「State」之我見

Binguner 發布于2019-08-22 11:05 / 496人閱讀

摘要：而是假設我們創建的都是一種名為的首類元素，它應當可以作為函數的參數或返回值進行傳遞，而不僅僅只是傳遞其計算值，即滿足其身為的特性可以被其它引用它的函數或對象觀察到它的變化當然，目前中并不存在這樣的首類元素。

原文：what-is-my-state

閱讀前須知

本文獻給對前端狀態管理 state management 有思考的同學。

文章有涉及 函數式編程、響應式編程 概念

原文是 slide，所以是言不成章的。本文為了通順，加了一些過渡。還有，由于 slide 常用于演講，所以文字說明不是很多。我補上了一些個人的理解（以引用塊的樣式），但也不是很多，有時候會再出文章解釋一些術語，如 lens 和 atom 等。

文中的 state 和「狀態」是同義的，有時為了強調和更易于理解，保留了這一術語未翻譯，讀者請自行腦內替換。

本文中的「我」指原作者

口味調查

在我給出我的口味前，下面幾個矛盾，你會怎么選擇？

無狀態 vs 狀態化
程序是基于狀態的，所以它不可能被完全地清除，但它必須被管理起來。

可變狀態 vs 不可變狀態
狀態隨著時間而變化，所以不可變狀態這個說法是自相矛盾的。人們可以在狀態的一個點上捕捉到不可變的值，但狀態本身并不全部不可變。

全局狀態 vs 局部狀態
來自外部的、共享的、全局狀態實際上優于被封裝在內部的本地狀態。這也是本篇文章要討論的要點之一。

前情提要

這篇文章不會提出新發明。

Most papers in computer science describe how their author learned what someone else already knew. — Peter Landin

我們的討論基于我在 Calmm 中的實踐
Calmm 是一個用于編寫響應式 UI 的框架。鼓勵使用外部共享的狀態，和持續可觀察的屬性（continuous observable properties）。

在贊美 Calmm 之前，我們需要達成一些共識

局部狀態有毒

為什么不用事件

本文的目標

希望咱們能從一個嶄新的角度討論 state ?

State 什么是 state

has value，有值

has identity，有索引

can change over time, 隨著時間會變化

狀態管理難在哪里？

值、索引和時間相互交織，索引和時間尤其復雜。

追蹤索引常常導致算法復雜化，比如 React 中的 key

隨著時間變化，依賴于狀態的一些計算會無效化

語言層面的局限

一般的語言（比如 js）對 state 這種數據基本都不做原生支持。

這體現在，在這些語言中：

變量是可變的、對象上的字段也是可變的

根本上來說，是次類元素

無法組合

無法分形（decompose）

無法（隨著時間）響應變化

什么叫次類元素？

這個說法對應于首類元素 first-class，它

無法通過函數返回

無法作為參數傳遞

演示局限

無法（隨著時間）響應變化

let x = 1       // 創建了一個可變的 state
let y = 2
let sum = x + y // 獲取了 state 的快照 snapshot，值為 3

x = 3

sum             // 值還是 3，sum 無法觀察 x 賦值后的值，隨之變化值為 5

state 不是語言中的 first-class 元素

function foo() {
  let x = 1 // 創建可變的 state
  bar(x)    // 無法將 state 作為參數傳遞，只能傳遞值，即 1

  x = 2     // 修改了 state ，但這對于函數 bar 來說是不可知的

  return x  // 也無法將 state 作為返回，只能返回值，即 2
}

如果你了解 js ，知道變量區分值類型和引用類型、形參實參的分別，那么就不會覺得上面的代碼有任何奇怪的地方。甚至你會覺得如果 x 重新賦值后， sum 會隨之變化為 5、對已經調用完畢的 bar 還能產生影響，那才太可怕了。
但其實上面的代碼，并不是在挑戰這些東西。而是假設我們創建的 x 都是一種名為 state 的首類元素，它應當可以

作為函數的參數或返回值進行傳遞，而不僅僅只是傳遞其計算值，即滿足其身為 first-class 的特性
可以被其它引用它的函數或對象觀察到它的變化

當然，目前 js 中并不存在這樣的首類元素。

Make State Fun Again

neta Make American Great Again，哈哈

我們試試在 js 中模擬出 State
下文代碼都是 typescript

State Interface

interface State {
  get(): T;
  set(value: T): void;
}

構造首類元素 state

我們已經說過首類元素的特性了，可以作為函數的參數和返回值傳遞。

class Atom {
  constructor(value) {
    this.value = value
  }
  get() {
    return this.value
  }
  set(value) {
    this.value = value
  }
}

現在在組件中，我們就可以聲明一個 state 來作為參數了。

Observable state

class Atom {
  constructor(value) {
    this.value = value
    this.observers = []
  }
  get() { return this.value }
  set(value) {
    this.value = value
    this.observers.forEach(observer => observer(value))
  }
  subscribe(observer) {
    observer(this.get())
    this.observers.push(observer)
  }
}

state 能獨立于時間變化了（Independence from time）

可分形的 state

decomposable

