The Elm Architecture

https://guide.elm-lang.org/architecture/

by tosh • 8 years ago

119 79 8 years ago

wa1987• 8 years ago

In what ways does the Elm architecture differ from MVC?

m90• 8 years ago

Not the Elm Architecture, but I found this a very good article on how MVC differs from unidirectional approaches: https://www.futurice.com/blog/reactive-mvc-and-the-virtual-d...

mpweiher3• 8 years ago

As usual, that article gets MVC wrong.

In MVC, the model-view communication is not "interactive" as defined by the article (source pushes to sink). Instead, the view pulls data from the model. There is only a general #changed notification to let the view know that the model has changed.

So "unidirectional" approaches fix the problems you get when you don't understand MVC. ¯\_(ツ)_/¯

thangngoc89• 8 years ago

If you want to use TEA but with easier interop with JavaScript libraries, you can use ReasonML/OCaml with bucklescript-tea[1] instead

[1] https://github.com/OvermindDL1/bucklescript-tea

napsterbr3• 8 years ago

Just pulled an all-nighter deciding what to use instead of Elm. We have a 45kloc codebase in Elm and, despite having some big pros, the closed source development it goes through, along with the 0.19 debacle, just pushed us over the edge. The team is very motivated to ditch elm over something else.

So, Bucklescript seems great (and it's wonderful how OvermindDL1 explains in the open his design decisions. An openness that I've missed in Elm), and IMO superior than Typescript, and comparable with Fable (in that case being mostly a matter of personal taste: F# vs ocaml).

But, as long as we are trying new stuff, I've decided to use Clojurescript with Reagent and re-frame. The tooling around it seems very mature (even more so than Elm, but I may be wrong), with a good community and macros!

For anyone in a similar position, several good options out there, but the best two that I've found, in my opinion, are Bucklescript (ReasonML/Ocaml) and Clojurescript. Cheers!

sixstringbudha2• 8 years ago

We have a 45kloc codebase in Elm and, despite having some big pros, the closed source development it goes through, along with the 0.19 debacle, just pushed us over the edge.

Can you clarify in concrete terms what the closed source development and 0.19 thing had cost you?

skybrian2• 8 years ago

Why lose sleep over this considering that 0.18 still works? (Genuine question, not criticism.)

somlor• 8 years ago

ClojureScript with re-frame is fantastic. I also use it on a production app with an Elixir backend, it's a great fit. Be sure to check out re-frisk and re-frame-10x.

TheSmoke• 8 years ago

first and foremost, you get to experience figwheel, an amazing interactive tool for the repl and browser. you'll see how you and rest of the team get productive in such a short time.

kuwze• 8 years ago

Could you go into more detail, maybe listing the pros and cons for ReasonML and ClojureScript considering your use case?

atrilumen• 8 years ago

I've lost touch with Elm to be honest, (been using Choo)... but hey: wouldn't it be easier (and probably better) to upgrade and use ports?

sridca3• 8 years ago

And if anyone is looking for something superior to TEA but in Haskell checkout Reflex.

http://docs.reflex-frp.org/en/latest/

"React and Elm do not offer the same concept of FRP as Reflex. Reflex offers something based on Conal Elliott's push-pull paper. Conal Elliott is the father of FRP (at least of the theory of FRP), and the semantic model he envisioned is similar to Reflex, but quite different from React/Elm. I believe his semantic model is pretty superior, and Reflex implements it quite nicely." https://www.reddit.com/r/haskell/comments/5aksxa/ghcjs_frame...

afrisch• 8 years ago

Shameless plug: ocaml-vdom[1] is another implementation of TEA in OCaml (with js_of_ocaml)

[1] https://github.com/LexiFi/ocaml-vdom

Touche3• 8 years ago

So what ties together the model, update, and view? It looks to me like it is this Browser module, is that right? Not knowing Elm or Haskell syntax, I'm guessing that Browser.sandbox is a function you call, passing in the model, update, and view functions.

Assuming that's all correct, how does Browser.sandbox, work exactly? In particular how does it know when to call Update?

At first glance it looks like it might massage the view and detect event listeners such as onClick in the button example, is that correct?

hawkice2• 8 years ago

Turning Html Msg types into actual Dom nodes means hooking up the event handlers so that they call update with the Msg the event handler is given. Browser.sandbox is building the Dom nodes and has the update function.

Touche3• 8 years ago

Yeah, I got that far. How does it know what it should turn into an Update handler though?

rtfeldman11• 8 years ago

Great question! You're correct, it's the Browser module.

In Elm, the entire application state is a single immutable value, which Browser owns and only changes when it calls `update` and a new value gets returned.

Browser calls `update` in response to these 3 situations:

1. An event handler from view (e.g. `onClick Foo` means Browser will call `update`, passing `Foo` as the message, whenever that element gets clicked)

2. A subscription fires (this is kinda like #1 except for global events instead of per-element handlers)

3. A command completes, and its resulting message needs to get sent to `update`

Every interaction in Elm is modeled in terms of one of these!

avolcano• 8 years ago

The bit I love about the Elm Architecture that I really wish existed in other frameworks is the "Command" system, by which the "Update" step can dispatch further changes. Basically, imagine if a Redux reducer could dispatch further actions.

I've tried building Redux apps with bidirectional real-time communication (re: networked video games), and found myself having to pull almost all of the logic up to the action layer, as I often needed to dispatch further side effects based on changes that happened as the result of an action. It made my reducer into nothing more than a dumb setter, and caused me to have to write complex mocked tests for my action layer instead of my reducer layer.

I know there's been some attempts at bringing this to Redux (such as https://github.com/redux-loop/redux-loop), but from what I've seen it isn't quite as easy to use.

OTOH, I will say, as an outside observer, it sounds like Elm has run into problems with this approach (see: the removal of WebSockets from this guide, pending a rewrite), so I am curious to know more about what issues arose.

bcherny• 8 years ago

Check out Undux effects - they're exactly that. https://undux.org

kiliancs• 8 years ago

redux-loop is harder to use, but so is Redux itself. They are both having to fight the language (JS) to do what is so simple in elm.

rtfeldman11• 8 years ago

To be fair, the websocket package's design problems are unrelated to the Elm Architecture - just plain old run-of-the-mill API challenges. :)

mudetroit• 8 years ago

redux-observable can give you something rather akin to that type of behavior. It sees each action after it has already been applied to update state. This also separates out the reducer from those side-effects, which you really want anyhowto keep your reducers as pure functions.

the_duke• 8 years ago

redux-saga makes implementing a pattern like this pretty straight-forward.

You can have sagas subscribing to actions and processing them in arbitrary ways, including dispatching new actions.

bauerd• 8 years ago

Basically, imagine if a Redux reducer could dispatch further actions.

You can achieve the same by using redux-saga[0], then writing a generator function ("saga") that inspects dispatched actions, and potentially triggers a side effect, dispatches another action, waits for another action to get dispatched in a certain time, etc.

[0] https://github.com/redux-saga/redux-saga

EduardoBautista• 8 years ago

I really wish the React ecosystem had less dependencies. Things that are included in other libraries are always met with “You can always install X” as if it were a good thing to add more dependencies.

craigts• 8 years ago

You should take a look at mobx-state-tree. It provides this capability in a straightforward way and is more approachable in general.

jarcane• 8 years ago

Hyperapp can do something like this. You can have an action that sends a message for another action. This is how it handles asynchronous HTTP requests for instance: the http() function takes both the URL/params for the request, and the name of an action that will receive the response as an argument.

The result feels very Elm-like, albeit sans the assurances of the typing.

yogthos• 8 years ago

The re-frame effects in ClojureScript are a similar idea https://github.com/Day8/re-frame/blob/master/docs/Effects.md

baddox• 8 years ago

I think Redux middleware is the answer to this. My preferred approach is to keep all my actions as simple serializable objects, and have (potentially many) small middlewares that listen for certain action types and perform async tasks and dispatch further simple action objects.

There are also more fully-baked middlewares like Redux Saga, but I find that those are a bit too heavy-handed and result in too much “lock-in” for implementing your actions and action creators.

russellbeattie• 8 years ago

"Imagine if a Redux reducer could dispatch further actions." I use a technique called "actors" that are like non-UI components that listen to store events and dispatch additional actions if necessary, using setTimeout so they're pushed to the end of the event loop.

Some pedants online continually claim this - or something like it - is an "anti-pattern" but I'm trying to get stuff done, and this is the way to do it.

okbake• 8 years ago

NGRX (the redux inspired state management library for angular) has a concept called 'effects', which lets you subscribe to the action stream (actions and the state in ngrx are both rxjs observables) and trigger side effects in response to certain actions. The effects themselves map to one or more actions (or zero if you want side-effects only) when they are finished that get dispatched.

Since you're dealing with them from within an observable stream you have access to all the rxjs operators, so you can do things like waiting for multiple actions to be dispatched before doing something, etc.

zoul• 8 years ago

I like the Elm architecture so much we have tried to do something similar in Swift on iOS. It’s a shame it’s not possible to go all the way in (it’s quite hard to find an analogy for the DOM diffing view part), but after a year of work or so it looks like the principled state management + message-based state changes + principled side effect modelling brought us about 70–80 % of the advantages. It feels _so_ good so see the state of the app change using well-defined messages and not by ad-hoc state changes on some entangled forest of singletons. I look forward to experimenting with the architecture further. I can’t recommend it enough.

dom96• 8 years ago

Huh, I must say I thought there was more to Elm's architecture (I've seen it mentioned in the recent negative article about Elm).

I've written an SPA[1] recently in a framework that is quite flexible and also ended up using a very similar architecture.

1 - https://github.com/nim-lang/nimforum

andrejewski• 8 years ago

If anyone wants the Elm architecture in JavaScript there is Raj: https://jew.ski/raj/

I spent over a year building the framework and a set of libraries around it so that the architecture feels natural to JavaScript developers.

There's only a few of us building apps with it right now, but the stories for doing most anything are covered and as of 2 months ago the framework hit 1.0. It is a safe foundation to build on as I don't plan to ever change it.

sridca3• 8 years ago

Yesterday's submission on Elm with interesting discussion in comments: https://news.ycombinator.com/item?id=17842400

vmchale• 8 years ago

This is just model-view-controller except Evan is taking credit for inventing it.

The Elm Architecture

Related Stories