Why We Use Om, and Why We’re Excited for Om Next
blog.circleci.com
Why We Use Om, and Why We’re Excited for Om Next
1–10 of 74 posts
Re: Why We Use Om, and Why We’re Excited for Om Next
#2This is a more coherent summary of Om than exists elsewhere, including the official Om site.
Re: Why We Use Om, and Why We’re Excited for Om Next
#3So I've been looking at Elm recently, what would the advantages/disadvantages for something like Elm over Om/Om Next?
Re: Why We Use Om, and Why We’re Excited for Om Next
#4This is a more coherent summary of Om than exists elsewhere, including the official Om site.
I wasn't surprised when I saw who wrote this. Peter's a great writer and educator. He has an excellent video series for explaining basic computer concepts.
Re: Why We Use Om, and Why We’re Excited for Om Next
#5I've spent the last few weeks building a side project in Om Next, and this article is spot on. Really excited to see CircleCI's plans to migrate, as it'll be fun to read their code and learn how they use it.
Relay and Falcor are great, but when I look at their docs it's unclear how to integrate with whatever backend I want (especially Relay). Looking at Om Next, it was totally clear how to write my own backend. The tradeoff is that everything is a little more manual, but that control gives you a ton of flexibility.
In a small amount of code, I have a client that can query financial data in a bunch of different ways, and if the data isn't available it sends the query to the backend, which executes it against a SQLite database and returns it to the client. The components are all unaware of this: they are just running queries against data and everything just works.
Combine this is with first-class REPL and hot reloading support via Figwheel (both frontend and backend) and I'm blown away at how fast I'm going to develop this app.
Re: Why We Use Om, and Why We’re Excited for Om Next
#6So I've been looking at Elm recently, what would the advantages/disadvantages for something like Elm over Om/Om Next?
Elm's HTML engine conceptually the same as React+Redux and Om Now. It's just a big single atom app state with ways to describe how to update it. It has all the same problems as Om Now (maybe not quite as bad because it doesn't have cursors, but it doesn't solve the data-as-a-graph problem).
Re: Why We Use Om, and Why We’re Excited for Om Next
#7> Application state as a single, immutable data structure.
react-cursor gives this pattern in javascript, immutability and all, but with regular old javascript objects. It also comes with all the same caveats as in this article. (I don't speak for the creator of Om, I speak for myself as the author of this library which was inspired by Om and Clojure)
https://github.com/dustingetz/react-cursor/
The beautiy of the state-at-root pattern with cursors, is that each little component, each subtree of the view, can stand alone as its own little stateful app, and they naturally nest/compose recursively into larger apps. This fiddle is meant to demonstrate this: https://jsfiddle.net/dustingetz/n9kfc17x/
> The tree is really a graph.
Solving this impedance mismatch is the main UI research problem of 2015/2016. Om Next, GraphQL, Falcor etc. It's still a research problem, IMO. The solution will also solve the object/relational impedance mismatch, i think, which is a highly related problem, maybe the same problem.
Re: Why We Use Om, and Why We’re Excited for Om Next
#8It seems like the setup I use is pretty similar to Om Next, but via independent libraries. I am looking forward to seeing the finished Om Next to compare.
ClojureScript is shaping up to be a fantastic way to program browser-based applications. This is what I use:
* Reagent -- another ClojureScript React wrapper
* Datascript -- An in-memory database with datalog query lang, this is used as the central store for all application data.
* Posh -- Datascript transaction watcher that updates Reagent components when their queries' return data changes
* core.async -- used for handling any kind of event dispatch and subscription. I do a unidirectional data flow type thing and it only took like 15 lines of ClojureScript.
This is one of the nicest front end development experiences I've had. Just the composition of these four libraries gives you a ton of flexibility and a good way to structure your application. You can use this setup to write a real-time syncing/fetching system with a backend database pretty easily.
Re: Why We Use Om, and Why We’re Excited for Om Next
#9I would love to see some code examples of this part "If we try to show a component that needs to know the current user’s initiated builds, that triggers an API call that asks the server for the data. If we stop using that component, we stop making that request. Automatically."
I'm currently knee deep in a react/redux implementation, which I guess is quite similar.
Re: Why We Use Om, and Why We’re Excited for Om Next
#10Clojure and ClojureScript for president in 2016! No, but seriously, one of the most promising pair of practically useful languages in existence.