Re: [討論] 現在寫RN的都準備跳Flutter啦？

[FrAnKw (hard to believe)]

※ 引述《FrAnKw (hard to believe)》之銘言：
: 不過基本上Redux的時代已經過去了 現在我們新的案子已經完全使用hooks
: 而且管理global state的方式也找到更好的solution

: 推 errorsyntax: 推，也想了解 redux 的替代方案                      09/01 13:15

很榮幸這篇文起到拋磚引玉的效果
有版友也在推文下面討論Angular的內容 挺好的！


關於Redux替代的部分
我們公司目前是使用Apollo Client
他是一套GrpahQL的解決方案 要搭配GraphQL的後端來使用
但其實若您目前專案是使用RESTFul也不是不行使用
因為Apollo有一套package可以把Rest api轉成GraphQL的

https://www.apollographql.com/docs/link/links/rest/


只是這種偏底層打地基的東西可能要在案子一開始跑時就要先訂好了
或許下一個案子可以參考看看

至於實作方法
因為Apollo Client裡面有cache的機制
他可以用writeData這個方法 來複寫由query要進來的資料
或者使用writeQuery這個方法 來無中生有建立一個由client產生的query object

結合以上 使用情境上就可以做到
create/update 都可以共用同一組資料結構
而改動的狀態 會被直接記在cache裡面
https://www.apollographql.com/docs/react/advanced/caching/

只要用的GraphQL查詢是一樣的名字(盡量不要使用匿名查詢)
那你在cache裡面拿到的就會是被保存下來的state

不過要注意的地方是
Apollo Server每一個object的結構都會預設帶一個基礎的property叫做__typename
從後端要來的資料都會預設自動帶上這個欄位
要共用結構的話 在writeQuery時要把這個prop補上 不然它會報錯 並且不能寫入
目前我是做了一個遞迴的方式在資料建立時自動補
或許之後研究一下Apollo Server可以不傳這個__typename的話
應該連補都不用了

我的實作方式是把useQuery這個hook做了一個包裹
包含了useQuery原先已有的東西之外
再把writeData/writeQuery上述所講的東西 實作完後一起暴露出來
用過的同事都說好爽好棒棒
可以少寫很多code

公司同事也有使用這個套件
https://github.com/apollographql/apollo-cache-persist
用來存放一些偏靜態的資料

另外一些公用的組件
例如modal, breadcrumb之類的東西
我們會使用HOC 然後這些小玩意會有自己的內部狀態或是使用Context

其實多去研究一下Redux的原理就可以發現
它的實作原理就是透過HOC加上context做出來的
這些共用小元件基本上方法也是類似Redux 只是他的影響範圍只限於他自己本身而已
大概是這樣子 歡迎提問討論

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.133.91.72 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1567336936.A.B28.html
※ 編輯: FrAnKw (220.133.91.72 臺灣), 09/01/2019 19:28:14
推 illl: 請問是因為要offline use才用grapgql管locla state嗎？ 如
→ illl: 果local state跟graphql拿到的資料不相關感覺還是用redux或
→ illl: context比較簡單？
→ FrAnKw: 會用graphql管local state是因為這樣component端就不用轉
→ FrAnKw: 內部狀態了 個人覺得這樣比較方便簡潔
→ FrAnKw: 至於你說的第二點也沒錯 可以使用別的方式儲存
→ FrAnKw: 或者GraphQL的writeQuery也可以自定義結構 就跟api結構
→ FrAnKw: 無關了
推 iDeepLearn56: 謝謝分享
推 dreamnook: 最近公司也想搞graphql 謝分享