React 本來就允許你在 JSX 中嵌入 js 代碼，但是它有諸多限制，會把表達式轉為字符串或其它 React elements。

F-component 就不一樣。F 是一組 lifted componenets 的命名空間。lifted component 是 React 內置組件的鏡像，但允許組件的 props 額外接受 Atom 類型的數據。

我們知道，一個 React JSX 元素中，它的子元素內容會被解析為 children prop。Focal 所做的就是支持嵌入 Atom 作為組件的子元素內容。

好了，讓我們來試試修改 state 的值：

// 下面這行代碼將修改 atom `count` 的當前值。
// 因為我們在 `Counter` 組件中使用了這個 atom `count`，所以修改了它的值后會使得組件更新
count.set(5)

// => 
Count: 5

你可能已經發現了，我們并沒有修改任何的 React 組件的 state （即沒有通過 Component.setState 的方式），但 Counter 還是不可思議地渲染了新內容。
實際上，從 React 的角度來說，Counter 組件的 props 和 state 都沒有改變，照道理這個組件也不會被更新渲染。

這次內容更新，是由 組件處理的。同理，換成其它 lifted component （或者說 F-component） 也會得到一樣的效果。F-component 會監聽 (.subscribe) 它所有的 Atom props，一旦 prop 的值發生改變，就會 render。

那么根據這個原理，修改 count 的值以后，子元素 隨之更新渲染，而 則不會。

下面我們來編寫稍微復雜一點的計數器組件。

// 給我們的計數器組件加點佐料
const Counter = (props: { count: Atom }) =>
  
    Count: {count}.
    {/* 輸出當前計數的奇偶性 */}
    That"s an {count.view(x => x % 2 === 0 ? "even" : "odd")} number!
  

// => 
Count: 5. That"s an odd number!

我們加了一行 ：That"s an odd/even number!，它是由 state atom 的 view 創建的。

創建一個 view 本質上是創建了一個 atom，這個 atom 輸出 state 時，可以表現為它經過修改后的值，對其修改的操作邏輯定義在 view 函數中。
這實際上和 array 或 Observable 的 map 方法差不多，主要的區別在于，和原生的 atom 一樣，這種衍生 atom （被稱為 view ）只會在新值和當前值不相等時才響應新值。

我們再看一個例子

const Counter = (props: { count: Atom }) =>
   `rgba(255, 0, 0, ${Math.min(16 * x, 255)})`)
    }}
  >
    Count: {count}.
    That"s an {count.view(x => x % 2 === 0 ? "even" : "odd")} number!
  

// => 
Count: 5. That"s an odd number!

在這里，我們用 state atom 來為組件創建動態的樣式。如你所見，atom 配合 F-component 幾乎無所不能。它能讓你更簡單地去用聲明式的手段，來描述組件對 state 的依賴。

我們已經了解了如何聲明式地創建基于應用狀態數據的 UI 層。接下來，為了使用它們來構建規模更大更復雜，同時又不致于分崩離析的應用，我們還需要兩樣東西：

既然應用的狀態數據都來自于一個單一數據源（ 唯一的 atom ），那么當應用的不同部分彼此交互時，這些交互行為不會破壞彼此之間的同步性，同時應用的狀態數據作為一個整體應始終保持一致。

Have the application state come from a single place (a single atom), so that when different parts of the application interact with each other, these interactions can"t fall out of sync with each other and the application state is consistent as a whole.

將應用的狀態數據劃分為若干部分，這樣我們可以通過組合若干個小的組件的方式創建我們的應用層。這些小的組件不必知道所有的應用狀態數據。

這兩個需求可能乍看起來互相矛盾，所以就需要 lenses 登場了。

讓我們快速復習下 lens 的概念
(不知道 lens 的可以參考維基 Haskell/Lens)

一種對不可變數據的一部分進行讀寫的抽象

一組 getter 、setter 函數的組合

lens 的泛型接口可以用 TypeScript 表達為：

interface Lens {
  get(source: TSource): T
  set(newValue: T, source: TSource): TSource
}

來看一個用例

import { Lens } from "@grammarly/focal"

// 后面我們會在 obj 上進行數據操作
const obj = {
  a: 5
}

// 用 lens 來查看對象的屬性 `a`
const a = Lens.create(
  // 定義一個 getter：返回 obj 的屬性
  (obj: { a: number }) => obj.a,
  // setter: 返回一個新對象，新對象的屬性 a 被更新為一個新值
  (newValue, obj) => ({ ...obj, a: newValue })
)

// 通過 lens 來訪問屬性
console.log(a.get(obj))
// => 5

// 通過 lens 來寫入一個新值
console.log(a.set(6, obj))
// => { a: 6 }

注意我們是如何通過 .set 方法返回一個新對象的：我們并沒有執行修改操作，當我們想要 .set 數據的某部分時，我們通過 lens 創建了一個新對象。

這看起來好像沒啥用。為什么我們不直接訪問 obj.a 呢？ 當我們需要返回新對象來避免修改操作時，為什么不直接 { ...obj, a: 6 } 呢？

