On Sep 10, 2016, at 8:52 AM, Oliver Searle-Barnes <[email protected]> wrote:
>
> Mark, have you considered the approach that Evan took with elm-autocomplete?
> Personally, I found this a satisfactory approach to the problem of private
> state/events, I'd be interested to hear your take on it.
I watched the video when it came out but I hadn't looked closely at the code at
the time. I just did so and I had a variety of reactions:
* There is a similarity between what I did and the auto complete code in that
the level above stores both the public state and the private state and provides
both to the view and update functions.
* The autocomplete code places a lot of burden on the client. For example, key
code identification. This may be needed for configurability but I could see it
being a problem for consistency across multiple auto completes in a larger
project. It could probably benefit from a standard usage path or an example of
how to build such a standard usage path as part of the examples.
* The communication mechanism back from auto complete is interesting in that it
returns messages or rather maybe messages. This is the sort of pattern that
deserves more attention. For example, should a fully generalized update
function look something like the following?
update :
Config parentMsg
-> StateFromParent
-> LocalMsg
-> LocalState
-> (LocalState, Cmd LocalMsg, Maybe parentMsg)
(Actually, autocomplete splits up the state from the parent into how many to
show and the items to show and spreads them out in the update parameters. I
don't recall a part of the API design discussion that went into why this
particular parameter order. I picked the order I did here in order to make the
function look more like a classic TEA update function with extra parameters at
the beginning.)
* One thing that will be different between the approach I took and this
approach is that if any of the local state depends on the global state — e.g.,
in a date picker, externally setting the date might change the month displayed
— then the autocomplete approach which would use a message to set the date at
the parent level might have an awkward sequencing problem in that we would do
something like the following:
update the date picker in its update function
process the update the date message
update the date picker again because the date changed
Basically, routing things back through the update function as a message can
interfere with de-bouncing. In contrast, I specifically stored the update to
the local state after updating the public state in my counters example. One
could do this as well in the deliver messages back approach, but the natural
place to handle messages feels like at the end of the update function in
essentially a tail recursive call. That said, using messages is definitely a
more versatile approach.
Mark
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
