On Thursday, August 11, 2016 at 2:38:45 AM UTC+1, Richard Feldman wrote: > > What were the cases where it was a good idea? You found some genuinely >> re-usable component in your code base? >> > > The first example that comes to mind is when we had a "school search" > modal dialog on a dashboard that only displayed occasionally: once on > signup, and then again if you wanted to edit the school associated with > your account. > > It had a ton of self-contained logic - 20 fields in the Model, talking > back and forth to an Algolia API, etc - that involved a lot of code which > had absolutely nothing to do with the rest of the page. No matter what the > user did on the modal, it didn't affect any other part of the UI. So there > was almost nothing to communicate to the parent (pretty much just "hey, the > user clicked the Close button") and giving it its own separate Model, its > own separate View, and its own separate Update moved a lot of code out of > all three places for the parent. > > In a lot of ways, needing a lot of parent-child communication is probably > a red flag that these are too tightly coupled for a parent-child > relationship to be a good idea. :) >
This sounds like Parna's principles of modular design and not wildly different to applying those principles in say OO design. If there is too much communication between two classes, the 'feature envy' suggests that the abstraction is not quite right. A better design needs to identify a class with enough self-contained state and/or logic to justify its existence. That said, in classic imperative OO design I reach for the modular design and re-use toolbox pretty quickly, it is almost second nature. It is interesting what you are saying about not reaching for a modular design so quickly with elm, but to explore the other options first. For example, I am already finding that the View will fairly quickly throw up re-usable bits and pieces - perhaps a div that I wrap various UI elements in to give them some common look and feel. This can be abstracted out by writing it as a function, and if that function is particularly useful it can be pulled up into a ViewUtils.elm for re-use. Functional programming itself offers a lot of possibilities that imperative OO does not. So I am reading your advice as 'explore what you can do with functional programming before you explore what you can do with modularizing the elm architecture'. -- 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.