好吧。想象你的對象結構相當復雜，比如 { a: { b: { c: 5 } } }，而它甚至僅僅只是一些更大的對象的一部分：

const bigobj = {
  one: { a: { b: { c: 5 } } },
  two: { a: { b: { c: 6 } } }
}

lenses 的一大特性就是你可以組合 lenses（把它們串聯起來）。假設你定義了一個 lens 用來把屬性 c 從對象 { a: { b: { c: 5 } } } 解構出來，那么在 bigobj 的 one 和 two 這兩個部分上，你都能復用這個 lens。

// 該 lens 用于操作對象 { a: { b: { c: 5 } } }` 里深度嵌套的屬性 c
const abc: Lens<...> = ...

// 該 lens 用于訪問 `bigobj` 的一部分： `one`
const one: Lens = ...

// 該 lens 用于訪問 `bigobj` 的一部分： `two`
const two: Lens = ...

// 把 lens `one` 或 `two` 和 lens `abc` 組合起來
// 然后我們可以在結構類似為
// `{ one: { a: { b: { c: 5 } } } }` 或 `{ two: { a: { b: { c: 5 } } } }`
// 的數據中操作 c
const oneC = one.compose(abc)
const twoC = two.compose(abc)

console.log(oneC.get(bigobj))
// => 5

console.log(twoC.get(bigobj))
// => 6

console.log(oneC.set(7, bigobj))
// => { one: { a: { b: { c: 7 } } }, two: { a: { b: { c: 6 } } } }

Focal 也提供了相當方便的定義這些 lenses 的手段。

// 只需要定義一個 getter 函數就可以創建上述的 lenses1
const abc = Lens.prop((obj: typeof bigobj.one) => obj.a.b.c)

const one = Lens.prop((obj: typeof bigobj) => obj.one)

const two = Lens.prop((obj: typeof bigobj) => obj.two)

// 1 注意使用限制！（RESTRICTIONS APPLY!）
// 在這個例子里，getter 函數只能是一個簡單的屬性路徑訪問函數
// 該函數僅包括一個屬性訪問表達式，沒有副作用 （side effects）

其中最棒的一點是，這種方式是完全類型安全的，所有的 IDE 工具（比如說自動補全、命名重構等）都仍然有效。

可能比較奇怪的一點是，lens 照道理應該還可以修改該值，但我們只定義了一個 getter 函數。這確實不可思議，因為我們在這里施了點魔法。但是，這只能被視為一個實現細節，因為這些特性在將來可能在 TypeScript 編譯器中就過時了。

簡單解釋下，我們用的方案可能類似于 WPF 里用來實現類型安全的 INotifyPropertyChanged 接口的標準實踐。我們通過調用 .toString 函數，把 getter 函數轉換成一個字符串，然后根據函數的源碼解析出屬性的訪問路徑。這種實現方式比較 hacky ，還有著明顯的限制，不過還是很有效的。

希望上一章能讓你稍微領略一下 lenses 的威力，當然你還可以用這個抽象來做更多的事情。遺憾的是我們沒法在這個簡短的教程里覆蓋 lens 所有有趣的部分。

不幸的是，大部分關于 lenses 的文章和介紹都是用 Haskell 來描述的。這是因為大部分對 lenses 的研究來自于 Haskell。不過很多其它語言也采用了 lenses ，包括 Scala, F#, OCaml, PureScript 和 Elm 等。

Program imperatively using Haskell lenses

WikiBooks article on Haskell lenses

School of Haskell lens tutorial

lens over tea blog series

好，言歸正傳。到此為止，我們已經知道了如何管理應用狀態數據，如何把狀態數據嵌入到我們的 UI 層代碼中。

我們還學習了如何抽象對不可變數據的操作，以便方便地對大型的不可變對象的部分進行操作。我們正是需要用它來拆分應用的狀態數據。我們想要這樣構造我們的應用：UI 組件的各部分僅和整個應用狀態數據中和它有關的那部分交互。

為了實現這個目的，我們可以通過結合 atom 和 lens 來生成 lensed atom。

Lensed atom 也還是一個 Atom，或者說從表面來看，它的表現和行為也和別的 atom 幾乎一樣。區別在于它的創建方式：lensed atom 操作于其它 atom 的一部分 state。這意味著，如果你通過 .set 或 .modify 來設置或修改一個 lensed atom 的值，那么源 atom 上與該 lensed atom 對應的這部分的值也會隨之改變。比如：

import { Atom, Lens } from "@grammarly/focal"

// 創建一個維護我們所需對象（的值）的 atom
const obj = Atom.create({
  a: 5
})

// 創建一個觀察屬性 a 的 lens
const a = Lens.prop((x: typeof obj) => x.a)

// 創建一個 lensed atom，這個 lensed atom 會維護對象 obj 的屬性 a 的值
const lensed = obj.lens(a)

console.log(obj.get())
// => { a: 5 }

