Skip to content
An example of a service component pattern in Elm
JavaScript Elm Other
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
build check in build project so it can be run from github Sep 11, 2019
src First version! Sep 11, 2019
.gitignore First version! Sep 11, 2019
LICENSE Create LICENSE Sep 11, 2019
README.md
docs.json check in build project so it can be run from github Sep 11, 2019
elm-application.json First version! Sep 11, 2019
elm.json First version! Sep 11, 2019
index.html check in build project so it can be run from github Sep 11, 2019
make.sh check in build project so it can be run from github Sep 11, 2019

README.md

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
You can’t perform that action at this time.