前端工作第四年

最新推荐文章于 2024-08-12 01:25:53 发布

kill370354

最新推荐文章于 2024-08-12 01:25:53 发布

阅读量298

点赞数 4

文章标签：前端

本文链接：https://blog.csdn.net/kill370354/article/details/140758661

版权

这是一篇水文，没有干货。

之前写过一年经验、前端三年，经历与经验，之所以没有“两年经验”，大概是因为两年的时候没有经验。本文标题没有提到“经验”二字，也是同样原因。

技术相关

状态管理相关疑问

这一年最想提的，就是上半年有个内部系统做重构，采取了一些新写法，不太习惯，为了寻求“最佳实践”，也曾问过群友、查过 github，最终仍无所成，迷茫至今……

新项目采用了 vue3 + pinia + tsx，我看 pinia 文档提到：

一个 Store 应该包含可以在整个应用中访问的数据。这包括在许多地方使用的数据，例如显示在导航栏中的用户信息，以及需要通过页面保存的数据，例如一个非常复杂的多步骤表单。

另一方面，你应该避免在 Store 中引入那些原本可以在组件中保存的本地数据，例如，一个元素在页面中的可见性。

我理解应该就是判断状态是否为多页面共享，以决定是否使用 pinia。但是这个新项目中，凡是后端返回的业务数据都保存在 pinia 中，简单来说就是接口返回的数据都保存。显然，这样会导致页面组件注销后仍然占用着内存。问过同事为什么这样做，回答比较宽泛：组件与数据分离，便于维护，便于单测……

按如上目的，把状态提到全局，类似 hook 的写法也同样有效。我也确实写过这样的代码，结果 code review 又没通过，最后还是改成了pinia，理由就是 hook 文件的 ref 应该在函数内部而非全局。

该问题已困扰我四个月了。期间见过内网中另一位前端大佬写的文章，提到前端数据结构设计，可能二者有一定关联。文中提到，把列表数据转换为按唯一 key 存储的对象数据，比如：

[
  { id: '123', name: 'a', age: 1 },
  { id: '456', name: 'b', age: 2 }
]

要存储为：

{
    "123": {
        "id": "123",
        "name": "a",
        "age": 1
    },
    "456": {
        "id": "456",
        "name": "b",
        "age": 2
    }
}

如果列表页可以点击查看详情，那么还可以往这个json中存储其他属性。这样的好处是页面展示的数据来源单一，如果有更新操作也很方便更新。否则如果列表数据和详情分开，得分开更新，可能还会需要列表整个刷新。

显然做这样一层转换是需要代码额外处理的，我也能理解这样做的好处，之前我也想过做类似的转换：

比如一个聊天页面，类似企业微信、新版QQ的样式，左侧是消息会话列表，中间是聊天框，右侧是群成员群介绍等，显然，对于中间和右侧的展示，我们不可避免要取多种类型的数据，这时就需要考虑设计什么结构，比如：

[
 // 整个数据也可以是对象形式，把群 id 作为 key
    {
        "id": "群id1",
        "messageList": [],
        "groupMembers": [],
        "info": {}
    },
    {
        "id": "群id2",
        "messageList": [],
        "groupMembers": [],
        "info": {}
    }
]

还是：

{
    "messageMap": {
     // 也可以是数组形式
        "群id1": [],
        "群id2": []
    },
    "groupMembers": {
    // 也可以是数组形式
        "群id1": [],
        "群id2": []
    },
    "info": {
     // 也可以是数组形式
        "群id1": {},
        "群id2": {}
    }
}