The SPA we're building is likely to factor out as:
Top level
UI Shell
Shared sidebar
Page 1
Page 2
Etc
Service provider
The UI shell manages the overall UI state — e.g., which page is active — and
structure. The service provider maps the API offered to the UI into the logic
to talk to the server. The top level plugs them together.
The key transition for me was accepting that it wasn't unreasonable to abandon
the specific use of Cmd and Sub as part of the glue. Rather the pieces use
types that can be used in the same way but provide more opportunity to
intervene where necessary for routing.
The unit of partitioning is essentially driven by thinking about what sections
it might be reasonable to have two programmers working on simultaneously.
Mark
> On Aug 28, 2016, at 12:11 PM, Erik Lott <mrerikl...@gmail.com> wrote:
>
> Here is a very basic primer showing how you might structure an imaginary SPA
> app:
>
> Top Level
> Page 1
> Page 2
> Page 3
> Page 4
--
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.
