Thanks, Richard. That all works if everything is essentially sitting
together at the top level and talk to the model. As I said, writing the
queue isn't really the hard part. I know you just like to let stuff
accumulate in one monolithic piece, but if you wanted to subdivide some of
the major sections into sub-modules, would you have them stop using
Platform.Cmd to communicate upward and instead say use something like:
type AppCommand msg
= Immediate (Cmd msg)
| Queued Int (Cmd Msg)
| Batch (List (AppCommand msg))
with appropriate implementations for AppCommand.batch, AppCommand.map, and
AppCommand.none?
The general guidelines for code development would then perhaps be:
• Structure in terms of models, messages, init, update, subscriptions, and
view (leaving some pieces out where they aren't appropriate).
• Be prepared to replace the standard platform types for Cmd and Sub if you
need to bridge between what your application logic needs and what your
server (or other backend) provides but when doing so follow the same API
patterns so that the shift is easy to make.
• More generally document what you need and what you deliver via types and
use transformations to go from one type to another. The tagging pattern in
the standard Elm examples is just a particularly simple form of
transformation.
• Don't subdivide too much.
If these are the guidelines, then it might be good if Elm did not auto
import pieces of Platform like Platform.Cmd and if Task.perform were
replaced with Platform.Cmd.fromTask. That way the guide could talk in
terms of building applications based on "commands" and "subscriptions" but
could also say that Platform.Cmd and Platform.Sub were just examples of
such types that were used at the boundary layer between the application,
the runtime system, and the effect managers and were also for most simple
and many not so simple programs but were in no way sacrosanct beyond their
role at the boundary.
Mark
On Fri, Aug 26, 2016 at 2:18 PM, Richard Feldman <
richard.t.feld...@gmail.com> wrote:
> I'm trying to rebuild the successor to some past systems in Elm and one
>> thing we learned on those systems was that to get good performance it was
>> critical that we prioritize HTTP fetches so that we didn't ask for the low
>> priority items at the same time as the high priority items. From a
>> correctness standpoint, the particular fetches are a local problem and the
>> Elm architecture provides a reasonable way to route those. But the
>> prioritization is a global problem. To go with that, I need cancelation
>> support because that's the other key piece in getting responsiveness and
>> what that means in practice is that if something hasn't left the queue yet,
>> I need a way to cancel it.
>>
>
> Okay, now we're getting somewhere!
>
> So you have a specific problem where you need a global queue for
> dispatching HTTP requests according to your applications' particular
> business logic.
>
> Here's how I would approach this if I had these same design constraints. I
> would add something like this to my model:
>
> requestQueue : Dict RequestId { order : Int, request : Task Never Msg }
>
> Then I'd introduce a function to enqueue messages with a particular
> priority level that determines the order value.
>
> I'd also introduce a Msg called Dispatch that pulls the next thing off
> the queue (sorting Dict.values by the order field) and uses Task.perform
> to run the HTTP request.
>
> To allow canceling, I'd add this to my top-level Msg:
>
> | CancelRequest RequestId
>
> This is what I would do if I had your particular business need. Seems
> pretty reasonable!
>
> I also think it would be no problem to introduce this to an existing Elm
> application after the fact. Just start by deleting your dependency on
> elm-http, and the compiler will immediately tell you every single place you
> were doing HTTP "the old way." Go through and transition those direct HTTP
> calls to use a stubbed-out implementation of "the new way," and then
> finally reintroduce the elm-http dependency to make the queue work for real!
>
> I'll also note that this use case seems very specific to your application.
> I would avoid trying to overgeneralize this into any kind of pattern that
> others should follow. :)
>
> --
> 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.
>
--
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.
