Won't this break the reactor/debugger? You can't really tell what sort of messages is being passed around in your application with this model, if you want to export message history, it would fail as well I believe.
I think a better way would be to not have nested components. Keep your entire message hierarchy, and model structure, flat. torsdag 24. august 2017 09.10.07 UTC+2 skrev Vlad GURDIGA følgende: > > Hey Elm-guys and Elm-gals! 👋 > > I have this toy-project > <https://github.com/gurdiga/xo.elm/tree/9fe9bd1b9f7cb13b6653ec55d9e873033e8930ed> > > where I’m getting my feet wet with Elm, and I’ve found an approach to > compose view function that’s a bit different than what The Elm Architecture > recommends. 🤓 > > Because I found message transformation (mapping > <http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html#map>) > between nested components to be counterintuitive, I left out messages, for > the most part. I only have one > <https://github.com/gurdiga/xo.elm/blob/9fe9bd1b9f7cb13b6653ec55d9e873033e8930ed/src/Main.elm#L33-L41> > > for the whole app: 🙃 > > type Msg > = Update Model (Cmd Msg) (Sub Msg) > > update : Msg -> Model -> ( Model, Cmd Msg )update msg model = > case msg of > Update model cmd sub -> > ( { model | subscription = sub }, cmd ) > > > Only the top component references it > <https://github.com/gurdiga/xo.elm/blob/9fe9bd1b9f7cb13b6653ec55d9e873033e8930ed/src/Main.elm#L64>, > > and from then on I use callback-style functions > <https://github.com/gurdiga/xo.elm/blob/9fe9bd1b9f7cb13b6653ec55d9e873033e8930ed/src/Dosar.elm#L31-L42> > > for wiring up the nested components: > > view : Dosar -> (Dosar -> Cmd msg -> Sub msg -> msg) -> Html msgview (Dosar > data) callback = > let > c data = > callback (Dosar data) > in > div [] > [ h1 [] [ text "Dosar nou" ] > , Temei.view data.temei (\v -> c { data | temei = v }) > , DocumentExecutoriu.view data.documentExecutoriu (\v -> c { data > | documentExecutoriu = v } Cmd.none Sub.none) > , Actiune.view data.actiune (\v -> c { data | actiune = v }) > ] > > > and also for event handlers > <https://github.com/gurdiga/xo.elm/blob/9fe9bd1b9f7cb13b6653ec55d9e873033e8930ed/src/Widgets/Fields.elm#L27-L34> > : > > unlabeledTextField : String -> (String -> msg) -> List (Html > msg)unlabeledTextField defaultValue callback = > [ input > [ value defaultValue > , onInput callback > ] > [] > ] > > > It seems to work well so far, and coming from JS I find this style a bit > more familiar conceptually: I only have functions and values. 🤓 > > I am at about 184K of Elm now, and I’m wondering if anyone else have tried > to do it this way and maybe found some gotchas that I should be aware of. > In particular, with regards to how the code compiles to JS and maybe other > Elm’s inner workings. 🤔 > > Cheers! 🤠 > > (NOTE: If you want to browse the code, please use this revision: > https://github.com/gurdiga/xo.elm/tree/9fe9bd1. After that I’m bringing > in elm-mdl <http://package.elm-lang.org/packages/debois/elm-mdl/8.1.0>, > and the code will probably get too noisy for the purpose of this > conversation. 🙂) > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