class LensedAtom {
  constructor({getter, setter}, source) {
    this.getter = getter
    this.setter = setter
    this.source = source
  }
  get() {
    return this.getter(this.source.get())
  }
  set(value) {
    this.source.set(this.setter(value, this.source.get()))
  }
}

把 store state 作為一個整體，而其分片的元素作為組件的 state

可組合的 state

class PairAtom {
  constructor([lhs, rhs]) {
    this.lhs = lhs
    this.rhs = rhs
  }
  get() {
    return [this.lhs.get(), this.rhs.get()]
  }
  set([lhs, rhs]) {
    this.lhs.set(lhs)
    this.rhs.set(rhs)
  }
}

事務性

獨立于存儲

全局狀態的場景 為什么說全局狀態更好？

組件因此可以無狀態、可以方便地組合

全局狀態更容易檢查

一切對全局狀態的操作測試起來都很簡單

全局狀態是穩健的單一數據源

為什么不用局部狀態

局部狀態無法從外部訪問

很難組合

只能間接地去測試局部狀態

很容易變得散亂

常見的誤解 流（streams）是無狀態的

一般我們認為 stream 是無狀態的，但是請看：

這是無狀態的嗎？

merge + scan 引入了局部狀態

組織很容易變得散亂

時間變得很重要

不過，從好的方便來說：

它可觀察

可以使得依賴更精確：可以方便地觀察「是什么觸發了這個 stream ？」。

但是沒必要。

任何人都可以修改狀態將會是一團糟

是的，在我們的方案里，任何人得到了一個 state 的分片，都可以修改它。
但是在 calmm 中，我們已經

（限定了）作用域
我們通過參數賦予組件一部分 state，組件只能修改這部分 state，而不是全部

（宣告了）意圖
如果你把可變 state 傳遞給了組件，這相當于就宣告說，你允許在這個組件中修改 state

觀察（了變化）
即使有人修改了 state，組件也能觀察 state 的變化并隨之應變。

課后思考

思考下，你到底想把 state 存儲在哪里？

同時，你的組件如何持久化 state 呢？

云服務器 GPU云服務器人工智能之我見我見 state 人工智能我見

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/91736.html

《CDN 之我見》系列二：原理篇（緩存、安全）

摘要：真正要做高性能的系統，不僅需要在數據結構與算法層面深入，更要從硬件操作系統文件系統底層原理等多個領域做更多的研究例如阿里云自研的系統使用了裸盤技術。《CDN之我見》共由三個篇章組成，分為原理篇、詳解篇和隕坑篇。本篇章適合那些從未接觸過、或僅了解一些 CDN 專業術語，想深入了解和感受 CDN 究竟是什么的同學。本次由白金老師繼續為大家分享《CDN之我見》系列二，主要講解緩存是什么、工...

maxmin 2019-06-24 18:02 評論0 收藏0
《CDN 之我見》系列二：原理篇（緩存、安全）

摘要：真正要做高性能的系統，不僅需要在數據結構與算法層面深入，更要從硬件操作系統文件系統底層原理等多個領域做更多的研究例如阿里云自研的系統使用了裸盤技術。《CDN之我見》共由三個篇章組成，分為原理篇、詳解篇和隕坑篇。本篇章適合那些從未接觸過、或僅了解一些 CDN 專業術語，想深入了解和感受 CDN 究竟是什么的同學。本次由白金老師繼續為大家分享《CDN之我見》系列二，主要講解緩存是什么、工...

rainyang 2019-06-21 16:47 評論0 收藏0
初級理解async實現之我見

摘要：在我們寫項目代碼的過程中，要經常請求接口數據，在某些異步請求數據之后，將得到的值進行處理。在我們寫項目代碼的過程中，要經常請求接口數據，在某些異步請求數據之后，將得到的值進行處理。通俗的一句話就是，我要把這個值放到另一個函數中，按行數順序處理，即同步的概念！例子：第一步，涉及異步函數假設我有一個函數abc， function abc(){ //異步方法，請求數據得到re...

CastlePeaK 2019-08-23 18:20 評論0 收藏0
Spring框架之我見（五）——Spring Boot

摘要：通過我們可以更輕松地入門，更簡單的使用的框架。團隊為了擺脫框架中各類繁復紛雜的配置，使用約定優于配置的思想，在基礎上整合了大量常用的第三方庫的開發框架。這里還要說的一點，的出現并不是單純的為了簡化開發，更是為做鋪墊。說完了Spring 我們來聊聊Spring的進階版Spring Boot，如果你還不知道Spring Boot，那希望這篇文章能夠為你指明方向。 Spring Boot ...

張巨偉 2019-08-15 13:34 評論0 收藏0
Spring框架之我見（一）——工廠模式

摘要：相對于工廠模式，抽象工廠模式生產的對象更加具體，也更加豐富，但相對編碼也更加復雜。具體的抽象工廠模式的實現大家可以參考菜鳥教程。知道了工廠模式和抽象工廠模式的區別，請大家使用的時候應該根據具體的情況進行選擇。大家好，今天給大家分享一些Spring的學習心得，在講Spring之前，先和大家分享Spring中核心的設計模式。工廠模式在聊概念之前我先問問大家：什么是工廠？這個很簡單，...

venmos 2019-08-15 13:32 評論0 收藏0