I've started experimenting with a general pattern of having update functions return:
* Maybe a new model (to make it easier to not generate new models on no-op cases and hence work better with lazy rendering) * A list of commands. These can be batched up into a single command at the top but in the meantime, it's simpler to work with than building explicit batches all the way up. (Admission: I'm actually doing this in a code base that still needs to move from 0.16 to 0.17, so these are effects rather than commands.) * A list of "notifications" where notifications are of whatever data type seems appropriate. Levels in the hierarchy can either process notifications, transform notifications, or just pass them along. The notifications logic came about out of wanting a general facility for adding errors to a global error list. It started as just returning a Maybe Error but then we found ourselves needing other notifications like the login sub-model wanting to tell the app model that we've logged in and can move from the logging in state to the active state. I haven't built enough yet with the notifications piece to be entirely comfortable with when and how they should get processed but at least from a data flow standpoint, it feels reasonable. I thought about merging commands and notifications into a general "send stuff up the hierarchy" mechanism but it turns out that they are actually rather distinct in how they need to be handled. But none of this really addresses the shared model question that started this thread. For the shared model, I would either look at storing it once outside the components and passing it in as an immutable piece of data as needed OR replicate it in the subcomponents and have the update logic that handles messages for subcomponents replicate the shared model to the other components after processing the message with the target subcomponent. Mark > On Jun 4, 2016, at 12:38 PM, Peter Damoc <[email protected]> wrote: > > If c1 and c2 need to have an effect outside of themselves, send that effect > as data out of update. > The parent can act on that data coming from the children and do the right > thing. > > If you need information from the share model in c1 and c2, send it as props > when you call the view. > > so... the signatures of the Child component should look like this: > > type DataForParent = DoSomeStuff | DoSomeOtherStuff |DoNothing > > update : Msg -> Model -> (Model, DataForParent) > > and > > view : Props -> Model -> Html Msg > > > of course, if you need to send Cmd upstream, the update wood look like: > > update : Msg -> Model -> (Model, Cmd Msg, DataForParent) > > > > > >> On Sat, Jun 4, 2016 at 9:58 PM, surfncode <[email protected]> wrote: >> Hello, >> >> How do you typically architecture child components that have a shared model >> owned by a higher component in the hierarchy ? >> >> Let say I have component P with a model resembling this >> >> type alias Model = {...,list: List SharedModel} >> >> SharedModel is actually defined in a separated module. >> >> P has two child components c1 and c2 displayed at the same time. Those >> components needs to access to the selected SharedModel in list. >> >> Both the model of c1 and c2 will therefore contain a copy of the selected >> SharedModel >> >> Most of the updates c1 and c2 need to perform on SharedModel are common. I >> was thinking of putting them in the form of utility function in the >> SharedModel module and call them from the parent component P >> >> This somewhat resembles the flux architecture where a central store is >> updated by the react components sharing common actions which then update the >> component views in cascade from the top. >> >> Is that the correct way to do it ? >> >> -- >> 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 [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
