4

Suppose I want to create a webpage with two components, say a Navbar and a Body. These two components do not interact with each other and can be developed independently. So, I have two elm files which have the following components in each of them:

type Model = ...

type Msg = ...

init : (Model, Cmd Msg)

update : Msg -> Model -> (Model, Cmd Msg)

view : Model -> Html Msg

Assumming that they both work fine, how do we compose them to make a program which has both these components?

I tried writing something like this:

type Model = {body : Body.Model , navbar : Navbar.Model}
type Msg = BodyMsg Body.Msg | NavbarMsg Navbar.Msg

view : Model -> Html Msg
view model = div [] [Body.view model.body, Navbar.view model.navbar]

update : Msg -> Model -> (Model, Cmd Msg)
update = ...

The above gets ugly quickly when I try to write this update function. In particular, once I extract the Msg's out of the Cmd's update functions from Navbar.update or Body.update, how do I extract them and feed them back to these functions again? Also, the view function above does not particularly look idiomatic.

What is the elm-architecture recommended way to solve this problem? Is this pattern idiomatic in elm-architecture?

glennsl
  • 28,186
  • 12
  • 57
  • 75
Agnishom Chattopadhyay
  • 1,971
  • 14
  • 32
  • Just to add, I don't think so, if this should be your approach with creating web apps in Elm. Component-wise development (like In React, Polymer) is completely different from functional paradigm (like Elm, PureScript) – kishlaya Jul 04 '18 at 04:22
  • @kishlaya What is the recommended way to create web apps in Elm? – Agnishom Chattopadhyay Jul 04 '18 at 05:13
  • You can follow [this](https://guide.elm-lang.org/reuse/) page for a guide. – kishlaya Jul 04 '18 at 05:47
  • I would add that if you were building your app and you ended up with two independent modules like you described above then that's perfectly acceptable and the way I describe in my answer is how you'd go about combining them. On the hand, there are other ways to think about building you app that doesn't involve component-wise thinking. Check out this [tutorial](https://github.com/dwayne/elm-todos/tree/tutorial/tutorial) for an example. – Dwayne Crooks Jul 04 '18 at 10:59

3 Answers3

5

I think @dwaynecrooks covered the technical aspects of the question. But I believe your problem implies a design aspect too.


How to grow Elm code?

As others pointed out: thinking in terms of components will almost certainly take you down a not so appealing path with Elm. (Many people start there. I and my team started there over 2 years ago, and it took us 3 apps/major redesigns to get to a point where I think we can be happy at least about the fundamentals.)

Instead of components, I suggest you should think of your Elm application as a tree. Each node of your tree represents a level of abstraction, and describes the behavior of your application on that level. When you have the feeling that there is too much detail for a given level, you can start thinking about how new, lower levels of abstraction could be introduced as child nodes.

In practice each node is implemented in its own Elm module: parents import their children. You may also consider that you don't have to stick to the usual model/update/view signatures, rather you should focus on the particularities of your app's domain. This is what – in my read – Richard Feldman is doing in his Real World SPA example app. And Evan's Life of a file talk is related to this question too.


The case of navbar + body

Regarding your particular case – it is not a rare case – here is my experience. If we say that our webapp has a navbar and then some body, this is a pretty static description of the app. This kind of description may fit a component based thinking, but it is less helpful if you want to end up with an elegant Elm app.

Instead, it is worth trying to describe the behavior of your app at this level of abstraction, which may sound something like this: The user can select x,y,z items in a navbar. Clicking on those items will affect the item in q way and also affect the body in either a, or b way. He can also click on v in the navbar, which would show a popup or do w, which logs him out of the app.

If you take this description and apply the logic that I described above, you should probably end up with some sort of a design where most of your navbar is described in your highest level of abstraction. This includes items x, y, z, v and behaviors a, b, w. Now, behavior a may mean that a specific, rich page must be displayed, which has its own detailed behavior that is described on a lower level of abstraction, whereas behavior b may mean that based on the selection some content must be loaded, and again the details of this loading process is worked out on a lower level of abstraction. And so on.

When we started approaching the problem this way, it became much more straight forward to find out how to split up logic, and how to deal with special cases. We realized, for instance, that when someone said that a page wants to display some stuff "in the navbar", what she really meant was that the navbar should collapse (or transform) for a particular page so that page can display it's own header in that area.

Focusing on the app's behavior instead of static content areas helped with this.

Community
  • 1
  • 1
Gabor
  • 1,656
  • 1
  • 16
  • 28
4

Yes, you're on the right path.

In the view you need to use Html.map.

view : Model -> Html Msg
view model =
  div []
    [ Html.map BodyMsg (Body.view model.body)
    , Html.map NavbarMsg (Navbar.view model.navbar)
    ]

Body.view model.body has type Html Body.Msg which requires us to use Html.map to get the correct type of Html Msg. Similarly for Navbar.view model.navbar.

And, for the update function you'd write it like so:

update : Msg -> Model -> (Model, Cmd Msg)
update msg model =
  case msg of
    BodyMsg bodyMsg ->
      let
        (newBody, newCmd) = Body.update bodyMsg model.body
      in
        { model | body = newBody } ! [ Cmd.map BodyMsg newCmd ]

    NavbarMsg navbarMsg ->
      let
        (newNavbar, newCmd) = Navbar.update navbarMsg model.navbar
      in
        { model | navbar = newNavbar } ! [ Cmd.map NavbarMsg newCmd ]

In the BodyMsg case, newBody has type Body.Model and so we can set the body field in model to it. However, newCmd has type Cmd Body.Msg and so before we can return we need to use Cmd.map to get the correct return type of Cmd Msg.

Similar reasoning can be used for the NavbarMsg case.

Also, the view function above does not particularly look idiomatic.

What bothers you about the view code?

N.B. This answer assumes you're using Elm 0.18.

Dwayne Crooks
  • 2,737
  • 25
  • 26
  • What is the `!` notation? – Agnishom Chattopadhyay Jul 04 '18 at 02:19
  • The issue with the view function is that it wraps around an extra `
    ` tag around both things. Why can't I juxtapose two Html elements one after the other without an extra wrap?     – Agnishom Chattopadhyay Jul 04 '18 at 02:21
  • 1
    @AgnishomChattopadhyay `(!) : model -> List (Cmd msg) -> (model, Cmd msg)` You can think of it as `model ! [msgs] = (model, batch [msgs])` – kishlaya Jul 04 '18 at 06:52
  • 1
    @AgnishomChattopadhyay `(!)` is a function defined [here](http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Platform-Cmd#!) that I'm using as a shorthand to write `({ model | body = newBody }, Cmd.batch [ Cmd.map BodyMsg newCmd ])`. Except that in this case it's not needed because `Cmd.batch` isn't necessary for a single command. So I could have written `({ model | body = newBody }, Cmd.map BodyMsg newCmd)`. – Dwayne Crooks Jul 04 '18 at 10:38
  • @AgnishomChattopadhyay as for the `view` function, if you wanted to return just the two views then you can do that as well. The type would become `view : Model -> List (Html Msg)` and the definition would be `view model = [ Html.map BodyMsg (Body.view model.body), Html.map NavbarMsg (Navbar.view model.navbar) ]`. However, at some point you'd need to write a view that returns `Html Msg` because that's the view return type that [Html.beginnerProgram](http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html#beginnerProgram), `Html.program` and `Html.programWithFlags` expect. – Dwayne Crooks Jul 04 '18 at 10:48
  • @DwayneCrooks How would make the code above more idiomatic and avoid repetition? I'm curious to see a solution, will help if you have a number of those modules to update and then map their resulting model/command. Thanks! – Svilen Jul 23 '18 at 11:17
  • 1
    @Svilen The code above is fine based on the question asked. The other question is whether or not he should be breaking everything apart into components like that such that code like the above is needed. I'd have to see all the source code to see how best to refactor it, if at all. It seems to me the code was developed in a component oriented style and so it lead to this problem. Another way is by thinking in terms of data structures and functions, for e.g. https://github.com/dwayne/elm-2048. Evan gave a great talk about this, https://www.youtube.com/watch?v=XpDsk374LDE. – Dwayne Crooks Jul 23 '18 at 13:29
3

That's basically the way to go, yes. There is a popular example for a larger SPA in Elm on GitHub. Here can you see the Main.elm that takes care of mapping the messages from each page: https://github.com/rtfeldman/elm-spa-example/blob/master/src/Main.elm

One thing that is missing from your example is the mapping of the message type that is absolutly required. I guess you left that out to have a smaller post, but from my experience that is the actual part where the boilerplate comes in.

However, you should try not to emulate a component approach like React. Just use functions. Separate pages in an SPA are one example where it makes sense to have a dedicatated message type and corresponding functions like you would with a program.

This article explains the general approach of scaling a larger Elm app and also mentions the point about not having dedicated messages for each component.

Malax
  • 9,436
  • 9
  • 48
  • 64