Hello, here in the doc Html - html 1.0.0 is said that " This should not come in handy too often. Definitely read this before deciding if this is what you want." (but the link is actually a 404 error). Html.map seems like a great way to reuse components to make bigger components. What I have been…

It used to point to Scaling The Elm Architecture · An Introduction to Elm , though I’ve seen someone on Slack suggest that Structure · An Introduction to Elm is what it should likely link to now. I think part of the what the Html docs are trying to suggest, though not too well, is that you shouldn’t…

[image] wolfadex: I think part of the what the Html docs are trying to suggest, though not too well, is that you shouldn’t break up your code until you need to. I.e. don’t do premature optimization around pages/components. There is a recent threat that elaborates further on the howtos of this…

It is trying to discourage the use of the nested Elm architecture pattern Nested TEA - Elm Patterns . Commonly Html.map is used in this pattern. This pattern is useful but is best to leave it for when it is really needed. It brings a good amount of complexity and boilerplate, so it better to find alt…

So this implies that you can build even a fairly sized application using only one Msg type. In practice, this is rarely the case, only if you are building some demo/toy/one screen app. That is why the referred statement in Html docs may be misleading in pursuing too much simplicity.

I have about 60k lines of code running in production, a decent sized application. I do not see any benefit of HTML.map there. I think there is only one of them in this application. But this is not pages, it’s an application. Maybe the mapping makes more sense if you build a website with pages. I u…

So this implies using a single Msg type through your app, you still have hierarchy inside of it? Seems that any reasonably-sized app should have some form of hierarchal structure. Something like that: type Msg = | CommonAppRelated | PartRelated (DoSomethingWithPart | DoSomethingElseWithPart) …

So this implies that you can build even a fairly sized application using only one Msg type. In practice, this is rarely the case, only if you are building some demo/toy/one screen app. That is why the referred statement in Html docs may be misleading in pursuing too much simplicity. Generally if…

[image] Latty: Generally if you do need to have something like that, the better solution is to take a Msg -> msg function that wraps the inner message type and return Html msg . If you have a (Msg -> msg) function, you might use it through Html.map (or Cmd.map in an update function): someVie…

Html.map doesn’t really offer much value in that scenario, I would just apply the function directly (i.e: DoStuff |> toMap |> onClick). What I was trying to say is that if you pass the wrapping function down to wherever the Html is made, rather than using Html.map after it’s made, you get more flexi…

The real point I was trying to make is that it is not really Html.map (or Cmd.map) that is the problem, its trying to split up an Elm application into stateful components that is. You would use Html.map (or Cmd.map) to do that, so it can be a code smell, but its not a certainty.

What's wrong with using Html.map?

Learn

francescortiz January 26, 2022, 1:37pm 3

There is a recent threat that elaborates further on the howtos of this principle:

Topic		Replies	Views
Idea: Use e.onClick instead of onClick to reduce boilerplate Request Feedback	5	883	March 9, 2021
Why not use: update fn state = fn state Learn	27	1718	March 5, 2021
Should a module expose its Msg constructors? Learn	19	3619	January 23, 2022
Is TEA a comonad? Learn	18	3543	January 16, 2018
Commands and messages from/to child models Learn	9	3322	August 23, 2021

What's wrong with using Html.map?

Related topics