这段时间我在寻找新坑，我们公司有个坑一直没人做，也就是动态 flutter，支持热更新，支持预加载，支持分布式开发

由于要做一个使用起来比较舒服的轮子，最近研究了下React的状态管理库，当然，仅限在使用层面，也就是用着舒服的角度来选择到底使用哪个状态管理库。本着在Github上面看看React社区内状态管理库的流行程度和使用程度的层面

在博客开发的过程中，有这样一个需求想解决，就是在SSR开发环境中，服务端的代码是是直接通过webpack打包成文件，因为里面包含同构的代码，就是服务端与客户端共享前端的组件代码

任何一个项目发展到一定复杂性的时候，必然会面临逻辑复用的问题。在React中实现逻辑复用通常有以下几种方式：Mixin、高阶组件(HOC)、修饰器(decorator)、Render Props、Hook。本文主要就以上几种方式的优缺点作分析

Context是 React中为了避免在不同层级组件中逐层传递props的产物，在没有Context的时候父组件向子组件传递props属性只能在组件树上自上而下进行传递，但是有些属性并不是组件树的每层节点都有相同的需求

React Hooks是从React 16.8版本推出的新特性，目的是解决React的状态共享以及组件生命周期管理混乱的问题。React Hooks的出现标志着，React不会再存在无状态组件的情况，React将只有类组件和函数组件的概念

在进入正式阅读之前，最好先思考一下下面的问题：React Hooks真的有生命周期吗？React Hooks的函数里面定义的函数或者变量会被缓存吗，这样下次再调用组件的时候就可以不用重新声明了。

前段时间 React 团队发布了一项用于解决 React 页面在多接口请求下的性能问题的解决方案 React Server Components。当然该方案目前还在草案阶段，官方也只是发了视频和一个示例 demo 来说明这个草案。

如果react火起来的时候，没有virtual dom，会怎样？你还会选择使用react吗？这是一个历史假设问题。但今天来看，这个问题却非常有趣，因为，在经历对react的狂热追捧之后

React 的数据是自顶向下单向流动的，即从父组件到子组件中，组件的数据存储在 props 和 state 中。实际上在任何应用中，数据都是必不可少的，我们需要直接的改变页面上一块的区域来使得视图的刷新

react-multi-page-app 是一个基于 webpack5 搭建的 react 多页面应用。为什么搭建多页面应用：多个页面之间业务互不关联，页面之间并没有共享的数据

UI产生交互的根本原因是各种事件，这也就意味着事件与更新有着直接关系。不同事件产生的更新，它们的优先级是有差异的，所以更新优先级的根源在于事件的优先级。一个更新的产生可直接导致React生成一个更新任务，最终这个任务被Scheduler调度

这样的用法和以往的 setState 是有明显的不同的，他看起来更像 redux——我们初始化一个 state，然后 dispatch 一个 action，再由 reducer 改变 state 后返回新的 state。

在典型的 React 数据流中，props 是父组件与子组件交互的唯一方式。要修改一个子组件，你需要使用新的 props 来重新渲染它。但是，在某些情况下，你需要在典型数据流之外强制修改子组件/元素。

React 是一个专注的组件库。因此，它对如何请求远程数据没有什么建议。如果要通过 HTTP 请求数据并将其发送到 Web API ，可以考虑下面四种方法。