On Tuesday, March 21, 2017 at 10:57:43 PM UTC, Mark Hamburg wrote:
>
> 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.
>
> On Tue, Mar 21, 2017 at 3:20 PM, 'Rupert Smith' via Elm Discuss <
> elm-d...@googlegroups.com >
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.
And it helps to not think about the functions "interacting" with each
other. They don't. A function can call another function. Nothing is
stopping you from calling the content update function or the user update
function from another update function, but I find it helps to just factor
out the
> The challenge is when there are dependencies between Updaters, for example
> the User Profile model might need data from the Session model, the Session
> updater might need to send messages to the User updater (Load user profile
> when session is updated), or the Content updater may need to
I've came up with solution very similar to Oliver's :)
Top `Page`(or `Screen`) update functions are getting the `Store` which is a
top level app model. Alternative way is to have `mapToContext` function
that receives some `Props` and `Store` and maps those to some useful
context(it might be
13 matches
Mail list logo
