1. 17

  2. 5

    I also have my doubts about the direction Elm is heading (I stopped using it for that reason), but I also have my doubts about PureScript. It’s great, but I had a lot of trouble find documentation and working examples for the current versions of the compiler and libraries (that is, once you managed to pick your rendering library in the first place).

    1. 5

      Well put. What Elm really lacks is a way to compose smaller pieces of an application at a higher level than plumbing views, models and updates at every boundary.

      1. 3

        I’m sure a good Elm developer could speak up here, but here’s how I’d refactor:

        update msg model =
              new = case msg of
                FirstThingLoaded data -> {model | data1 = data}
                SecondThingLoaded data -> {model | data2 = data}
                ThirdThingLoaded data -> {model | data3 = data}
                FourthThingLoaded data -> {model | data4 = data}
              buildRenderableData model = …
            if isJust model.data1 && isJust model.data2 && isJust model.data3 && isJust model.data4 then
              (buildRenderableData new, Cmd.none)
              (new, Cmd.none)

        This solves the “no help from the compiler here if you accidentally type data2 instead of data3” problem.

        Additionally, I’d encapsulate each Thing model data as a type. Then the compiler helps.

        If there are a lot of functions like buildRenderableData with a guard condition, then I’d generalise that pattern:

        if [guard] then
          f model

        From the bestiary of functions, this should look familiar.

        I wonder if the author ever reached out to the Elm community for help?

        (As for WebSocket support, I feel his pain. I await for proper HTML5 Audio support in Elm.)