This is an interesting question and important for larger apps.
In the instance I am working on I plan to use a cache, and have implemented
the idea in one of the components so far. I have the relevant top level
component monitor for events in sub-components triggering messages that
require the cache to be supplemented, handling the downloading, and then
routing the result to the cache. I pass the cache down through my view
functions alongside the relevant section of the overall model, and the view
function shows a holding statement for as long as the cache cannot provide
content.
Simon
On Tuesday, 31 May 2016 18:29:44 UTC+2, James Wilson wrote:
>
> In Elm, each component basically has its own internal state (which is
> actually all just a slice of one global model). In my app, I also want
> global state that is independant of any components; for example a
> clientside cache of various API responses (asset details - there could be
> many thousands, user authentication status).
>
> I want any component to be able to call methods that make use of this
> global state. For example, a method to obtain details for items in the
> current view might first look at the global state to see if these items are
> cached. If they arent, the call would provide a Cmd to be issued that gets
> the items (and puts them in the cache), while simultaneously updating the
> state to indicate that they are being loaded (so that the same request
> again from another component doesnt trigger another call to the backend).
> If they are cached, they can be easily returned from there. A first shot at
> a signature might look something like:
>
> getItem : GlobalState -> ID -> Tag -> (GlobalState, Cmd msg)
>
>
>
> However we could partially apply functions that exist on some globalState
> instantiation to hdie the initial state being passed in and end up with:
>
> state.items.getItem : ID -> Tag -> (GlobalState, Cmd msg)
>
>
>
> The downside of this approach is that I have to thread this state through
> multiple calls that might make use of it, and thread it back up explicitly
> through the update functions to get it back to the top. At the top we'd
> then have something like (excuse any mistakes!):
>
> update msg model = case msg of
> SubMsg m ->
> let (newSubModel, subCmds, newGlobalState) = SubComponent.update m
> model.subModel
> in ({ model | state = newGlobalState, subModel = newSubModel}, Sub.map
> SubMsg subCmds)
> ...
>
>
> An alternative approach is to hold this global state in an effect manager,
> and so in the app you'd end up using the Cmd/Sub mechanism to ask for
> things from the state and internally initiate API requests to update the
> state as necessary. We'd end up with an API more like:
>
> getItem : ID -> Tag -> Cmd msg
>
>
> or
>
> state.items.getItem : ID -> Tag -> Cmd msg
>
>
> where the returned Cmd would either lead to an item being sent to the
> component immediately via a cache (where Tag is a Msg type the component
> knows about) or after it was obtained via some backend. This would make all
> retrieving of state async but seems to simplify the interface (perhaps at
> the cost of more complexity in implementing the effect manager).
>
> Which approach do people think is best for working with global state
> (neither is an option if you have a better way!)? Do you get away with not
> needing this kind of thing (and if so, how)? I'd love to hear back,
> especially from those that have had experience building larger apps in Elm!
>
--
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.
