Prajna's blog

Mental model react 的核心可以用 ui=fn(state)来表示，更详细可以用 12const state = reconcile(update);const UI = commit(state); react源码可以分为如下几个模块： Scheduler（调度器）： 排序优先级，让优先级高的任务先进行reconcile Reconciler（协调器）： 找出哪些节点发生了改变，并打上不同的Tag Renderer（渲染器）： 将Reconciler中打好标签的节点渲染到视图上 12345 Scheduler的作用是调度任务，react15没有Scheduler这部分，所以所有任务没有优先级，也不能中断，只能同步执行。​ Reconciler发生在render阶段，render阶段会分别为节点执行beginWork和completeWork（后面会讲），或者计算state，对比节点的差异，为节点赋值相应的effectTag（对应dom节点的增删改）​ Renderer发生在commit阶段，commit阶段遍历effectList执行对应的dom操作或部 ...

IntroductionBit是用于组件驱动的开发的标准基础结构。它提供了可扩展的工具链，以模块化和可扩展的方式开发，构建，测试和集成组件。 Bit的工作区使模块化Web项目的分布式开发成为可能，从而将任何Web项目变成由组件组成的“ monorepo”。每个功能都是组件的范围。组件的每个范围都包含其所有者团队需要交付的所有内容：UI组件，数据连接的组件，React钩子，Node模块，甚至是无服务器功能。 在这里推出官网: bit Juncture在团队进行项目微服务化的时候，进行到组件的拆分的时候遇到了写问题，主要是多个微项目间的组件共用。 一开始的构想就是集成组件库，已有一个团队组件库，使用的是dumi，但如果在项目间使用，便需要频繁到组件库中修改，而且不方便进行调试。在调研了一番，于是便使用了bit作为组件拆分方案。 使用时很简单，只需要按照官网教程走一遍就行 tutorial v14 version老版使用很简单，这里使用的是线上的，具体命令可以参考官网，这里说下大概： 第一个组件install12npm install bit-bin -gbit -v init1bit i ...

