The example is simplified but I think in reality there may comes a case in which you need to group certain parts into components. I guess we are also used to partition the app into different parts, usually starting by watch the mockups. Maybe we should do a little translation from the "dump and smart" component concept in react: - dump ==> pure function - smart ==> elm component with its own model, view, update
On Wed, Aug 17, 2016 at 2:52 PM, Kasey Speakman <[email protected]> wrote: > Why were two inputs arbitrarily made into a component? If you're not > reusing it, then why bother? In the broader picture, you are trying to > apply object orientation (encapsulation), and it doesn't fit. It can't fit > because the model does not ultimately belong to the component. > > If you need to compose certain elements together for reuse, consider > making it a view-only widget (a pure function), passing in the data and > message constructors it needs to fulfill its purpose. > > http://elm-lang.org/blog/blazing-fast-html#reusable-widgets > > The thread Magnus linked is a good read as well. > > > On Tuesday, August 16, 2016 at 9:51:15 PM UTC-5, Jacky See wrote: >> >> >> Hi, I'm a new comer to elm. I try to build application using elm and have >> some problem on component. >> >> Suppose I'm building an BMI calculator, initially I have a model >> >> type alias Model = { weight:Int, height:Int } >> >> The rendering is just an two input[type=number]. >> The result is rendered by a pure function at the main app: >> >> calclulate model = >> let >> h = (toFloat model.height) / 100 >> w = toFloat model.weight >> in >> toString (round (w / (h*h))) >> >> >> One day a decision made to change those two inputs into a component of >> its own (BmiConfig). >> So the models become >> >> --at main app >> type alias Model = { bmiConfig: BmiConfig.Model ... } >> >> --at BmiConfig >> type alias Model = {weight:Int, height:Int} >> >> We need to to the work of connecting Msg, etc. The calculate function >> becomes >> >> calclulate model = >> let >> h = (toFloat model.config.height) / 100 >> w = toFloat model.config.weight >> in >> toString (round (w / (h*h))) >> >> >> Another a change comes and requesting add +/- button to the number input. >> We try to make a small generic component NumberInput. Models become: >> >> --at main app >> type alias Model = { bmiConfig: BmiConfig.Model ... } >> >> --at BmiConfig >> type alias Model = {weight:NumberInput.Model, >> height:NumberInput.Model} >> >> --at NumberInput >> type alias Model = {value:Int, max:Int, min:Int, .... } >> >> The calculate function needs to be changed again: >> >> calculate model = >> let >> h = (toFloat model.config.height.value) / 100 >> w = toFloat model.config.weight.value >> in >> toString (round (w / (h*h))) >> >> It seems to me that every refactoring to extract component would lead to >> a propagation >> of change all the ways from child to its parents. Parents need to know >> the data >> structure of child to do calculation too. Is that the correct way of >> applying the elm architecture? >> Have I missed something? >> >> >> >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/elm-discuss/mYGK12WCiew/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Best Regards, Jacky See -- 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.
