> > * 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. >
How? The client defines a function that everyone in the project should use that enforces particular consistent choices on the bits you care about. Then people use that. Boom, consistency by way of functions? > * 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) > No! Not to me at least. The thing I love about the basic Elm thing is the update separates two very distinct things that most js frameworks don't (can't?) and that's it: - I 'changed' a thing in my state. - I'd like to do something in the outside world. (also there's the bit about "something happened and I'd like to respond to it, with Sub") As far as generalizability goes, I have overdone generalizing enough in my life that I try to just....not. When I see some things that are doing the same thing I'll *extract function*. If a bunch of functions work on the same sort of thing it seems I have a *module* I want to reuse elsewhere. If I have things that look sort of similar but operate on different types, it seems I have a *Parametric Type* that I haven't yet teased out (did that moments ago in fact). This part is fun. It makes my code nicer. Gradually. And I love that no one else dictated how I should do this internal bit. *I'm trying pretty hard to do a lot of this learning in public. <http://dailydrip.com/topics/elm>* There are other people that have written on how they handle "Parent<->Child communication" (though this terminology finally seems silly to me because have functions and values in a hierarchy rather than objects here). Since you talked about slack stuff earlier, I'd welcome you to *look at my phoenix/elm chat application <https://github.com/knewter/phoenix-elm-chat>,* as I've made it a bit more over-engineered than it should be for very specific reasons. I am kind of meandering towards a world where a given channel can be wired into various widgets. I think maybe it's a decent starting point for you to just make a feature branch and show the issue you are talking about so we can have a real discussion about code that compiles and can be tied to a specific frustration. Would you be willing to tweak my existing example (which I've spent a decent amount of time building and making open source), to show the issue that you ran into? That way you have an easy and (hopefully moderately similar) codebase you can toy with to show the issues that isn't encumbered, and we can all have a nice little pow-wow about how best to solve your problems. I'm pretty sure everyone that reads this list would find kibitzing on someone elss's code kind of fun :) * 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. > Again, it seems like it might be possible to see a real problem and talk through it. Josh -- 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.
