Refactor Redux-go

如標題所示，這次我要談論的是redux-go的重構
在幾次的測試撰寫過程中，我發現舊版的redux-go有一些小問題
首先是Action物件建構不易，且無關的資訊不斷出現
何謂建構不易？我們必須用

redux.SendAction("type")

這樣彆扭的寫法來建構只有type的Action
然而需要Args時，卻要使用

&redux.Action{
    Type: "type",
    Args: map[string]interface{} {
        // ...
    },
}

這樣複雜的寫法，直接使用struct非常容易出錯，如果客戶端直接插值給Args，結果只會是panic

讓介面容易被使用，不容易被誤用

而且redux這個模組資訊完全是非必要的，所以我在v0.5.0將整個Action部份移到redux/action模組
這樣一來程式就變成了

import "github.com/dannypsnl/redux/action"

action.New("type")

非必要的資訊已被移除，現在我們可以專注於action
下一步是讓新增Args的介面容易使用，所以我在v0.5.1新增func (*Action) Arg(string, interface{})方法進入action模組
於是新增Args變成

action.New("type").
    Arg("key", value).
    Arg("key2", value)

這樣的流暢呼叫式

第二個部份是Store，大抵和Action問題一樣，所以亦將其移入store模組
所以客戶端程式就變成了

import "github.com/dannypsnl/redux/store"
import "github.com/dannypsnl/redux/action"

func main() {
    store := store.New(reducer...)
    store.Dispatch(
        action.New("type").
            Arg("key", value).
            Arg("key2", value))
}

注意省略概念外的程式

第三是DispatchC方法的部份(屬於Store)
原本我發現在效能較高的電腦上，序列式的計算subscribed function比共時化的程式更快
於是分成兩個API
但是經過檢討，我認為這只會造成困惑，且未來多核心能力上升，Go亦可能優化其排程器使實作更加高效，比起讓客戶端負擔測試程式效能的成本，直接採取共時版本的實作更加適合，因此採取這個作法(v0.6.0)

經過這次重構，我重新認識了Go的模組組織概念，還有誰來負擔決策成本的問題，是非常有趣的體驗