转载自前端备忘录-江湖术士 我们来看看看看，搭配 anime.js ，并采用领域驱动，如何做动画吧~ 123456789101112131415function useAnime(props: AnimeParams = {}) { const ref = useRef<any>(); const animationRef = useRef<AnimeInstance>(); useLayoutEffect(() => { if (!ref.current) { console.warn("please bind the anime ref while useAnime"); return; } animationRef.current = anime({ ...props, targets: [ref.current], });
...

转载自前端备忘录-江湖术士 React Hooks DDD 性能优化方案使用 DDD 的方案，只通过 基础 Hooks 组织业务代码，实际上是对开发常识的一种回归 DDD 并不比分层架构架构更难，相比，它比分层架构集成度更高，依赖更少，开发更自然，更符合人的思维习惯 不同于后端，涉及多节点，多服务，涉及统一数据访问结构等，抽象成 DDD 要麻烦很多，前端不涉及这些问题 因此，对于前端来讲，DDD 只是对基础面向对象的一次回归，只是对之前妄图只通过函数式解决应用架构级别问题的拨乱反正，应该是大幅提高生产效率，大幅降低学习成本的方案 废话不多说，我们来看看，就性能优化来说，在 DDD 下应该如何进行 调度组件渲染过程，我们无法干预，这个是 React 自己的逻辑，这部分没必要纠结 patch 过程对开发者来说完全封闭，无法干预 但是，如同其他所有异步方案，调度是性能优化的核心 我们的注意力总是应该集中在调度上 即 —— 控制 React 何时进入 协调过程，协调过程中是否要进行 patch 何时进入协调？首先明确一个问题，你需要视图更新，必然会进入协调，这个过程不以人的意志为转移，不可能跳 ...

转载自前端备忘录-江湖术士 好了，大家如果已经熟悉了 React DDD，那么可以来看看如何真正发挥出 React DDD 的威力吧！ 首先，领域驱动是面向对象在自顶向下设计中，发挥最大威力的模式，是极限的面向对象思想方法 你可能会说，不对，React 是函数式 朋友，且不说 React 与极限管道风格的 cycle 等框架有多少差距，世界上存在纯粹无副作用的函数式系统么？（lambda机已经不存在了） 既然不存在，项目越大，副作用越多，自底向上的开发模式早晚会碰到它的边界，这时候，面向对象在顶层架构发威，一定会成为必然 关于为什么到了某个层级，领域驱动是必然，推荐一下阿里的回答： 软件系统从来都不是凭空而来，而是以软件的形式解决特定的问题。当我们面临现实世界的复杂问题时，如何以软件的形式落地？领域驱动设计是一套方法论，指导我们将复杂问题进行拆分、拆分出各个子系统间的关联以及是如何运转的，帮助我们解决大型的复杂系统在落地中遇到的问题 分治是 DDD 的核心注意，这个分治，不是只分治状态，只分治状态没有意义 而是要将 状态，逻辑，资源（图片，音视频），配置项等等 一起分治 极端一点，分开 ...

转载自前端备忘录-江湖术士 基础函数式，比如纯函数，柯里化什么的，就先不讨论了，大家可以自行搜索，这部分文章非常多 如果形成一个标准封装的函数结构，那么我们可以做些什么事情呢？ 123456789function someFunc(state) { // just mutate state state.xxx = xxx; return state;}function anotherFunc(state) { state.otherXxx = otherXxx; return state;} 当我们做了科里化之后，两个函数如果共享同一个参数和返回数据，我们可以把它们连接起来 someFunc(antherFunc(state)) 这就构成了一个流水生产线，以此类推还可以叠加更多 someFunc1(someFunc2(someFunc3(someFunc4))) 通过类似 ramda 库中的 compose 封装一下，可以更加美观： R.compose(someFunc3,someFunc2,someFunc1)() 注意顺序 这就很 ...

转载自前端备忘录-江湖术士 二话不多说，先上代码： 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667import { createContext, Profiler, useContext, useEffect, useState,} from "react";const Service = createContext(null);function useService() { const [check, setCheck] = useState(""); useEffect(() => { setTimeout(() => { setCheck("change"); }, 3000 ...

转载自前端备忘录-江湖术士 这部分会非常枯燥，如果不想看的可以不看，直接给结论到就行，那就是—— React DDD 并不需要你考虑性能问题 除了惰性初始化 小字也注意一下，要严谨一些 那好，我们开始吧 首先，我们要知道，class 下的 React 协调调度和 function 下的逻辑是不同的，不要拿着 class 的逻辑 说 function，这样没有意义，这属于历史问题 这不单是给 React 程序员说的，也是给其他平台程序员说的，hooks 发布之后，这两种写法其实是势同水火，官方只是为了保证平滑升级而已（ng 暴力升级就不会有这方面考量，有利有弊） 首先，在 reconcile 源码的 beginWork 入口处，你就能看到 updateFunctionComponent 和 updateClassComponent 的不同： https://github.com/facebook/react/blob/master/packages/react-reconciler/src/ReactFiberBeginWork.new.js updateFunctionCompone ...

转载自前端备忘录-江湖术士 React DDD 可以 很好地配合 Typescript 使用时有以下原则： 类型必须自动获得，最好不要主动声明，参数声明，强制注解都最好不要有 class 结构应对复杂数据（注意！只是数据）时，对类型的支持比 function 强大经常看我文章的人，一定会记得，我对待 Typescript 的看法： 非 DDD 下使用 Typescript 体验非常差 非 管道函数式 下使用 Typescript 体验非常差 不提倡 Reducer ，但是承认其有一定作用（对于不熟悉管道的同学）好了，接下来我们来详细阐述： 类型最好自动获取，自动推断Typescript 是个工具，是来帮助你写代码的 不是来干扰你写代码的！ 比如，一旦需要你手动声明类型（除非交由你定义），其实和无类型的体验差不多 比如，redux 的各种散件 function 提取： 12345678910111213141516export const SEND_MESSAGE = "SEND_MESSAGE";export const DELETE_MESSAGE ...

转载自前端备忘录-江湖术士 领域驱动，各自只管各自的模块，顶层再来进行组装和分配 坚持根据特性区命名目录。 坚持为每个特性区创建一个 NgModule。 能提供限界上下文，将某些功能牢牢地锁在一个地方，开发某个功能时，只需要关心这个模块就够了。 视图的归试图，逻辑的归逻辑1234function SomeComponent() { const someService = useService(); return <div>{someService.state}</div>;} 跨组件数据传递？12345678910function useGlobalService() { return { state: "" };}const GlobalService = createContext(null);function SomeComponent() { return ( <GlobalService.Provider valu ...