On Sep 10, 2016, at 2:06 PM, Josh Adams <[email protected]> wrote: > > 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.
There is code I wrote 20 or more years ago that is still going strong in an evolving code base that makes hundreds of millions of dollars a year in revenue. The way it has managed to stay viable is that it's broken up into modules with useful API boundaries. Those API boundaries are influenced by this being a C++ code base, but my expectation would be that if Elm is suitable for building similarly long-lived code bases, it needs to have some strong story about how best to modularize code. I don't expect it to look like C++/OO modularization, but I'm looking for something. Waiting until you need it is useful for avoiding work you don't need to do, but being cognizant of best practices from the beginning means that when you need to do it, you won't find yourself cursing and swearing about how everything is tangled together. > I'm trying pretty hard to do a lot of this learning in public. 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, 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 will put it on my list to look through. Whether it's easily adaptable to demonstrating the issues I was looking at, I'll have to see. And maybe, you've just hit on the right patterns to begin with. One other example of where splitting things apart felt ugly was that we wanted to track connection errors as a global state and display them in one place. Any Http command coming back could need to set the global error state. When everything is all at the global level, this isn't a big problem. It just means that a lot of code can modify this one field in the model. But if we followed the nesting patterns from the older TEA documents, then the place where the command results were being delivered were not places where the global error state was accessible let alone modifiable. This resulted in a series of "solutions": * Posting to a mailbox to trigger a signal to trigger a message to set the global connection error status. (This was in Elm 0.16.) * Passing a maybe error back up from the update functions as an extra parameter. * Passing a general notification construct back up from the update functions because we had other cases with similar needs. * Folding these notifications together with commands as a command replacement. Basically, commands are just a request that something above/outside the current point in the model do some work. These all worked. None of them were so pretty as to be obvious answers. My current inclination is toward doing something where requests substitute for commands and get turned into commands when we get further up the nesting hierarchy. It keeps TEA patterns mostly in place but it has the "downside" of abandoning use of Cmd inside much of the code. 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.
