= [];
171 |
172 | map(dataset, (example: {
173 | "sepalLength": number,
174 | "sepalWidth": number,
175 | "petalLength": number,
176 | "petalWidth": number,
177 | "species": string,
178 | }) => {
179 | const input: any = omit(example, 'species');
180 | inputValues = inputValues.concat(values(input));
181 | });
182 |
183 | const input = new Array2D(
184 | [datasetSize, inputValues.length / datasetSize],
185 | inputValues,
186 | ).transpose();
187 |
188 | return input;
189 | }
190 | ```
191 |
192 | ## 小结
193 | 在理解了数据向量化及矩阵的概念后，相信大家已经可以将大样本量，以数组形式存储的数据转换为适合进行深度学习模型训练的大型矩阵了，接下来让我们从如何初始化参数开始，一步步搭建我们的第一个深度学习模型。
--------------------------------------------------------------------------------
/2018/写给 Web 开发者的深度学习教程 - 数据标准化 & 参数初始化/equation1.svg:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/2018/React v16.3 版本新生命周期函数浅析及升级方案/React v16.3 版本新生命周期函数浅析及升级方案.md:
--------------------------------------------------------------------------------
1 | # React v16.3 版本新生命周期函数浅析及升级方案
2 | 一个月前，React 官方正式发布了 v16.3 版本。在这次的更新中，除了前段时间被热烈讨论的[新 Context API](https://zhuanlan.zhihu.com/p/33925435) 之外，新引入的两个生命周期函数 `getDerivedStateFromProps`，`getSnapshotBeforeUpdate` 以及在未来 v17.0 版本中即将被移除的三个生命周期函数 `componentWillMount`，`componentWillReceiveProps`，`componentWillUpdate` 也非常值得我们花点时间去探究一下其背后的原因以及在具体项目中的升级方案。
3 |
4 | ## componentWillMount
5 | ### 首屏无数据导致白屏
6 | 在 React 应用中，许多开发者为了避免第一次渲染时页面因为没有获取到异步数据导致的白屏，而将数据请求部分的代码放在了 `componentWillMount` 中，希望可以避免白屏并提早异步请求的发送时间。但事实上在 `componentWillMount` 执行后，第一次渲染就已经开始了，所以如果在 `componentWillMount` 执行时还没有获取到异步数据的话，页面首次渲染时也仍然会处于没有异步数据的状态。换句话说，组件在首次渲染时总是会处于没有异步数据的状态，所以不论在哪里发送数据请求，都无法直接解决这一问题。而关于[提早发送数据请求](https://gist.github.com/bvaughn/89700e525ff423a75ffb63b1b1e30a8f)，官方也鼓励将数据请求部分的代码放在组件的 `constructor` 中，而不是 `componentWillMount`。
7 |
8 | 另一个常见的 `componentWillMount` 的用例是在服务端渲染时获取数据，因为在服务端渲染时 `componentDidMount` 是不会被调用的。针对这个问题，笔者这里提供两种解法。第一个简单的解法是将所有的数据请求都放在 `componentDidMount` 中，即只在客户端请求异步数据。这样做可以避免在服务端和客户端分别请求两次相同的数据（`componentWillMount` 在客户端渲染时同样会被调用到），但很明显的缺点就是无法在服务端渲染时获取到页面渲染所需的所有数据，所以如果我们需要保证服务端返回的 HTML 就是用户最终看到的 HTML 的话，我们可以将每个页面的数据获取逻辑单独抽离出来，然后一一对应到相应的页面，在服务端根据当前页面的路由找到相应的数据请求，利用链式的 Promise 在渲染最终的页面前就将数据塞入 redux store 或其他数据管理工具中，这样服务端返回的 HTML 就是包含异步数据的结果了。
9 |
10 | ### 事件订阅
11 | 另一个常见的用例是在 `componentWillMount` 中订阅事件，并在 `componentWillUnmount` 中取消掉相应的事件订阅。但事实上 React 并不能够保证在 `componentWillMount` 被调用后，同一组件的 `componentWillUnmount` 也一定会被调用。一个当前版本的例子如服务端渲染时，`componentWillUnmount` 是不会在服务端被调用的，所以在 `componentWillMount` 中订阅事件就会直接导致服务端的内存泄漏。另一方面，在未来 React 开启异步渲染模式后，在 `componentWillMount` 被调用之后，组件的渲染也很有可能会被其他的事务所打断，导致 `componentWillUnmount` 不会被调用。而 `componentDidMount` 就不存在这个问题，在 `componentDidMount` 被调用后，`componentWillUnmount` 一定会随后被调用到，并根据具体代码清除掉组件中存在的事件订阅。
12 |
13 | ### 升级方案
14 | 将现有 `componentWillMount` 中的代码迁移至 `componentDidMount` 即可。
15 |
16 | ## componentWillReceiveProps
17 | ### 更新由 props 决定的 state 及处理特定情况下的回调
18 | 在老版本的 React 中，如果组件自身的某个 state 跟其 props 密切相关的话，一直都没有一种很优雅的处理方式去更新 state，而是需要在 `componentWillReceiveProps` 中判断前后两个 props 是否相同，如果不同再将新的 props 更新到相应的 state 上去。这样做一来会破坏 state 数据的单一数据源，导致组件状态变得不可预测，另一方面也会增加组件的重绘次数。类似的业务需求也有很多，如一个可以横向滑动的列表，当前高亮的 Tab 显然隶属于列表自身的状态，但很多情况下，业务需求会要求从外部跳转至列表时，根据传入的某个值，直接定位到某个 Tab。
19 |
20 | 在新版本中，React 官方提供了一个更为简洁的生命周期函数：
21 |
22 | ```javascript
23 | static getDerivedStateFromProps(nextProps, prevState)
24 | ```
25 |
26 | 一个简单的例子如下：
27 |
28 | ```javascript
29 | // before
30 | componentWillReceiveProps(nextProps) {
31 | if (nextProps.translateX !== this.props.translateX) {
32 | this.setState({
33 | translateX: nextProps.translateX,
34 | });
35 | }
36 | }
37 |
38 | // after
39 | static getDerivedStateFromProps(nextProps, prevState) {
40 | if (nextProps.translateX !== prevState.translateX) {
41 | return {
42 | translateX: nextProps.translateX,
43 | };
44 | }
45 | return null;
46 | }
47 | ```
48 |
49 | 乍看下来这二者好像并没有什么本质上的区别，但这却是笔者认为非常能够体现 React 团队对于软件工程深刻理解的一个改动，即 **React 团队试图通过框架级别的 API 来约束或者说帮助开发者写出可维护性更佳的 JavaScript 代码**。为了解释这点，我们再来看一段代码：
50 |
51 | ```javascript
52 | // before
53 | componentWillReceiveProps(nextProps) {
54 | if (nextProps.isLogin !== this.props.isLogin) {
55 | this.setState({
56 | isLogin: nextProps.isLogin,
57 | });
58 | }
59 | if (nextProps.isLogin) {
60 | this.handleClose();
61 | }
62 | }
63 | ```
64 |
65 | ```javascript
66 | // after
67 | static getDerivedStateFromProps(nextProps, prevState) {
68 | if (nextProps.isLogin !== prevState.isLogin) {
69 | return {
70 | isLogin: nextProps.isLogin,
71 | };
72 | }
73 | return null;
74 | }
75 |
76 | componentDidUpdate(prevProps, prevState) {
77 | if (!prevState.isLogin && this.props.isLogin) {
78 | this.handleClose();
79 | }
80 | }
81 | ```
82 |
83 | 通常来讲，在 `componentWillReceiveProps` 中，我们一般会做以下两件事，一是根据 props 来更新 state，二是触发一些回调，如动画或页面跳转等。在老版本的 React 中，这两件事我们都需要在 `componentWillReceiveProps` 中去做。而在新版本中，官方将更新 state 与触发回调重新分配到了 `getDerivedStateFromProps` 与 `componentDidUpdate` 中，使得组件整体的更新逻辑更为清晰。而且在 `getDerivedStateFromProps` 中还禁止了组件去访问 this.props，强制让开发者去比较 nextProps 与 prevState 中的值，以确保当开发者用到 `getDerivedStateFromProps` 这个生命周期函数时，就是在根据当前的 props 来更新组件的 state，而不是去做其他一些让组件自身状态变得更加不可预测的事情。
84 |
85 | ### 升级方案
86 | 将现有 `componentWillReceiveProps` 中的代码根据更新 state 或回调，分别在 `getDerivedStateFromProps` 及 `componentDidUpdate` 中进行相应的重写即可，注意新老生命周期函数中 `prevProps`，`this.props`，`nextProps`，`prevState`，`this.state` 的不同。
87 |
88 | ## componentWillUpdate
89 | ### 处理因为 props 改变而带来的副作用
90 | 与 `componentWillReceiveProps` 类似，许多开发者也会在 `componentWillUpdate` 中根据 props 的变化去触发一些回调。但不论是 `componentWillReceiveProps` 还是 `componentWillUpdate`，都有可能在一次更新中被调用多次，也就是说写在这里的回调函数也有可能会被调用多次，这显然是不可取的。与 `componentDidMount` 类似，`componentDidUpdate` 也不存在这样的问题，一次更新中 `componentDidUpdate` 只会被调用一次，所以将原先写在 `componentWillUpdate` 中的回调迁移至 `componentDidUpdate` 就可以解决这个问题。
91 |
92 | ### 在组件更新前读取 DOM 元素状态
93 | 另一个常见的 `componentWillUpdate` 的用例是在组件更新前，读取当前某个 DOM 元素的状态，并在 `componentDidUpdate` 中进行相应的处理。但在 React 开启异步渲染模式后，render 阶段和 commit 阶段之间并不是无缝衔接的，也就是说在 render 阶段读取到的 DOM 元素状态并不总是和 commit 阶段相同，这就导致在
94 | `componentDidUpdate` 中使用 `componentWillUpdate` 中读取到的 DOM 元素状态是不安全的，因为这时的值很有可能已经失效了。
95 |
96 | 为了解决上面提到的这个问题，React 提供了一个新的生命周期函数：
97 |
98 | ```javascript
99 | getSnapshotBeforeUpdate(prevProps, prevState)
100 | ```
101 |
102 | 与 `componentWillUpdate` 不同，`getSnapshotBeforeUpdate` 会在最终的 render 之前被调用，也就是说在 `getSnapshotBeforeUpdate` 中读取到的 DOM 元素状态是可以保证与 `componentDidUpdate` 中一致的。虽然 `getSnapshotBeforeUpdate` 不是一个静态方法，但我们也应该尽量使用它去返回一个值。这个值会随后被传入到 `componentDidUpdate` 中，然后我们就可以在 `componentDidUpdate` 中去更新组件的状态，而不是在 `getSnapshotBeforeUpdate` 中直接更新组件状态。
103 |
104 | 官方提供的一个例子如下：
105 |
106 | ```javascript
107 | class ScrollingList extends React.Component {
108 | listRef = null;
109 |
110 | getSnapshotBeforeUpdate(prevProps, prevState) {
111 | // Are we adding new items to the list?
112 | // Capture the scroll position so we can adjust scroll later.
113 | if (prevProps.list.length < this.props.list.length) {
114 | return (
115 | this.listRef.scrollHeight - this.listRef.scrollTop
116 | );
117 | }
118 | return null;
119 | }
120 |
121 | componentDidUpdate(prevProps, prevState, snapshot) {
122 | // If we have a snapshot value, we've just added new items.
123 | // Adjust scroll so these new items don't push the old ones out of view.
124 | // (snapshot here is the value returned from getSnapshotBeforeUpdate)
125 | if (snapshot !== null) {
126 | this.listRef.scrollTop =
127 | this.listRef.scrollHeight - snapshot;
128 | }
129 | }
130 |
131 | render() {
132 | return (
133 |
134 | {/* ...contents... */}
135 |
136 | );
137 | }
138 |
139 | setListRef = ref => {
140 | this.listRef = ref;
141 | };
142 | }
143 | ```
144 |
145 | ### 升级方案
146 | 将现有的 `componentWillUpdate` 中的回调函数迁移至 `componentDidUpdate`。如果触发某些回调函数时需要用到 DOM 元素的状态，则将对比或计算的过程迁移至 `getSnapshotBeforeUpdate`，然后在 `componentDidUpdate` 中统一触发回调或更新状态。
147 |
148 | ## 小结
149 | 最后，让我们从整体的角度再来看一下 React 这次生命周期函数调整前后的异同：
150 |
151 | #### Before
152 | 
153 |
154 | #### After
155 | 
156 |
157 | 在第一张图中被红框圈起来的三个生命周期函数就是在新版本中即将被移除的。通过上述的两张图，我们可以清楚地看到将要被移除的三个生命周期函数都是在 render 之前会被调用到的。而根据原来的设计，在这三个生命周期函数中都可以去做一些诸如发送请求，setState 等包含副作用的事情。在老版本的 React 中，这样做也许只会带来一些性能上的损耗，但在 React 开启异步渲染模式之后，就无法再接受这样的副作用产生了。举一个 Git 的例子就是在开发者 commit 了 10 个文件更新后，又对当前或其他的文件做了另外的更新，但在 push 时却仍然只 push 了刚才 commit 的 10 个文件更新。这样就会导致提交记录与实际更新不符，如果想要避免这个问题，就需要保证每一次的文件更新都要经过 commit 阶段，再被提交到远端，而这也就是 React 在开启异步渲染模式之后要做到的。
158 |
159 | 另一方面，为了验证个人的理解及测试新版本的稳定性，笔者已经将个人负责的几个项目全部都升级到了 React 16.3 并根据上述提到的升级方案替换了所有即将被移除的生命周期函数。目前，所有项目在生产环境中都运行良好，没有收到任何不良的用户反馈。
160 |
161 | 当然，以上的这些生命周期函数的改动，一直要到 React 17.0 中才会实装，这给广大的 React 开发者们预留了充足的时间去适应这次改动。但如果你是 React 开源项目（尤其是组件库）的维护者的话，不妨花点时间去详细了解一下这次生命周期函数的改动。因为这不仅仅可以帮助你将开源项目更好地升级到 React 的最新版本，更重要的是可以帮助你提前理解即将到来的异步渲染模式。
162 |
163 | 同时，笔者也相信在 React 正式开启异步渲染模式之后，许多常用组件的性能将很有可能迎来一次整体的提升。进一步来说，配合异步渲染，许多现在的复杂组件都可以被处理得更加优雅，在代码层面得到更精细粒度上的控制，并最终为用户带来更加直观的使用体验。
--------------------------------------------------------------------------------
/2017/前端数据层不完全指北/前端数据层不完全指北.md:
--------------------------------------------------------------------------------
1 | # 前端数据层不完全指北
2 | 不知不觉间时间已经来到了 2017 年末尾。
3 |
4 | 在过去一年中，关于前端数据层的讨论依然在持续升温。不论是数据类型层面的 TypeScript，Flow，PropTypes，应用架构层面的 MVC，MVP，MVVM，还是应用状态层面的 Redux，MobX，RxJS，都各自拥有一批忠实的拥趸，却又谁都无法说服别人认同自己的观点。
5 |
6 | 关于技术选型上的讨论，笔者一直所持的态度都是求同存异。在讨论上述方案差异的文章已汗牛充栋的今天，不如让我们暂且放缓脚步，回头去看一下这些方案所要解决的共同的问题，并试图给出一些最简单的解法。
7 |
8 | 接下来让我们以通用的 MVVM 架构为例，逐层剖析前端数据层的共同痛点。
9 |
10 | ## Model 层
11 | 作为应用数据链路的最下游，前端的 Model 层与后端的 Model 层其实有着很大的区别。相较于后端 Model，前端 Model 并不能起到定义数据结构的作用，而更像是一个容器，用于存放后端接口返回的数据。
12 |
13 | 在这样的前提下，在 RESTful 风格的接口已然成为业界标准的今天，如果后端数据是按照数据资源的最小粒度返回给前端的话，我们是不是可以直接将每个接口的标准返回，当做我们最底层的数据 Model 呢？换句话说，我们好像也别无选择，因为接口返回的数据就是前端数据层的最上游，也是接下来一切数据流动的起点。
14 |
15 | 在明确了 Model 层的定义之后，让我们来看一下 Model 层存在的问题。
16 |
17 | ### 数据资源粒度过细
18 | 数据资源粒度过细通常会导致以下两个问题，一是单个页面需要访问多个接口以获取所有的显示数据，二是各个数据资源之间存在获取顺序的问题，需要按顺序依次异步获取。
19 |
20 | 对于第一个问题，常见的解法为搭建一个 Node.js 的数据中间层，来做接口整合，最终暴露给客户端以页面为粒度的接口，并与客户端路由保持一致。
21 |
22 | 这种解法的优点和缺点都非常明显，优点是每个页面都只需要访问一个接口，在生产环境下的页面加载速度可以得到有效的提升。另一方面，因为服务端已经准备好了所有的数据，做起服务端渲染来也很轻松。但从开发效率的角度来讲，不过是将业务复杂度后置的一种做法，并且只适用于页面与页面之间关联较少，应用复杂度较低的项目，毕竟页面级别的 ViewModel 粒度还是太粗了，而且因为是接口级别的解决方案，可复用性几乎为零。
23 |
24 | 对于第二个问题，笔者提供一个基于最简单的 redux-thunk 的工具函数来链接两个异步请求。
25 |
26 | ```javascript
27 | import isArray from 'lodash/isArray';
28 |
29 | function createChainedAsyncAction(firstAction, handlers) {
30 | if (!isArray(handlers)) {
31 | throw new Error('[createChainedAsyncAction] handlers should be an array');
32 | }
33 |
34 | return dispatch => (
35 | firstAction(dispatch)
36 | .then((resultAction) => {
37 | for (let i = 0; i < handlers.length; i += 1) {
38 | const { status, callback } = handlers[i];
39 | const expectedStatus = `_${status.toUpperCase()}`;
40 |
41 | if (resultAction.type.indexOf(expectedStatus) !== -1) {
42 | return callback(resultAction.payload)(dispatch);
43 | }
44 | }
45 |
46 | return resultAction;
47 | })
48 | );
49 | }
50 | ```
51 |
52 | 基于此，我们再提供一个常见的业务场景来帮助大家理解。比如一个类似于知乎的网站，前端在先获取登录用户信息后，才可以根据用户 id 去获取该用户的回答。
53 |
54 | ```javascript
55 | // src/app/action.js
56 | function getUser() {
57 | return createAsyncAction('APP_GET_USER', () => (
58 | api.get('/api/me')
59 | ));
60 | }
61 |
62 | function getAnswers(user) {
63 | return createAsyncAction('APP_GET_ANSWERS', () => (
64 | api.get(`/api/answers/${user.id}`)
65 | ));
66 | }
67 |
68 | function getUserAnswers() {
69 | const handlers = [{
70 | status: 'success',
71 | callback: getAnswers,
72 | }, {
73 | status: 'error',
74 | callback: payload => (() => {
75 | console.log(payload);
76 | }),
77 | }];
78 |
79 | return createChainedAsyncAction(getUser(), handlers);
80 | }
81 |
82 | export default {
83 | getUser,
84 | getAnswers,
85 | getUserAnswers,
86 | };
87 | ```
88 |
89 | 在输出时，我们可以将三个 actions 全部输出，供不同的页面根据情况按需取用。
90 |
91 | ### 数据不可复用
92 | 每一次的接口调用都意味着一次网络请求，在没有全局数据中心的概念之前，许多前端在开发新需求时都不会在意所要用到的数据是否已经在其他地方被请求过了，而是粗暴地再次去完整地请求一遍所有需要用到的数据。
93 |
94 | 这也就是 Redux 中的 Store 所想要去解决的问题，有了全局的 store，不同页面之间就可以方便地共享同一份数据，从而达到了接口层面也就是 Model 层面的可复用。这里需要注意的一点是，因为 Redux Store 中的数据是存在内存中的，一旦用户刷新页面就会导致所有数据的丢失，所以在使用 Redux Store 的同时，我们也需要配合 `Cookie` 以及 `LocalStorage` 去做核心数据的持久化存储，以保证在未来再次初始化 Store 时能够正确地还原应用状态。特别是在做同构时，一定要保证服务端可以将 Store 中的数据注入到 HTML 的某个位置，以供客户端初始化 Store 时使用。
95 |
96 | ## ViewModel 层
97 | ViewModel 层作为客户端开发中特有的一层，从 MVC 的 Controller 一步步发展而来，虽然 ViewModel 解决了 MVC 中 Model 的改变将直接反应在 View 上这一问题，却仍然没有能够彻底摆脱 Controller 最为人所诟病的一大顽疾，即业务逻辑过于臃肿。另一方面，单单一个 ViewModel 的概念，也无法直接抹平客户端开发所特有的，业务逻辑与显示逻辑之间的巨大鸿沟。
98 |
99 | ### 业务逻辑与显示逻辑之间对应关系复杂
100 | 举例来说，常见的应用中都有使用社交网络账号登录这一功能，产品经理希望实现在用户连接了社交账户之后，首先尝试直接登录应用，如果未注册则为用户自动注册应用账户，特殊情况下如果社交网络返回的用户信息不满足直接注册的条件（如缺少邮箱或手机号），则跳转至补充信息页面。
101 |
102 | 在这个场景下，登录与注册是业务逻辑，根据接口返回在页面上给予用户适当的反馈，进行相应的页面跳转则是显示逻辑，如果从 Redux 的思想来看，这二者分别就是 action 与 reducer。使用上文中的链式异步请求函数，我们可以将登录与注册这两个 action 链接起来，定义二者之间的关系（登录失败后尝试验证用户信息是否足够直接注册，足够则继续请求注册接口，不足够则跳转至补充信息页面）。代码如下：
103 |
104 | ```javascript
105 | function redirectToPage(redirectUrl) {
106 | return {
107 | type: 'APP_REDIRECT_USER',
108 | payload: redirectUrl,
109 | }
110 | }
111 |
112 | function loginWithFacebook(facebookId, facebookToken) {
113 | return createAsyncAction('APP_LOGIN_WITH_FACEBOOK', () => (
114 | api.post('/auth/facebook', {
115 | facebook_id: facebookId,
116 | facebook_token: facebookToken,
117 | })
118 | ));
119 | }
120 |
121 | function signupWithFacebook(facebookId, facebookToken, facebookEmail) {
122 | if (!facebookEmail) {
123 | redirectToPage('/fill-in-details');
124 | }
125 |
126 | return createAsyncAction('APP_SIGNUP_WITH_FACEBOOK', () => (
127 | api.post('/accounts', {
128 | authentication_type: 'facebook',
129 | facebook_id: facebookId,
130 | facebook_token: facebookToken,
131 | email: facebookEmail,
132 | })
133 | ));
134 | }
135 |
136 | function connectWithFacebook(facebookId, facebookToken, facebookEmail) {
137 | const firstAction = loginWithFacebook(facebookId, facebookToken);
138 | const callbackAction = signupWithFacebook(facebookId, facebookToken, facebookEmail);
139 |
140 | const handlers = [{
141 | status: 'success',
142 | callback: () => (() => {}), // 用户登陆成功
143 | }, {
144 | status: 'error',
145 | callback: callbackAction, // 使用 facebook 账户登陆失败，尝试帮用户注册新账户
146 | }];
147 |
148 | return createChainedAsyncAction(firstAction, handlers);
149 | }
150 | ```
151 |
152 | 这里，只要我们将可复用的 action 拆分到了合适的粒度，并在链式 action 中将他们按照业务逻辑组合起来之后，Redux 就会在不同的情况下 dispatch 不同的 action。可能的几种情况如下：
153 |
154 | ```text
155 | // 直接登录成功
156 | APP_LOGIN_WITH_FACEBOOK_REQUEST
157 | APP_LOGIN_WITH_FACEBOOK_SUCCESS
158 |
159 | // 直接登录失败，注册信息充足
160 | APP_LOGIN_WITH_FACEBOOK_REQUEST
161 | APP_LOGIN_WITH_FACEBOOK_ERROR
162 | APP_SIGNUP_WITH_FACEBOOK_REQUEST
163 | APP_LOGIN_WITH_FACEBOOK_SUCCESS
164 |
165 | // 直接登录失败，注册信息不足
166 | APP_LOGIN_WITH_FACEBOOK_REQUEST
167 | APP_LOGIN_WITH_FACEBOOK_ERROR
168 | APP_REDIRECT_USER
169 | ```
170 |
171 | 于是，在 reducer 中，我们只要在相应的 action 被 dispatch 时，对 ViewModel 中的数据做相应的更改即可，也就做到了业务逻辑与显示逻辑相分离。
172 |
173 | 这一解法与 MobX 及 RxJS 有相同又有不同。相同的是都定义好了数据的流动方式（action 的 dispatch 顺序），在合适的时候通知 ViewModel 去更新数据，不同的是 Redux 不会在某个数据变动时自动触发某条数据管道，而是需要使用者显式地去调用某一条数据管道，如上述例子中，在用户点击『连接社交网络』按钮时。综合起来和 redux-observable 的思路可能更为一致，即没有完全抛弃 redux，又引入了数据管道的概念，只是限于工具函数的不足，无法处理更复杂的场景。但从另一方面来说，如果业务中确实没有非常复杂的场景，在理解了 redux 之后，使用最简单的 redux-thunk 就可以完美地覆盖到绝大部分需求。
174 |
175 | ### 业务逻辑臃肿
176 | 拆分并组合可复用的 action 解决了一部分的业务逻辑，但另一方面，Model 层的数据需要通过组合及格式化后才能成为 ViewModel 的一部分，也是困扰前端开发的一大难题。
177 |
178 | 这里推荐使用抽象出通用的 **Selector** 和 **Formatter** 的概念来解决这一问题。
179 |
180 | 上面我们提到了，后端的 Model 会随着接口直接进入到各个页面的 reducer，这时我们就可以通过 Selector 来组合不同 reducer 中的数据，并通过 Formatter 将最终的数据格式化为可以直接显示在 View 上的数据。
181 |
182 | 举个例子，在用户的个人中心页面，我们需要显示用户在各个分类下喜欢过的回答，于是我们需要先获取所有的分类，并在所有分类前加上一个后端并不存在的『热门』分类。又因为分类是一个非常常用的数据，所以我们之前已经在首页获取过并存在了首页的 reducer 中。代码如下：
183 |
184 | ```javascript
185 | // src/views/account/formatter.js
186 | import orderBy from 'lodash/orderBy';
187 |
188 | function categoriesFormatter(categories) {
189 | const customCategories = orderBy(categories, 'priority');
190 | const popular = {
191 | id: 0,
192 | name: '热门',
193 | shortname: 'popular',
194 | };
195 | customCategories.unshift(popular);
196 |
197 | return customCategories;
198 | }
199 |
200 | // src/views/account/selector.js
201 | import formatter from './formatter.js';
202 | import homeSelector from '../home/selector.js';
203 |
204 | const categoriesWithPopularSelector = state =>
205 | formatter.categoriesFormatter(homeSelector.categoriesSelector(state));
206 |
207 | export default {
208 | categoriesWithPopularSelector,
209 | };
210 | ```
211 |
212 | 在明确了 ViewModel 层需要解决的问题后，有针对性地去复用并组合 action，selector，formatter 就可以得到一个思路非常清晰的解决方案。在保证所有数据都只在相应的 reducer 中存储一份的前提下，各个页面数据不一致的问题也迎刃而解。反过来说，数据不一致问题的根源就是代码的可复用性太低，才导致了同一份数据以不同的方式流入了不同的数据管道并最终得到了不同的结果。
213 |
214 | ## View 层
215 | 在理清楚前面两层之后，作为前端最重要的 View 层反而简单了许多，通过 `mapStateToProps` 和 `mapDispatchToProps`，我们就可以将粒度极细的显示数据与组合完毕的业务逻辑直接映射到 View 层的相应位置，从而得到一个纯净，易调试的 View 层。
216 |
217 | ### 可复用 View
218 | 但问题好像又并没有那么简单，因为 View 层的可复用性也是困扰前端的一大难题，基于以上思路，我们又该怎样处理呢？
219 |
220 | 受益于 React 等框架，前端组件化不再是一个问题，我们也只需要遵守以下几个原则，就可以较好地实现 View 层的复用。
221 |
222 | * 所有的页面都隶属于一个文件夹，只有页面级别的组件才会被 connect 到 redux store。每个页面又都是一个独立的文件夹，存放自己的 action，reducer，selector 及 formatter。
223 | * components 文件夹中存放业务组件，业务组件不会被 connect 到 redux store，只能从 props 中获取数据，从而保证其可维护性与可复用性。
224 | * 另一个文件夹或 npm 包中存放 UI 组件，UI 组件与业务无关，只包含显示逻辑，不包含业务逻辑。
225 |
226 | ## 小结
227 | 虽然说开发灵活易用的组件库是一件非常难的事情，但在积累了足够多的可复用的业务组件及 UI 组件之后，新的页面在数据层面，又可以从其他页面的 action，selector，formatter 中寻找可复用的业务逻辑时，新需求的开发速度应当是越来越快的。而不是越来越多的业务逻辑与显示逻辑交织在一起，最终导致整个项目内部复杂度过高无法维护后只能推倒重来。
228 |
229 | ## 一点心得
230 | 在新技术层出不穷的今天，在我们执着于说服别人接受自己的技术观点时，我们还是需要回到当前业务场景下，去看一看要解决的到底是一个什么样的问题。
231 |
232 | 抛去少部分极端复杂的前端应用来看，目前大部分的前端应用都还是以展示数据为主，在这样的场景下，再前沿的技术与框架都无法直接解决上面提到的这些问题，反倒是一套清晰的数据处理思路及对核心概念的深入理解，再配合上严谨的团队开发规范才有可能将深陷复杂数据泥潭的前端开发者们拯救出来。
233 |
234 | 作为工程学的一个分支，软件工程的复杂度从来都不在于那些无法解决的难题，而是如何制定简单的规则让不同的模块各司其职。这也是为什么在各种框架，库，解决方案层出不穷的今天，我们还是在强调基础，强调经验，强调要看到问题的本质。
235 |
236 | 王阳明所说的知行合一，现代人往往是知道却做不到。但在软件工程方面，我们又常常会陷入照猫画虎地做到了，却并不理解其中原理的另一极端，而这二者显然都是不可取的。
--------------------------------------------------------------------------------
/2016/重新设计 React 组件库/重新设计 React 组件库.md:
--------------------------------------------------------------------------------
1 | # 重新设计 React 组件库
2 | 在 react + redux 已经成为大部分前端项目底层架构的今天，让我们再回到软件工程界一个永恒的问题上来，那就是如何提升一个开发团队的开发效率？
3 | 从宏观的角度来讲，只有对具体业务的良好抽象才能真正提高一个团队的开发效率，又囿于不同产品所面临的不同业务需求，当我们抽丝剥茧般地将一个个前端项目抽象到最后一层，那么剩下的就只有按钮、输入框、对话框、图标等这些毫无业务意义的纯 UI 组件了。
4 |
5 | 选择或开发一套适合自己团队使用的 UI 组件库应该是每一个前端团队在底层架构达成共识后下一件就要去做的事情，那么我们就以今天为始，分别从以下几个方面来探讨如何构建一套优秀的 UI 组件库。
6 |
7 | ## 第一个问题：选择开源 vs 自己造轮子
8 | 在 React 界，优秀且开源的 UI 组件库有很多，国外的如 [Material-UI](http://www.material-ui.com/)，国内的如 [Ant Design](https://ant.design/)，都是经过众多使用者检验，组件丰富且代码质量过硬的组件库。所以当我们决定再造一套 UI 组件库之前，不妨先尝试下这些在 UI 组件库界口碑良好的标品，再决定是否要进入这个看似简单实则困难重重的领域。
9 |
10 | 在这里，我们并不会去比较任何组件库之间的区别或优劣，但却可以从产品层面给出几个开发自有组
11 | 件库的判断依据，以供参考。
12 |
13 | * 产品有独立的设计规范，包括但不限于组件样式、交互模式。
14 | * 产品业务场景较为复杂，需要深度定制某些常用组件。
15 | * 前端团队需要同时支撑多条业务线。
16 |
17 | ## 设计思想：规范 vs. 自由
18 | 在选择了自己造轮子这样一条路之后，下一个摆在面前的艰难选择就是，要造一个规范的组件库还是一个自由的组件库？
19 |
20 | 规范的组件库可以从源码层面保证产品视觉、交互风格的一致性，也可以很大程度上降低业务开发的复杂度，从而提升团队整体的开发效率。但在遇到一些看似相似实则不同的业务需求时，规范的组件库往往会走入一个难以避免的死循环，那就是实现 A 需求需要使用 a 组件，但是现有的 a 组件又不能完全支持 A 需求。
21 |
22 | 这时摆在工程师面前的就只有两条路：
23 |
24 | * 重新开发一个完美支持 A 需求的 a+ 组件
25 | * 修改 a 组件源码使其支持 A 需求
26 |
27 | 方法一费时费力，会极大地增加本次项目的开发成本，而方法二又会导致 a 组件代码膨胀速度过快且逻辑复杂，极大地增加组件库后期的维护成本。
28 |
29 | 在多次陷入上面所描述的这个困境之后，在最近的一次内部组件库重构时，我们选择了拥抱自由，这其中既有业务方面的考虑，也有 React 在组件自由组合方面的天然优势，让我们来看一个例子。
30 |
31 | ### Select
32 |
33 | ```javascript
34 | // traditional select
35 |
36 |
41 | {value}
42 |
43 |
44 | {menu}
45 |
57 | {
58 | children
59 | ||
60 |
61 |
62 | {label ? {label} : null}
63 |
64 | {currentValue !== '' ? currentValue : selectPlaceholder}
65 |
66 |
67 |
68 |
69 | }
70 | {this.renderPopup()}
71 |
72 | ```
73 |
74 | 在支持传统的文字加箭头之外，更自由的 Select 添加了对 label 及 children 支持，分别可以对应有名称的 Select
75 |
76 | 
77 |
78 | 及类似前面提到的自定义元素。
79 |
80 | ### Dropdown
81 |
82 | 类似的还有 Select 的孪生兄弟 Dropdown。
83 |
84 | ```javascript
85 | // Customizeable Dropdown
86 |
87 | {data.map((value, idx) => {
88 | return (
89 |
95 | );
96 | })}
97 |
98 |
99 | // Using Dropdown
100 | const demoData = [{ text: 'Robb Stark', age: 36 }]
101 | const DropdownItem = (props) => (
102 |
103 |
{props.data.text}
104 |
is {props.data.age} years old.
105 |
{ this.container = node; }}
54 | >
55 | {this.renderSildeList()}
56 | {this.renderDots()}
57 |
58 | );
59 | }
60 | ```
61 |
62 | 至此，我们只需要改变轮播组件中的 `currentIndex`，即可间接改变 `SlideList` 的 `translateX`，以此实现轮播元素之间的切换。
63 |
64 | ### 响应用户操作
65 | 轮播作为一个常见的通用组件，在桌面和移动端都有着非常广泛的应用，这里我们先以移动端为例，来阐述如何响应用户操作。
66 |
67 | ```javascript
68 | {map(children, (child, i) => (
69 |
78 | {child}
79 |
80 | ))}
81 | ```
82 |
83 | 在移动端，我们需要监听三个事件，分别响应滑动开始，滑动中与滑动结束。其中滑动开始与滑动结束都是一次性事件，而滑动中则是持续性事件，以此我们可以确定在三个事件中我们分别需要确定哪些值。
84 |
85 | #### 滑动开始
86 | * startPositionX：此次滑动的起始位置
87 |
88 | ```javascript
89 | handleTouchStart = (e) => {
90 | const { x } = getPosition(e);
91 | this.setState({
92 | startPositionX: x,
93 | });
94 | }
95 | ```
96 |
97 | #### 滑动中
98 | * moveDeltaX：此次滑动的实时距离
99 | * direction：此次滑动的实时方向
100 | * translateX：此次滑动中轨道的实时位置，用于渲染
101 |
102 | ```javascript
103 | handleTouchMove = (e) => {
104 | const { width, currentIndex, startPositionX } = this.state;
105 | const { x } = getPosition(e);
106 |
107 | const deltaX = x - startPositionX;
108 | const direction = deltaX > 0 ? 'right' : 'left';
109 | this.setState({
110 | moveDeltaX: deltaX,
111 | direction,
112 | translateX: -(width * currentIndex) + deltaX,
113 | });
114 | }
115 | ```
116 |
117 | #### 滑动结束
118 | * currentIndex：此次滑动结束后新的 currentIndex
119 | * endValue：此次滑动结束后轨道的 translateX
120 |
121 | ```javascript
122 | handleTouchEnd = () => {
123 | this.handleSwipe();
124 | }
125 |
126 | handleSwipe = () => {
127 | const { children, speed } = this.props;
128 | const { width, currentIndex, direction, translateX } = this.state;
129 | const count = size(children);
130 |
131 | let newIndex;
132 | let endValue;
133 | if (direction === 'left') {
134 | newIndex = currentIndex !== count ? currentIndex + 1 : START_INDEX;
135 | endValue = -(width) * (currentIndex + 1);
136 | } else {
137 | newIndex = currentIndex !== START_INDEX ? currentIndex - 1 : count;
138 | endValue = -(width) * (currentIndex - 1);
139 | }
140 |
141 | const tweenQueue = this.getTweenQueue(translateX, endValue, speed);
142 | this.rafId = requestAnimationFrame(() => this.animation(tweenQueue, newIndex));
143 | }
144 | ```
145 |
146 | 因为我们在滑动中会实时更新轨道的 translateX，我们的轮播组件便可以做到**跟手**的用户体验，即在单次滑动中，轮播元素会跟随用户的操作向左或向右滑动。
147 |
148 | ### 实现顺滑的切换动画
149 | 在实现了滑动中跟手的用户体验后，我们还需要在滑动结束后将显示的轮播元素定位到新的 `currentIndex`。根据用户的滑动方向，我们可以对当前的 `currentIndex` 进行 +1 或 -1 以得到新的 `currentIndex`。但在处理第一个元素向左滑动或最后一个元素向右滑动时，新的 `currentIndex` 需要更新为最后一个或第一个。
150 |
151 | 这里的逻辑并不复杂，但却带来了一个非常难以解决的用户体验问题，那就是假设我们有 3 个轮播元素，每个轮播元素的宽度都为 300px，即显示最后一个元素时，轨道的 translateX 为 -600px，在我们将最后一个元素向左滑动后，轨道的 translateX 将被重新定义为 0px，此时若我们使用原生的 CSS 动画：
152 |
153 | ```css
154 | transition: 1s ease-in-out;
155 | ```
156 |
157 | 轨道将会在一秒内从左向右滑动至第一个轮播元素，而这是反直觉的，因为用户一个向左滑动的操作导致了一个向右的动画，反之亦然。
158 |
159 | 这个问题从上古时期就困扰着许多前端开发者，笔者也见过以下几种解决问题的方法：
160 |
161 | * 将轨道宽度定义为无限长（几百万 px），无限次重复有限的轮播元素。这种解决方案显然是一种 hack，并没有从实质上解决轮播组件的问题。
162 | * 只渲染三个轮播元素，即前一个，当前一个，下一个，每次滑动后同时更新三个元素。这种解决方案实现起来非常复杂，因为组件内部要维护的状态从一个 currentIndex 增加到了三个拥有各自状态的 DOM 元素，且因为要不停的删除和新增 DOm 节点导致性能不佳。
163 |
164 | 这里让我们再来思考一下滑动操作的本质。除去第一和最后两个元素，所有中间元素滑动后新的 translateX 的值都是固定的，即 `-(width * currentIndex)`，这种情况下的动画都可以轻松地完美实现。而在最后一个元素向左滑动时，因为轨道的 `translateX` 已经到达了极限，面对这种情况我们如何才能实现顺滑的切换动画呢？
165 |
166 | 这里我们选择将最后一个及第一个元素分别拼接至轨道的头尾，以保证在 DOM 结构不需要改变的前提下实现顺滑的切换动画：
167 |
168 | 
169 |
170 | 这样我们就统一了每次滑动结束后 `endValue` 的计算方式，即
171 |
172 | ```javascript
173 | // left
174 | endValue = -(width) * (currentIndex + 1)
175 |
176 | // right
177 | endValue = -(width) * (currentIndex - 1)
178 | ```
179 |
180 | ### 使用 requestAnimationFrame 实现高性能动画
181 | `requestAnimationFrame` 是浏览器提供的一个专注于实现动画的 API，感兴趣的朋友可以再重温一下[《React Motion 缓动函数剖析》](https://zhuanlan.zhihu.com/p/20458251)这篇专栏。
182 |
183 | 所有的动画本质上都是一连串的时间轴上的值，具体到轮播场景下即：以用户停止滑动时的值为起始值，以新 `currentIndex` 时 `translateX` 的值为结束值，在使用者设定的动画时间（如0.5秒）内，依据使用者设定的缓动函数，计算每一帧动画时的 `translateX` 值并最终得到一个数组，以每秒 60 帧的速度更新在轨道的 `style` 属性上。每更新一次，将消耗掉动画值数组中的一个中间值，直到数组中所有的中间值被消耗完毕，动画结束并触发回调。
184 |
185 | 具体代码如下：
186 |
187 | ```javascript
188 | const FPS = 60;
189 | const UPDATE_INTERVAL = 1000 / FPS;
190 |
191 | animation = (tweenQueue, newIndex) => {
192 | if (isEmpty(tweenQueue)) {
193 | this.handleOperationEnd(newIndex);
194 | return;
195 | }
196 |
197 | this.setState({
198 | translateX: head(tweenQueue),
199 | });
200 | tweenQueue.shift();
201 | this.rafId = requestAnimationFrame(() => this.animation(tweenQueue, newIndex));
202 | }
203 |
204 | getTweenQueue = (beginValue, endValue, speed) => {
205 | const tweenQueue = [];
206 | const updateTimes = speed / UPDATE_INTERVAL;
207 | for (let i = 0; i < updateTimes; i += 1) {
208 | tweenQueue.push(
209 | tweenFunctions.easeInOutQuad(UPDATE_INTERVAL * i, beginValue, endValue, speed),
210 | );
211 | }
212 | return tweenQueue;
213 | }
214 | ```
215 |
216 | 在回调函数中，根据变动逻辑统一确定组件当前新的稳定态值：
217 |
218 | ```javascript
219 | handleOperationEnd = (newIndex) => {
220 | const { width } = this.state;
221 |
222 | this.setState({
223 | currentIndex: newIndex,
224 | translateX: -(width) * newIndex,
225 | startPositionX: 0,
226 | moveDeltaX: 0,
227 | dragging: false,
228 | direction: null,
229 | });
230 | }
231 | ```
232 |
233 | 完成后的轮播组件效果如下图：
234 |
235 | 
236 |
237 | ### 优雅地处理特殊情况
238 | * 处理用户误触：在移动端，用户经常会误触到轮播组件，即有时手不小心滑过或点击时也会触发 `onTouch` 类事件。对此我们可以采取对滑动距离添加阈值的方式来避免用户误触，阈值可以是轮播元素宽度的 10% 或其他合理值，在每次滑动距离超过阈值时，才会触发轮播组件后续的滑动。
239 | * 桌面端适配：对于桌面端而言，轮播组件所需要响应的事件名称与移动端是完全不同的，但又可以相对应地匹配起来。这里还需要注意的是，我们需要为轮播组件添加一个 dragging 的状态来区分移动端与桌面端，从而安全地复用 handler 部分的代码。
240 |
241 | ```javascript
242 | // mobile
243 | onTouchStart={this.handleTouchStart}
244 | onTouchMove={this.handleTouchMove}
245 | onTouchEnd={this.handleTouchEnd}
246 | // desktop
247 | onMouseDown={this.handleMouseDown}
248 | onMouseMove={this.handleMouseMove}
249 | onMouseUp={this.handleMouseUp}
250 | onMouseLeave={this.handleMouseLeave}
251 | onMouseOver={this.handleMouseOver}
252 | onMouseOut={this.handleMouseOut}
253 | onFocus={this.handleMouseOver}
254 | onBlur={this.handleMouseOut}
255 |
256 | handleMouseDown = (evt) => {
257 | evt.preventDefault();
258 | this.setState({
259 | dragging: true,
260 | });
261 | this.handleTouchStart(evt);
262 | }
263 |
264 | handleMouseMove = (evt) => {
265 | if (!this.state.dragging) {
266 | return;
267 | }
268 | this.handleTouchMove(evt);
269 | }
270 |
271 | handleMouseUp = () => {
272 | if (!this.state.dragging) {
273 | return;
274 | }
275 | this.handleTouchEnd();
276 | }
277 |
278 | handleMouseLeave = () => {
279 | if (!this.state.dragging) {
280 | return;
281 | }
282 | this.handleTouchEnd();
283 | }
284 |
285 | handleMouseOver = () => {
286 | if (this.props.autoPlay) {
287 | clearInterval(this.autoPlayTimer);
288 | }
289 | }
290 |
291 | handleMouseOut = () => {
292 | if (this.props.autoPlay) {
293 | this.autoPlay();
294 | }
295 | }
296 | ```
297 |
298 | ## 小结
299 | 至此我们就实现了一个只有 `tween-functions` 一个第三方依赖的轮播组件，打包后大小不过 2KB，完整的源码大家可以参考这里 [carousel/index.js](https://github.com/AlanWei/sea-ui/blob/master/components/carousel/index.js)。
300 |
301 | 除了节省的代码体积，更让我们欣喜的还是彻底弄清楚了轮播组件的实现模式以及如何使用 `requestAnimationFrame` 配合 `setState` 来在 react 中完成一组动画。
302 |
303 | ## 感想
304 |
305 | 
306 |
307 | 大家应该都看过上面这幅漫画，有趣之余也蕴含着一个朴素却深刻的道理，那就是在解决一个复杂问题时，最重要的是思路，但仅仅有思路也仍是远远不够的，还需要具体的执行方案。这个具体的执行方案，必须是连续的，其中不可以欠缺任何一环，不可以有任何思路或执行上的跳跃。所以解决任何复杂问题都没有银弹也没有捷径，我们必须把它弄清楚，搞明白，然后才能真正地解决它。
308 |
309 | 至此，组件库设计实战系列文章也将告一段落。在全部四篇文章中，我们分别讨论了组件库架构，组件分类，文档组织，国际化以及复杂组件设计这几个核心的话题，因笔者能力所限，其中自然有许多不足之处，烦请各位谅解。
310 |
311 | 组件库作为提升前端团队工作效率的重中之重，花再多时间去研究它都不为过。再加上与设计团队对接，形成设计语言，与后端团队对接，统一数据结构，组件库也可以说是前端工程师在拓展自身工作领域上的必经之路。
312 |
313 | **不要害怕重复造轮子，关键是每造一次轮子后，从中学到了什么。**
314 |
315 | 与各位共勉。
--------------------------------------------------------------------------------
/2018/从新的 Context API 看 React 应用设计模式/从新的 Context API 看 React 应用设计模式.md:
--------------------------------------------------------------------------------
1 | # 从新的 Context API 看 React 应用设计模式
2 | 在即将发布的 React v16.3.0 中，React 引入了新的声明式的，可透传 props 的 [Context API](https://github.com/facebook/react/pull/11818)，对于新版 Context API 还不太了解朋友可以看一下笔者之前的一个[回答](https://www.zhihu.com/question/267168180/answer/319754359)。
3 |
4 | 受益于这次改动，React 开发者终于拥有了一个官方提供的安全稳定的 global store，子组件跨层级获取父组件数据及后续的更新都不再成为一个问题。这让我们不禁开始思考，相较于 Redux 等其他的第三方数据（状态）管理工具，使用 Context API 这种 vanilla React 支持的方式是不是一个更好的选择呢？
5 |
6 | ## Context vs. Redux
7 | 在 react + redux 已经成为了开始一个 React 项目标配的今天，我们似乎忘记了其实 react 本身是可以使用 state 和 props 来管理数据的，甚至对于目前市面上大部分的应用来说，对 redux 的不正确使用实际上增加了应用整体的复杂度及代码量。
8 |
9 | ### Vanilla React Global Store
10 | ```javascript
11 | import React from "react";
12 | import { render } from "react-dom";
13 |
14 | const initialState = {
15 | theme: "dark",
16 | color: "blue"
17 | };
18 |
19 | const GlobalStoreContext = React.createContext({
20 | ...initialState
21 | });
22 |
23 | class GlobalStoreContextProvider extends React.Component {
24 | // initialState
25 | state = {
26 | ...initialState
27 | };
28 |
29 | // reducer
30 | handleContextChange = action => {
31 | switch (action.type) {
32 | case "UPDATE_THEME":
33 | return this.setState({
34 | theme: action.theme
35 | });
36 | case "UPDATE_COLOR":
37 | return this.setState({
38 | color: action.color
39 | });
40 | case "UPDATE_THEME_THEN_COLOR":
41 | return new Promise(resolve => {
42 | resolve(action.theme);
43 | })
44 | .then(theme => {
45 | this.setState({
46 | theme
47 | });
48 | return action.color;
49 | })
50 | .then(color => {
51 | this.setState({
52 | color
53 | });
54 | });
55 | default:
56 | return;
57 | }
58 | };
59 |
60 | render() {
61 | return (
62 |
69 | {this.props.children}
70 |
71 | );
72 | }
73 | }
74 |
75 | const SubComponent = props => (
76 |
77 | {/* action */}
78 |
88 |
{props.theme}
89 | {/* action */}
90 |
100 |
{props.color}
101 | {/* action */}
102 |
113 |
246 |
247 | {props.theme} and {props.language}
248 |
249 | {props.todos.map((todo, idx) =>
{todo}
)}
250 |
251 |
301 |
302 | {props.theme} and {props.language}
303 |
304 | {props.todos.map((todo, idx) =>
{todo}
)}
305 |
306 |