看了上面的问题，我理解你的担心是如果存在多 redux Store 实例的情况下，由 Context-Provider 向下传入的 store value 会不会被互相覆盖，其实 react-redux 提供了多实例的使用方式，使用起来会增加你应用开发的复杂度，具体链接： https://react-redux.js.org/using-react-redux/accessing-store#multiple-stores 。（需要在 Provider 中和组件的 connect 中手动指定 Context 实例方式手工指定 store 的来源）

但是不推荐你这么做，因为会让使用你组件的开发者带来不小的心智负担。

- - -

假设你的组件逻辑非常复杂（如：富文本编辑器、拖拽组件等）一定要选一种数据流方案将逻辑外置的话，推荐你用 mobx （开启严格模式），但是使用时候一定要注意 mobx 获取的所有对象实例都是 mutable 的，有时候需要手动去处理引用相等问题导致组件不更新，最新版的 mobx-react 也是对 hooks api 很友好的，非常方便。

- - -

最推荐的做法还是使用 Context + useReducer 来自定义 hooks 方式来解决你的问题，根据你上面的描述这种方式完全可以满足你的需求。

MDN 上关于 relatedTarget 的解释： https://developer.mozilla.org/en-US/docs/Web/API/FocusEvent/relatedTarget

不同事件的 relatedTarget 不太一样

CodeSandBox: https://codesandbox.io/s/onblur-bubble-preventiton-ngsdj?file=/src/App.js

核心思路是利用 event.relatedTarget 这个属性来判断失焦是来自内部还是外部。代码如下：

import React, { useRef } from "react";
import "./styles.css";

export default function App() {
const outerRef = useRef();
return (
<div className="App">
<div
onBlur={(e) => {
// 失焦后获取焦点的那个元素
const nextFocusDom = e.relatedTarget;
// 判断其是否在父元素内，如果在父元素内就不错处理
if (nextFocusDom && outerRef.current.contains(nextFocusDom)) {
console.log(" [内部导致] 父元素失焦");
} else {
console.log(" [需要处理] [外部导致] 父元素失焦");
}
}}
className="outer"
ref={outerRef}
tabIndex="0"
>
<input className="inner" />
<select className="inner" />
</div>
<input />
</div>
);
}

let data = [
{
"id": "1234",
"key1": "val1",
"key2": "val2",
"name": "someone",
"age": 39
},
{
"id": "1234",
"key1": "val1",
"key2": "val2",
"name": "someone",
"age": 39
}
]

let result = data.map(item => {
// 过滤出想要保留的 key
const fKeys = Object.keys(item).filter(key => !['name', 'age'].includes(key));
// 不改变原有引用对象数据
let newItem = {};
for (let key of fKeys) {
newItem[key] = item[key];
}
return newItem;
});

指定黑名单就行了，如果是白名单的话用展开操作符可以简化逻辑

你都用 saga 了就还是按照 saga 那套中心化 store 的模式来吧。如果想在组件内使用 hooks，那就在你的页面最外层包一层 conncect 把 dispatch 和 store 传进去（可以爷父子一层一层，也可以创建一个 context 直接隔着传下去），里面的消费组件只要写好 effect 处理好引用变更就好了。

把语言切换的状态做成持久化的，只在加载应用的时候读取一次然后递给应用最外层的 Provider 。

固定长度消息头里写消息体的长度，读取的时候不够就缓存下来不处理，等下一个包拼起来完整了再处理

按照你的写法：
1 、useEffect 中的代码只会在组件 mount 以后执行一次，不管以后组件状态或者 props 怎么变 useEffect 中的代码只会执行 1 次。（也就是为什么 1 和 2 只会输出一次，而 0 会输出多次）
2 、useState 生成的 setState 的执行是**创建一个新的 state 为下一次 render 使用**。但是 useEffect 这次函数闭包里的 formData 是上一次的 state 也就是{}，这一点跟类组件的 this.state 是完全不一样的。类组件的 this.state 保存的是状态对象的一个引用，但是用 useState 生成的 state 是通过闭包保存了执行 useEffect 时 state 的在函数执行上下文中的，也就是旧的 state 引用。每次重新 render 以后都会生成一个新的 state，而不是改变旧 state 的引用里的值。

升高了都晃

这个网站加密比较厉害，建议用模拟浏览器的方式去爬

geohash 可解

```javascript
class Main extends Component {
constructor(props) {
super(props);
this.state = {
value: 0,
};
this.handleChange = this.handleChange.bind(this);
}

handleChange(event) {
this.setState({
value: event.target.value,
});
}

render() {
const { data = [] } = this.props;
return (
<>
<select value={this.state.value} onChange={this.handleChange}>
{data.map((item, idx) => (
<option value={idx} key={JSON.stringify(item)}>
{idx + 1}
</option>
))}
</select>
<Chart data={data[this.state.value]} />
</>
);
}
}
```

你的 Chart 应该是只有 componentDidMount 的时候渲染了一次，之后就不渲染了，如果是 echarts 的话要手动在 componentWillReceiveProps 周期里面去判断 props.data 是不是改变了然后手动去用 echarts 的 api 去刷新图表

@batyu 是的，可能也就是技术栈相近一点改造成本没那么高。或者也可以试试新框架做渐进式的改造，慢慢改，这点上面 vue 做的比 react 好。

引入 requirejs+backbone+handlebars 模板做模块化改造成本小一点，但是要看原先的数据渲染是放在服务端做的还是前端做的，要是服务端做的话改造还是比较大

reducer 拆分下 然后用 combineReducer 的方式会清楚一点。如果还不行的话尝试考虑用 middleware 去做更高级的处理

把包 1 单独部署成 umd 的版本，然后 A B 两个项目 external 这个包用 umd 方式引入，就可以实现包 1 在线版本更新后 A 和 B 不用重新编译部署，但是需要注意浏览器的缓存策略。

你的需求是不是找一个能够提供 api 来操作生成颜色字符串的库，这个库可以 https://github.com/bgrins/TinyColor
但是需要一点颜色变换的理论基础才能生成比较好看的色板

这样改应该就可以了，let 定义的变量名不允许重定义，但是允许重复赋值。

window.onload = function () {
let gogogo;
let btn1 = document.getElementById('btn1');

btn1.onclick = function () {
clearInterval(gogogo);
gogogo = setInterval(function () {省略...})
}

在 github 发现了这个仓库看了下代码，一开始以为是对 jsnes 的 ts 实现，后来发现好像不是。不过楼主厉害 一个月能做成这样,666