Logo
Section 1 / 11

状态对象

由于状态对象是任何应用程序最基础的部分,我们将仔细设计它,以避免未来出现任何问题。

导入

状态对象

由于状态对象是任何应用程序最基础的部分,我们将仔细设计它,以避免未来出现任何问题。

在上一节中,我们已经完成了 Skypey 应用的基本框架。现在,让我们进入应用最核心的部分:状态对象(state object)。

React 应用的构建方式决定了整个应用在很大程度上是状态对象的一个函数。

无论你是在开发一个复杂的大型应用,还是一个简单的项目,都应该认真思考如何设计应用的状态对象结构。

尤其是在使用 Redux 时,如果能正确地设计状态对象,就能大大降低应用的复杂性。

那么,怎样才算设计得当呢?

首先,考虑一下我们的 Skypey 应用。

应用中的每个用户都有多个联系人。

user-contacts-1.png
user-contacts-1.png

而每个联系人与主用户之间都有一系列消息,构成了他们之间的对话记录。当你点击任意一个联系人时,就会进入该对话界面。

user-messages-1.png
user-messages-1.png

根据这种关系,你脑海中可能会浮现如下图所示的结构。

A giant user box with nested contacts
A giant user box with nested contacts

于是,你可能会这样描述应用的状态:

user-contact-rel-explained.png
user-contact-rel-explained.png

用普通的 JavaScript 表示,你的状态对象可能长这样:

1const state = { 2 user: [ 3 { 4 contact1: 'Alex', 5 messages: [ 6 'msg1', 7 'msg2', 8 'msg3' 9 ] 10 }, 11 12 { 13 contact2: 'john', 14 messages: [ 15 'msg1', 16 'msg2', 17 'msg3' 18 ] 19 } 20 ] 21}

上面这个状态对象中,user 字段是一个庞大的数组。由于用户有多个联系人,这些联系人就以对象的形式存放在数组中。又因为每段对话包含多条消息,所以消息也被存储在数组里。

乍一看,这似乎是个合理的方案。但事实真的如此吗?

如果你从后端接收到的数据结构正好是这样的,会不会觉得挺好的?

其实并不理想。在本节课的下一部分中,我们将讨论如何优化这一实现方式。

理解通过操作进行的状态更新

识别关系