The idea of ​​smart and dumb components in Elm

Question

I like the React's / Redux concept for intelligent and dumb components, where the dumb component does not process its own state (the Dump component does not know anything about the outside world, everything that it does fires an event and displays the value according to its input). This is trivial because the entire state is processed in one place (main gearbox).

In Elm, each component has its own "update" function (similar to the Redux reducer), so there is nothing strange in using the same template (dumb and intelligent components).

Is using smart and dump components a good practice at Elm? If so, will I have components without the “upgrade” method? I wonder how I will pass the data (details) to my component and how I can trigger events for the parent component.

I will be glad to hear your thoughts.

Answer 1

The viscous equivalent of the "dumb component" (aka Presentation, clean, skinny component) is just a function that produces Html :

 view : ... -> Html 

The elm-html library is written in this style, for example,

 button : List Attribute -> List Html -> Html 

You set the "attribute" by providing attributes when you call the function. In particular, you register events by delivering handlers to the List Attribute :

 button [ onClick addr ClickAction ] -- event handler [ text "Click me" ] -- child "components" 

You will see this template also in other libraries, although the exact types may differ from List Attribute and List Html .

Answer 2

Another smart / dumb difference you can make is with components that return Effects and those that don't. But to answer your question ...

Nothing prevents you from defining actions in a child

 type Action = Submit | Click 

and in the parent view having

 Child.view (Signal.forwardTo address ChildAction) props 

(We transmit props because there is no model data as such for the transition)

but then processing all the actions in the parent update :

 case action of ChildAction act -> case act of Child.Submit -> ... Child.Click -> ... 

This would be significant if the effect of the action in the Child was to change the state of the parent or other child.