So here's the Elm high level on the tree of components:
An Elm component is typocally a Model type and a Msg type. When side effects occur, the component receives a call to update with the model and the message. It returns a new model and a new side effect to cause (could be none). The model is then rendered into a view.
If you have a user profile component then maybe you have a user info component and a settings component. And maybe the settings component has a notifications component and a privacy component.
The Model for that is pretty straightforward. It's just a tree of data.
The Msg for that is what is being complained about. Any side effects caused by a child component will call the update function of the parent. It then has to route that to the child component.
The result is that you have:
type Msg = ProfileMsg Profile.Msg | SettingsMsg Settings.Msg
type Profile.Msg = ...
type Settings.Msg = NotificationsMsg Notifications.Msg | PrivacyMsg Privacy.Msg
type Notifications.Msg = ...
type Privacy.Msg = ...
So now your top level msg could be a SettingsMsg (Settings.PrivacyMsg (Privacy.SetDefault Privacy.Self))
And in order to process it in update you have to unwrap the outer type (like SettingsMsg) and then call update on the child component with the data from the msg. You repeat until a component can handle it. The the component returns a new model and possible new side effect. You wrap up that side effect in something like SettingsMsg and return it along with your new model.
It's a lot of boilerplate. As far as creating coupling, what if you want to use the notification component elsewhere in the app. Now something other than Settings needs to wrap it so you get Settings.NotificationMsg and Toolbar.NotificationMsg.
Thank you for taking the time to clarify and explain. That's exactly what I was talking about.
Worth noting -- it might be that there's just a missing construct/approach itty bitty piece of language support here that would make this problem a lot smoother.
I'm actually surprised I've not heard of anyone else express something other than complete satisfaction about it as it doesn't take much messing around to whack into it.
An Elm component is typocally a Model type and a Msg type. When side effects occur, the component receives a call to update with the model and the message. It returns a new model and a new side effect to cause (could be none). The model is then rendered into a view.
If you have a user profile component then maybe you have a user info component and a settings component. And maybe the settings component has a notifications component and a privacy component.
The Model for that is pretty straightforward. It's just a tree of data.
The Msg for that is what is being complained about. Any side effects caused by a child component will call the update function of the parent. It then has to route that to the child component.
The result is that you have:
type Msg = ProfileMsg Profile.Msg | SettingsMsg Settings.Msg
type Profile.Msg = ...
type Settings.Msg = NotificationsMsg Notifications.Msg | PrivacyMsg Privacy.Msg
type Notifications.Msg = ...
type Privacy.Msg = ...
So now your top level msg could be a SettingsMsg (Settings.PrivacyMsg (Privacy.SetDefault Privacy.Self))
And in order to process it in update you have to unwrap the outer type (like SettingsMsg) and then call update on the child component with the data from the msg. You repeat until a component can handle it. The the component returns a new model and possible new side effect. You wrap up that side effect in something like SettingsMsg and return it along with your new model.
It's a lot of boilerplate. As far as creating coupling, what if you want to use the notification component elsewhere in the app. Now something other than Settings needs to wrap it so you get Settings.NotificationMsg and Toolbar.NotificationMsg.
It just gets clumsy.