# What's wrong with using Html.map?

**URL:** <https://discourse.elm-lang.org/t/whats-wrong-with-using-html-map/8105>\
**Category:** Learn\
**Created:** [January 25, 2022, 5:15pm UTC](https://discourse.elm-lang.org/t/whats-wrong-with-using-html-map/8105 "2022-01-25T17:15:55Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![Latty](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/latty/32/130_2.png) [@Latty](https://discourse.elm-lang.org/u/Latty)\
**Post date:** [January 28, 2022, 12:06pm UTC](https://discourse.elm-lang.org/t/whats-wrong-with-using-html-map/8105/8 "2022-01-28T12:06:26Z")

</div>

> 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 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`. The main advantage of this over `Html.map` is it doesn’t lock you into “one layer” of the message type. You can then potentially take another argument that results in a `msg` for something else, and the caller can provide whatever they want.

E.g: say you have some kind of reusable form. You might want internal messages to update the state of the form (some kind of `FormMsg -> msg`), but then take some kind of `FormData -> msg` for the user submitting the form, as it will be context dependent what that does, and it doesn’t really make sense for it to be internal to the form.

---

_[View the full topic](https://discourse.elm-lang.org/t/whats-wrong-with-using-html-map/8105)._