console.log(lensed.get())
// => 5

// 為 lensed atom 設置新值
lensed.set(6)

console.log(obj.get())
// => { a: 6 }

注意，當我們為 lensed atom 設置新值的時候，源 atom 的值是如何變化的。

我們還有一種更簡潔的方法來創建 lensed atom：

const lensed = obj.lens(x => x.a) // 1

// 1 還是要注意使用限制 SAME RESTRICTIONS APPLY!
// 和 `Lens.prop` 方法一樣，atom 的 `lens` 方法接受一個 getter 函數作為參數，
// 這個 getter 函數只能是一個簡單的屬性路徑訪問函數，
// 它僅包括一個屬性訪問表達式，沒有副作用。

我們無需顯式地去創建 lens，atom 的 lens 方法已經提供了幾個重載來幫助你立即創建 lensed atom。另外需要注意的是，我們不需要在此為對象添加類型標注，編譯器已經知道了我們正在操作的數據的類型，并且為我們自動推斷出來（比如在上面那個例子里，根據 obj 的類型 Atom<{ a： number }>，編譯器可以自動推斷出 x 的類型）

基于這種能力，現在我們可以拆分應用的單一數據源為幾個小的部分，使其適用于獨立的 UI 組件中。讓我們來嘗試把這一方案用在上述的計數器例子中：

import * as React from "react"
import * as ReactDOM from "react-dom"
import { Atom, F } from "@grammarly/focal"

// 應用的狀態數據
const state = Atom.create({
  count: 0
})

// 原先寫好的計數器組件
const Counter = (props: { count: Atom }) =>
  
    Count: {props.count}.

     props.count.modify(x => x + 1)}>
      Click again!
    
  

// app 組件，其 prop.state 攜帶整個應用的狀態數據
const App = (props: { state: Atom<{ count: number }> }) =>
  

    Hi, here"s a counter:

    {/*
      在此，我們拆分應用狀態數據，把其中的一部分給 counter 組件使用
    */}
     x.count)} />
  

我們就用這個例子作為 Focal 基礎教程的總結吧。

希望你現在能理順上面這些東西是如何結合起來的。另外，還請務必看看一些其它例子
。嘗試搭建并嘗試跑通它們，方便進一步了解你可以用 focal 來做什么。

Focal 不是一個框架，換句話說，它并不限制你非要用要某種特定的方式來編寫整個應用。Focal 提供了命令式的接口 （回想下，你可以用 .set 或 .modify 方法來操作 atom ），并且可以完美地配合原生的 React 組件。這意味著，在同一個應用里，你可以只在某些部分使用 Focal。

盡管我們還沒有建立一套全面的評測基準 (benchmarks)，目前為止，在類似 TodoMVC 的例子中，Focal 的性能表現至少近似于原生 React。

一般來說，當一個被嵌入到 React 組件里的 Atom 或 Observable 觸發一個新值時，組件中只有相關的那部分會被更新。

這意味著，在一個復雜的 React 組件中，如果你在該樹某處相當深的可見部位，有一個頻繁變更的值，那么當該值變化時，只有對應的那部分會更新，而不是整個組件樹都會更新。在很多場景下，這使得我們很容易為 VDOM 的重計算做優化。

略

盡管從技術上來說可以把 Focal 用于純 Javascript 項目，但是我們還沒嘗試過這樣做。所以，如果你在搭建這種項目時遇到了問題，歡迎前來提交 issues。

Focal 起初只是想把 Calmm 轉接到 TypeScript ，但隨后我們因為一些顯著的差異而放棄了。

一開始，我們更專注于快速開發產品和類型安全。基于此，許多東西都被簡化了，所以在當時（TypeScript 版本為 1.8 時）Focal 還很難和類型系統搭配得很好，API 也不夠直觀，也很難讓新入門函數式編程的 React 老用戶快速上手。

Calmm 是模塊化的，由幾個獨立的庫組成。而 Focal 沒必要模塊化，因為我們只有一種使用場景，所以我們只需要在一個庫里維護所有東西。

Calmm 最初大量借助 Ramda 的 curry 和 Partial Application。這不利于搭配類型系統，所以我們決定放棄這種做法。不過隨著 TypeScript 編譯器的進步，現在要去實現上面那種做法可能變得容易多了，所以這也許會是一個有趣的話題。

Calmm 最初還借用了 Ramda 里的 lens ，這種 lens 使用的是 van Laarhoven 表示法。相反，Focal 使用的是含有一對 getter/setter 的 na?ve 表示法。由于我們無需去做遍歷或多態更新 (traversals or polymorphic updates)，所以這對我們來說足夠了。不過有可能我們會在以后重新考慮這個問題。

Calmm 的主要實現 (kefir.atom 和 kefir.react.html) 都基于 Kefir 的 observables。一開始我們也用 Kefir，不過很快遷移為 RxJS 5.x。最主要的原因是，RxJS 功能更豐富，它有一些 Kefir 還不支持的對 observables 的操作。