Open worldzhao opened 2 years ago
学习了
彩蛋很精华[手动狗头]
issue当文档用,太秀了。厉害。这样也可以进行评论交流了。嘿嘿
issue当文档用,太秀了。厉害。这样也可以进行评论交流了。嘿嘿
好奇,有React Query + Unstated Next 的範例嗎? 感謝
好奇,有React Query + Unstated Next 的範例嗎? 感謝
根据官方文档正常使用就可以了呀。
React Query 负责异步数据请求,遇到复用的场景不需要额外存储到 context 和 redux 等工具
Unstated Next 当作正常 Context 使用就好
React Query: Does this replace client state? 这篇文章也描述了二者的关系,可以看看。
好奇,有React Query + Unstated Next 的範例嗎? 感謝
今天发现使用 react query 以及 swr 如果只是做简单的客户端状态共享,甚至 context 也可以需要,参见下图:
好奇,有React Query + Unstated Next 的範例嗎? 感謝
今天发现使用 react query 以及 swr 如果只是做简单的客户端状态共享,甚至 context 也可以需要,参见下图:
之前有在想unstated-next 的部份要不要換成recoil or zustand。不過之後換工作可能要回去寫vue了XD
Q:为什么有回归环节? A: 因为同一天会上线一个项目的多个需求,所以提前合入 master 回归(一般提前一天)这一步是为了避免多个需求同一天上线合码导致的一些 BUG,故而有了这个环节。
feature 分支合并到 master 的时机是不是早了一点?比如说 a 功能临时不上线了,遇到这样的场景还要再把 a 功能的分支剔除掉。
Q:为什么有回归环节? A: 因为同一天会上线一个项目的多个需求,所以提前合入 master 回归(一般提前一天)这一步是为了避免多个需求同一天上线合码导致的一些 BUG,故而有了这个环节。
feature 分支合并到 master 的时机是不是早了一点?比如说 a 功能临时不上线了,遇到这样的场景还要再把 a 功能的分支剔除掉。
测试完预发环境才会合入 master,如果都到了这个阶段还不上线那确实只能恶心人了,但在多需求并行的情况下,合并是无法避免的,总不可能上线前才合入而不预留回归时间。
想自己搭建一个企业级react组件库,用哪种方式最合适呢?如果用Monorepo的话,现在看有好几种方式pnpm,yarn...然后发布工具lerna。。。有那种开箱即用得模板吗?
想自己搭建一个企业级react组件库,用哪种方式最合适呢?如果用Monorepo的话,现在看有好几种方式pnpm,yarn...然后发布工具lerna。。。有那种开箱即用得模板吗?
monorepo 对于组件库来讲可有可无,如果要用的话, pnpm 默认的 workspace 支持即可。
喔喔,之前用得yarn,pnpm没用过,到时候试试
请问作者对于不同项目中共享的services在monorepos中该怎么作为单独项目(不包含请求库)管理 ?主要不同项目中会有有着不同的拦截规则,(请求库使用axios)。 使用共享services时与如何各项目内的拦截规则集成? 现在本人是将拦截规则在各项目中也抽离封装,然后在业务内配合共享services组合使用,但是感觉实在不够优雅,相当于多一个隐式约定。 另外还有ts请求/响应参数的智能提示现在是通过导出共享的services单个service附带函数通过Parameters,ReturnType工具类体操获得,感觉也是太过啰嗦 作者有这类场景的实践建议么?有简单的示例的话就更好啦,感谢!
同时,作者的分享非常棒,从中真的学习到了非常多对于monorepos项目管理的经验,再次感谢!
请问作者对于不同项目中共享的services在monorepos中该怎么作为单独项目(不包含请求库)管理 ?主要不同项目中会有有着不同的拦截规则,(请求库使用axios)。 使用共享services时与如何各项目内的拦截规则集成? 现在本人是将拦截规则在各项目中也抽离封装,然后在业务内配合共享services组合使用,但是感觉实在不够优雅,相当于多一个隐式约定。 另外还有ts请求/响应参数的智能提示现在是通过导出共享的services单个service附带函数通过Parameters,ReturnType工具类体操获得,感觉也是太过啰嗦 作者有这类场景的实践建议么?有简单的示例的话就更好啦,感谢!
同时,作者的分享非常棒,从中真的学习到了非常多对于monorepos项目管理的经验,再次感谢!
我说一下我这边的实践:
import request from '@request';
不知道有没有解决你的问题,不建议手写 service 代码
多谢作者解惑,生成service模板在项目内利用alias来实现集成的方案很棒,拓展了我的解决思路。
不过service模板作为单独的package,该怎么配合项目alias使用?这种情况下service package中的alias
@request
也会被替换?我去测试一下。
另外turborepo推出后,作者对于业务项目monorepo现在更推荐rush?还是turborepo+pnpm ?
多谢作者解惑,生成service模板在项目内利用alias来实现集成的方案很棒,拓展了我的解决思路。 不过service模板作为单独的package,该怎么配合项目alias使用?这种情况下service package中的
alias
@request
也会被替换?我去测试一下。 另外turborepo推出后,作者对于业务项目monorepo现在更推荐rush?还是turborepo+pnpm ?
让 webpack 处理一下这个包就可以了,推荐 pnpm,rush 文档不是太友好,pnpm 足够了
这两年收获了很多,在构建大型项目上面积累了一些经验,虽然已经融入在了日常开发协作中,但依旧觉得有必要记录下来,希望对其他同学形成一些参考。
(可选)Monorepo
Monorepo 是一个包含多个不同项目的单一仓库,这不是必须的,但对于我们团队来讲,从中受益良多。
对于开发者来讲,常常会遇到以下实际场景:
维护的多个组件库、配置库或工具库提供给多个业务项目使用
与这个问题类似的还有统一改造相关问题,如域名升级、基础库升级等等,一个项目对应一个仓库会导致此类场景很难推进(多仓库、多分支以及多版本号)。
流程重复建设
发包流水线,Gitlab CI 流水线等等,需要为每一个项目进行单独配置,存在很多重复工作。
项目开发指南以及规范也很难聚焦,不够透明,无法快速地作用到每一位同学。
通过 Monorepo 可以解决很多此类流程以及规范上的问题,整体团队达到一致与统一,降低沟通损耗,同时随着团队扩大以及项目的增多,模块抽离与复用变得十分容易。
笔者先前有过 Rush 的落地经验,在实践过程中,发现除了最基本的代码共享能力外,还应当至少具备三种能力,即:
如何选择合适自己的 Monorepo 工具链?
想要了解更多关于 Monorepo 的知识,可以翻阅笔者 Monorepo 系列文章:
我也为你准备了一个 Rush 项目的模板:https://github.com/worldzhao/rush-monorepo-example
🗄️ 项目结构
就近原则:将组件、函数、样式、状态等尽可能地放在其被使用的地方。
除了以类型维度划分组件 components、函数 utils、状态 models 以及 hooks 等模块,业务开发中更多时候应该以功能 feature 为维度组织项目。
feature 是服务于某个业务模块的 components、models 以及 utils 等模块的组合,如果是没有具体业务属性相关的通用模块就放外面。
这是构建大型项目的较佳实践,在可维护性与可读性上取得了较好的效果。 目录结构如下:
推荐阅读:
React 基础不牢,地动山摇
Hooks 基础
组件设计
避免坏味道的代码
关于 useMemo 与 useCallback
遇到长列表可以考虑使用 React.memo 配合 useMemo/useCallback 进行 rerender 优化,绝大多数场景下不会遇到性能问题,不要过早优化,更不要无脑使用这两个 hook,会引入过多 dependencyList,导致后续维护难度增加。 若在函数内取到了不符合预期的旧值,请考虑:
推荐阅读:
💅🏻 样式方案
推荐:Tailwind CSS + Styled Components
兼顾开发效率与视觉规范,优先使用 Tailwind CSS 处理样式,内置部门内视觉规范以及通用的样式方案。
遇到 Tailwind CSS 无法覆盖的场景,如一些复杂的伪类或覆盖第三方组件库的样式,请使用 Styled Components。
优点:
缺点:
renderXXX()
推荐阅读:
🗃️ 状态管理
推荐:React Query + Unstated Next
服务端状态交由 React Query(或 SWR)管理,客户端状态共享基于 React Context 即可。
对于绝大多数应用程序来说,在将所有的异步代码迁移到 React Query 之后,真正需要全局访问的客户端状态通常是非常少的。
为了保证可读性,你更应该使用 Unstated Next 而非直接使用 React Context。
推荐阅读:
📡 网络请求
推荐:暂无
除了简单封装 axios 以及 fetch 等网络请求库(不要过度封装!),还有两点需要重点关注:
由于笔者使用的是公司内部方案,没有使用过开源方案,所以暂无推荐,只听说过 Pont,有兴趣的同学可以一试。
🌲 分支规范
推荐:Trunk Based Development
分支规范需要结合当前团队的迭代节奏合理选择。对于 Monorepo 以及迭代节奏稳定、不过度追求灵活的团队来讲,推荐使用 Trunk Based Development 分支模型。
开发阶段:
测试阶段:
同开发阶段一致
预上线阶段:
hotfix:
优点:
10 lines = 10 issues; 500 lines = looks fine
缺点:
以上是推荐做法,但实际上往往不尽人意,以笔者目前团队为例,同一个业务项目存在了多个产品经理,产品经理的需求之间相互独立,但是会要求在同一天上线,同时希望需求 A 不会因为需求 B delay 而 delay。
Q:为什么有回归环节?
A: 因为同一天会上线一个项目的多个需求,所以提前合入 master 回归(一般提前一天)这一步是为了避免多个需求同一天上线合码导致的一些 BUG,故而有了这个环节。
Q:为什么预发环境测试完才合入 master?
A: 是为了最大程度避免某个需求出现问题导致整体需求 delay,测完 PPE 基本已经有保障了。
代理工具
推荐:whistle / lightproxy
使用代理工具时,开发者一般会关注以下内容五点内容:
构建工具内置的 proxy 往往无法全面满足,笔者使用的是公司内部基于 whistle 开发的一个代理软件,开源工具可以试试 whistle 以及 lightproxy。
其他
通过 CI 流水线保证代码质量、自动发包流水线提高发包效率也是很有必要的,但是笔者都是基于 Monorepo 仓库前提进行落地,参考价值可能不大,就不详细展开了。