This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (2)
- # boot (1)
- # cljs-dev (126)
- # cljsrn (4)
- # clojars (1)
- # clojure (109)
- # clojure-austin (5)
- # clojure-austria (1)
- # clojure-boston (2)
- # clojure-brasil (33)
- # clojure-canada (1)
- # clojure-russia (1)
- # clojure-spec (62)
- # clojurescript (23)
- # core-async (1)
- # cursive (33)
- # datomic (26)
- # ethereum (2)
- # hoplon (7)
- # jobs (1)
- # lein-figwheel (1)
- # luminus (12)
- # off-topic (4)
- # om (3)
- # om-next (49)
- # perun (2)
- # protorepl (2)
- # specter (6)
- # test-check (1)
- # untangled (2)
- # vim (6)
- # yada (30)
from the getting start guide: "The reconciler accepts novelty, merges it into the application state, finds all affected components based on their declared queries, and schedules a re-render."
is there a computer science paradigm that makes use of that term that i might look up?
@machty “novelty” doesn’t really refer to any specific concept. It means what it is: Something new 🙂
Under the hood, it’s a
merge, but you can change that function to anything you like, if ever you need to.
another question, i'm reading this excellent article https://circleci.com/blog/why-we-use-om-and-why-were-excited-for-om-next/
>But in the UI, the “Delete” button should really be part of the grocery item component. Just as our data doesn’t map perfectly to our UI, neither do our mutation operations. >The usual solution to this problem in Om is core.async channels. The grocery list component would set up a channel and pass it to each list item. To delete itself, an item component would put a message on that channel. Meanwhile, the list component would run a go block to listen for the message, and when it got it, it would om/update! its cursor.
@machty i think that section you’re reading is the part where they’re talking about how to do it in om.now
In om.next, you wouldn’t even pass a callback. You’d just have the component use om/transact!
i've heard a lot of recent backlash in the go community against channel-overuse where callbacks suffice
wherein you have some central go-loop that handles events, and matches on event types. Think pub-sub.
so instead of some deeply nested component having to pass an action through several levels of callbacks, it can just get the channel from
(:pub-chan (om/get-shared owner)) and
put! the action in there
and it can just skip all the way up to that central go-loop, and perform the actions there.
in om.now, you can pass :shared to the
root function, and any component down the line will be able to access those values via
they’re similar in that they provide deeply nested children some data, skipping the middlemen
so what is the status of Om.Next? Is it still alpha/beta? (also where do I go to answer this question myself next time?)
are there some big picture problems that remain to be solved? is there an area of om.next that's particularly volatile?