The implementation of the size picker service.
For the most part, this is structured like any other sub-component, with
Model and Msg types, and update, view, and subscriptions functions.
The only differences are:
Model type is parametric on the top component's Msg typerequest function.request and update has an additional valueThe model of the service must be parametric on the message type of the component that contains it. This is usually the top component in the application.
The reason for this can be seen in the dictionary of pending requests: The
request includes a function that maps the response (the picked size) to a
message to be re-injected into the program, via the top component's update
function.
The message type of this service, as a sub-component.
This like a standard sub-component update function with an addition:
The returned tuple has a third value, List top, that is a list of top-level
messages that should be operated on after this update. These are the messages
back to requesting sub-components.
This is almost identical in every way to update, only it handles a
Request, not a Msg. Upon progressing the request, the model may have
changed, new Commands issues, and even other response messages returned.
Notice that Request here is parameterized by top. This is because by the
time a Request from a child component had bubbled up to the top component
for dispatch to this function, it has been mapped (Command.map) to the
top component's message type.
Internal ids are used to tag the requests in progress.