elmのトランスレータパターンは何ですか？

Question

elm git bookでは、子コンポーネントが主更新機能を介して配布され、最終的に子コンポーネントの適切な更新機能によって処理されるメッセージを生成するアーキテクチャが説明される。トランスレータパターンとこれとはどのように違うのですか？また、各パターンのユースケースは何ですか？簡単な例を示してください。

Answer 1

updateのネストされた「コンポーネント」がある場合は常に、親が子のMsgsおよびCmdsを通過するようにする必要があります。 gitのブックoutlines this with a simple example（このコードは親であり、かつWidget子である）：

type Msg 
    = WidgetMsg Widget.Msg 

update message model = 
    case message of 
    WidgetMsg subMsg -> 
     let 
     (updatedWidgetModel, widgetCmd) = 
      Widget.update subMsg model.widgetModel 
     in 
     ({ model | widgetModel = updatedWidgetModel }, Cmd.map WidgetMsg widgetCmd) 

上記子供がupdate機能を持つ任意の時間が必要であろう。しかし、上記の例では、親は子メッセージが子どもに伝えられていることを知らない、または気にしません。

しかし、親が子供によって生成されたメッセージについて知る必要がある場合を考えてみましょう。たとえば、ネストされた子コンポーネントが、ゲームが失われた親と通信する必要があるゲーム。

Translator Patternは、親コンポーネントが子更新関数から返されたメッセージに反応する必要がある場合に便利です。ここでは、更新機能の基本的な構造は、リンクされた例である：それは以前updateの例のようにたくさん見えること

GameMsg internalMsg -> 
    let 
    (game_, cmd) 
     = Game.update internalMsg model.game 
    in 
    { model | game = game_ } ! [ Cmd.map gameTranslator cmd ] 

お知らせ。主な違いは、それよりもむしろブラインド親Msg（唯一の子Msgの周りに渡された最初の例の単一WidgetMsgことでブラインド）に直接Cmdをマッピングされ、gameTranslatorマッピング機能を使用すると、親のいずれかにマップすることができますメッセージ。

Translator Pattern Blog Post全体を読むと役立ちます。これはElm 0.17のために書かれているので、いくつかの構文の変更がありますが、一般的な考え方はまだ成立しています。