摘要:現(xiàn)已存在許多成熟的狀態(tài)管理解決方案,還有基于的但對(duì)于我個(gè)人來(lái)說(shuō),理想的狀態(tài)管理工具只需同時(shí)滿足兩個(gè)特點(diǎn)簡(jiǎn)單易用,并且適合中大型項(xiàng)目完美地支持要做到這兩點(diǎn)其實(shí)并不簡(jiǎn)單。所以我決定自己造一個(gè)可能是基于和最好的狀態(tài)管理工具
現(xiàn)已存在許多成熟的狀態(tài)管理解決方案:Redux、Mobx、Mobx-state-tree,還有基于 Redux 的 Dva.js、Rematch... 但對(duì)于我個(gè)人來(lái)說(shuō),理想的狀態(tài)管理工具只需同時(shí)滿足兩個(gè)特點(diǎn):
簡(jiǎn)單易用,并且適合中大型項(xiàng)目
完美地支持 Typescript
要做到這兩點(diǎn)其實(shí)并不簡(jiǎn)單。
首先說(shuō)說(shuō) “簡(jiǎn)單易用,并且適合中大型項(xiàng)目”,這里包含層含義:
Api 足夠簡(jiǎn)單,盡量引入少的概念
易用性高,使用者易用上手,較少的冗余代碼
能讓使用者更容易的寫(xiě)出可維護(hù)性高的代碼
能讓業(yè)務(wù)代碼有良好地組織方式
怎么才能算是簡(jiǎn)單易用呢?用一個(gè)叫 reworm 的狀態(tài)管理庫(kù)來(lái)舉例,它的使用方式是這樣的:
import React from "react"; import { Provider, create } from "reworm"; const { set, get } = create({ name: "John" }); class App extends React.Component { componentDidMount() { set(prev => ({ name: "Peter" + prev.name })); } render() { return (); } } {get(s => s.name)}
我碰巧寫(xiě)寫(xiě)過(guò)一個(gè)類似狀態(tài)管理庫(kù),叫 mistate,甚至更簡(jiǎn)單,連 Provider 都不用,實(shí)現(xiàn)代碼也只有 40 行。用法如下:
import React from "react"; import { create } from "mistate"; const { get, set } = create({ count: 0 }); const App = () => ({get(s => s.text)});
它們足夠簡(jiǎn)單,非常容易上手,但是它們致命是缺點(diǎn)是并不適合中大型項(xiàng)目,它們自由度太高,缺乏對(duì)業(yè)務(wù)代碼的約束,在多人合作的中大型項(xiàng)目,代碼的可維護(hù)性會(huì)大大降低,因?yàn)槊總€(gè)人寫(xiě)的代碼風(fēng)格可能都不一樣。舉個(gè)例子,有些人可能會(huì)直接在 Component 中使用 set,有些人可能會(huì)基于 set 封裝成一個(gè)個(gè) acton:
import React from "react"; import { create } from "mistate"; const { get, set } = create({ count: 0 }); const actions = { increment() { set(prev => ({ count: prev.count++ }) }, decrement() { set(prev => ({ count: prev.count-- }) }, } const App = () => ({get(s => s.text)});
這種自由度雖然靈活度高,但是降低了代碼的可維護(hù)性。
另外,用 render props 獲取 state 看似比 Redux 的 Connect 簡(jiǎn)單,但其實(shí)并不優(yōu)雅,比如一個(gè)很常見(jiàn)的獲取多個(gè) state,使用 render props 可能要這樣:
const Counter = create({ count: 0 }); const User = create({ name: "foo" }); const Todo = create({ todos: [] }); const App = () => ({User.get(user => ();{user.name}))}{Todo.get(todo => ({todo.todos.map(item => {))}{item.name}; {Counter.get(s => s.count)}; })}
多個(gè) render props 的嵌套會(huì)導(dǎo)致 callback hell 類似結(jié)果,直接讓你的代碼反人類。
上面說(shuō)完了 “簡(jiǎn)單易用”,下面聊聊 “適合中大型項(xiàng)目”。當(dāng)然,我心目中的 “適合中大型項(xiàng)目” 的前提是 “簡(jiǎn)單易用”,否者我并不會(huì)選擇它。
首先上面面說(shuō)的 reworm 和 mistate 并不適合在中大型項(xiàng)目中使用,他們適合用在小型項(xiàng)目,比如一個(gè)簡(jiǎn)單的營(yíng)銷活動(dòng),還以非常適合的場(chǎng)景就是在工具類庫(kù)中使用,因?yàn)樗鼈冏銐蚝?jiǎn)單、輕量。
再說(shuō)說(shuō)大家熟悉 Redux 和 Mobx,首先是 Redux ,我個(gè)人認(rèn)為 Redux 確實(shí)滿足 “適合中大型項(xiàng)目”,因?yàn)槭褂谜邘缀醵紩?huì)按照它推薦的方式來(lái)組織代碼,但它不滿足 “簡(jiǎn)單易用”,太過(guò)于繁瑣,使用起來(lái)有種吃*的感覺(jué)(本人沒(méi)吃過(guò)~)。然后是 Mobx,個(gè)人挺喜歡,挺 “簡(jiǎn)單易用”,對(duì)使用者寫(xiě)出的代碼有一定的限制,但感覺(jué)又太過(guò)于自由,并且非 Immutable,給人感覺(jué)是一個(gè)很中庸的解決方案。
在滿足 “簡(jiǎn)單易用,并且適合中大型項(xiàng)目” 的前提下,個(gè)人比較喜歡的狀態(tài)管理解決方案是: dva、rematch、mirror,三者都是基于 Redux 開(kāi)發(fā),他們的 Api 相似度極高,簡(jiǎn)化了 Redux 的使用,使得代碼組織方更加合理,通俗的說(shuō)就是為 Redux 用戶提供了最舒服的套路去寫(xiě)代碼,可以說(shuō)是當(dāng)前 Redux 社區(qū)中的最佳實(shí)踐。
看看他們是如何組織代碼,以 mirror 來(lái)舉例:
import React from "react" import mirror, {actions, connect, render} from "mirrorx" // declare Redux state, reducers and actions, // all actions will be added to `actions`. mirror.model({ name: "app", initialState: 0, reducers: { increment(state) { return state + 1 }, decrement(state) { return state - 1 } }, effects: { async incrementAsync() { await new Promise((resolve, reject) => { setTimeout(() => { resolve() }, 1000) }) actions.app.increment() } } }) // connect state with component const App = connect(state => { return {count: state.app} })(props => () ) // start the app,`render` is an enhanced `ReactDOM.render` render({props.count}
{/* dispatch the actions */} {/* dispatch the async action */}, document.getElementById("root"))
可以看出它們核心是把 Redux 分散的 actions 和 reducers 合并在一個(gè)地方,并減少了樣板代碼,而且自帶異步 action 解決方案,抽象為 effects。
說(shuō)完第一個(gè)特點(diǎn),接下來(lái)是第二個(gè)特點(diǎn):“完美地支持 Typescript”。
為什么我這么這么執(zhí)著于 Typescript,使用過(guò) Typescript 的都應(yīng)該知道,不過(guò)什么規(guī)模的項(xiàng)目,開(kāi)發(fā)體驗(yàn)比使用 Javascript 好太多,沒(méi)入坑的同學(xué)可以去試試。
基于第一特點(diǎn)的篩選,原生 Redux 和 Mobx 已被忽略,對(duì)于dva、rematch、mirror,對(duì) Typescript 支持最好的是 Rematch,它本身也是用 Typescript 寫(xiě)的,遂繼續(xù)忽略 Dva 和 mirror。
在聊 Rematch 和 Typescript 一起使用之前,先了解一下原生 Redux 和 Typescript 怎么一起使用, 用使用頻率最高的 connect 舉個(gè)例子:
interface StateProps { count: number } interface DispatchProps { increment: () => void } interface OwnProps { name: string } export default connect( mapStateToProps, mapDispatchToProps )(MyComponent);
為了 MyComponent 的 props 能有正確的類型斷言,你必須手寫(xiě) StateProps 和 DispatchProps,這是一件很蛋疼的事情,也沒(méi)有體現(xiàn)出使用 Typescript 的優(yōu)勢(shì)所在。理想的應(yīng)該是 connect 之后 MyComponent 的 props 能被自動(dòng)推倒出來(lái),這才是完美的開(kāi)發(fā)體驗(yàn)。但是基于 hoc 的使用方式,這方面貌似暫時(shí)無(wú)解,除非使用 render props,但是 render props 的書(shū)寫(xiě)方式真是有點(diǎn)辣眼睛。
再來(lái)看看 Rematch 和 Typescript 怎么一起使用:
import * as React from "react" import { connect } from "react-redux" import { iRootState, Dispatch } from "./store" const mapState = (state: iRootState) => ({ dolphins: state.dolphins, sharks: state.sharks, }) const mapDispatch = (dispatch: Dispatch) => ({ incrementDolphins: dispatch.dolphins.increment, incrementDolphinsAsync: dispatch.dolphins.incrementAsync, incrementSharks: () => dispatch.sharks.increment(1), incrementSharksAsync: () => dispatch.sharks.incrementAsync(1), incrementSharksAsync2: () => dispatch({ type: "sharks/incrementAsync", payload: 2 }), }) type connectedProps = ReturnType& ReturnType type Props = connectedProps class Count extends React.Component { // .... } export default connect(mapState, mapDispatch)(Count)
跟原生的 Redux 基本大同小異,沒(méi)體現(xiàn) Typescript 的優(yōu)勢(shì),有點(diǎn)強(qiáng)行上 Typescript 的感覺(jué)。
對(duì)我個(gè)人而言 Rematch 也無(wú)法滿足這兩個(gè)特點(diǎn)。
所以, 我決定自己造一個(gè):
stamen: 可能是基于 Hooks 和 Typescript 最好的狀態(tài)管理工具
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://www.ezyhdfw.cn/yun/99268.html
摘要:接上一篇我理想中的狀態(tài)管理工具之前說(shuō),對(duì)于我個(gè)人來(lái)而言,理想的狀態(tài)管理工具只需同時(shí)滿足兩個(gè)特點(diǎn)簡(jiǎn)單易用,并且適合中大型項(xiàng)目完美地支持未能找到一個(gè)完美滿足這兩點(diǎn)的,所以我決定自己造了一個(gè)叫。把分為和兩類是很好的實(shí)踐。 接上一篇:我理想中的狀態(tài)管理工具 之前說(shuō),對(duì)于我個(gè)人來(lái)而言,理想的狀態(tài)管理工具只需同時(shí)滿足兩個(gè)特點(diǎn): 簡(jiǎn)單易用,并且適合中大型項(xiàng)目 完美地支持 Typescript 未...
摘要:燃盡圖的一部分軸圖表的軸始終表示時(shí)間通常以天為單位。閱讀燃盡圖通過(guò)將沖刺進(jìn)度線與指南進(jìn)行比較來(lái)讀取圖。沖刺結(jié)束時(shí)更新進(jìn)度這是一個(gè)團(tuán)隊(duì)的燃盡圖表,它在沖刺審查會(huì)議前一天更新所有狀態(tài)。 什么是燃盡圖? 燃盡圖是在剩余工作和時(shí)間之間繪制的折線圖。Scrum團(tuán)隊(duì)使用這些圖表來(lái)跟蹤他們?cè)趕print中燒毀任務(wù)時(shí)的進(jìn)度。 Burndown圖表相當(dāng)容易理解,但團(tuán)隊(duì)通常很難理解圖表背后的全部含義。 燃...
閱讀 1836·2021-11-11 10:58
閱讀 4522·2021-09-09 09:33
閱讀 1346·2021-08-18 10:23
閱讀 1642·2019-08-30 15:52
閱讀 1816·2019-08-30 11:06
閱讀 1974·2019-08-29 14:03
閱讀 1582·2019-08-26 14:06
閱讀 3093·2019-08-26 10:39