My approach is: there is one specific `Feature{X,Y,…}Msg` for each feature,
so the main `update` function has only one entry for each "submodule". Each
submodule's update looks like this:
update : FeatureXMsg -> Model -> ( Model, Cmd Msg )
The key is to have it just like this everywhere. Each
We've done that as well in places. But I was mostly looking for an example
of how to access extra data during an update. Another example from our
codebase is accessing the User record (name, email address, etc) which we
store at the top of the session model. The updater for a more specific
state
On Tuesday, March 21, 2017 at 6:27:01 PM UTC, Mark Hamburg wrote:
>
> P.P.S. If you want your mind more deeply twisted, here is what we do when
> we want to store the auth token fairly high up but a piece of code needs it
> for constructing an HTTP request:
>
Why not use a secure cookie? Then
And if we were more deeply nested, the NeedAuthorization could also have
been forwarded via code like this — note also that I fixed the failure to
properly type the case entries in my previous message:
applySubModelOutMsg : SubModelOutMsg -> Model -> ( Model, List OutMsg )
applySubModelOutMsg
Oliver asked whether our out messages approach had an equivalent of Cmd.map.
I'll paraphrase some code to show how it works. It's definitely more code
than the simple Cmd approach but it provides more functionality as well.
I'm simplifying away a lot of details like the fact that the login
On Monday, March 20, 2017 at 11:58:38 AM UTC, Eirik Sletteberg wrote:
>
> In larger Elm apps, it makes sense to divide Updaters so you can
> package-by-feature.
> For example, a single page application could have updaters like this:
>
> - Configuration updater
> - Session updater
> - User Profile
The main reason to separate is when the smaller pieces have their own
conceptual integrity. That becomes something one can manage independently
and maintain more local invariants about thereby making that piece of the
code easier to reason about. But a dependency has to be managed somewhere
and
That was what I was thinking, put all the application state in one model,
and all updaters will deal with that single model, instead of each Updater
having its own sub-model. In the end, almost all the data is dependent
somehow.
tirsdag 21. mars 2017 12.22.15 UTC+1 skrev Fedor Nezhivoi
> for example the User Profile model might need data from the Session model
This is probably the biggest issue with how people used to do it in Redux.
If you read it closely then you'll see that your data is dependent. By
separating it between modules you do not make it in decoupled, you just
Is it an option to make all the updaters deal with the root model and the
root message?
And in the "main" updater, just compose the other updaters?
It could make things simpler, but hurt isolation. Also I'm not sure whether
that would introduce circular dependencies between modules?
mandag 20.
On Monday, March 20, 2017 at 8:41:36 PM UTC, Martin Norbäck Olivers wrote:
>
>
> The reason I was thinking about it was not actually anything to do with
>> garbage collection. I have a data modelling language with a type system,
>> but it has grown in a slightly ad-hoc manner and needs some
>>
11 matches
Mail list logo
