A Service Pattern

In larger Elm programs, the structure is often divided into a multiple parts, each having their own Model & Msg types, and init, update, view, and subscriptions functions. There are common patterns for bundling up several of these sub-components into container component. This container component does the job of aggregating the Model data, wrapping and unwrapping Msg data, and calling the other functions, combining the results.

A pattern this doesn't handle is a component (a help system, say) that wishes to offer services to the sub-components (like showHelp), but be managed as a single resource at the top level. (We want one help system, not several on the page).

While a single service like this isn't so hard, it gets much more difficult if there are multiple services, and when the services want to be able to trigger events events back in the sub-components.

This application demonstrates techniques to handle this cleanly, and extensibly.

See it in action: Run the app

It easily supports multiple services (in linear code). It allows service requests to have message functions (like Html.Evnets handlers), and trigger those back at a later time. It allows services to make use of port and Cmd. And services can use each other, even self or mutually recursively.

Narrative Path

The docs have a path that layout key ideas in order. Afterward, definitely look at the source code to see the details of how it is done.

Read at the docs in this sequence:

If you are looking at this on github the links below won't work. Instead, browse over to the elm doc preview version.

• SizePicker — the interface for clients that want to use the size picking service
• Sub1 — a sub-component of the main app, which uses those services
• Command — a type like Cmd, but that covers all the kinds of requests code can make, including the service requests
• SizePicker.Service - the implementation of the service, which, for the most part is just a standard sub-component
• Top — the top component that has sub-components in the usual way, but also handles distributing requests to, and responses from the services