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."

i believe i understand this sentence, but haven't seen "novelty" used in this context

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 🙂

Basically it refers to whatever new data you have.

Under the hood, it’s a merge, but you can change that function to anything you like, if ever you need to.

@levitanong thanks

another question, i'm reading this excellent article https://circleci.com/blog/why-we-use-om-and-why-were-excited-for-om-next/

go on

>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.

Also, sho thang, brah

?

“sure thing, bro"

😛

yeah i just didn't know if inadvertently did a bro-y thing

I’m not sure why they’d use a channel for that

that was my question... why not just have the list component pass in a callback?

lemme take a look at their code

https://github.com/swannodette/todomvc/blob/5789a77334d2241e515f632a96c23118907ae852/labs/architecture-examples/om/src/todomvc/app.cljs#L135

@machty i think that section you’re reading is the part where they’re talking about how to do it in om.now

confirm, i'm just trying to understand why core.async would even be used for om.now

In om.next, you wouldn’t even pass a callback. You’d just have the component use om/transact!

ah, well

i think it’s a matter of taste.

you could use callbacks all you like, but other people prefer channels

yeah

i've heard a lot of recent backlash in the go community against channel-overuse where callbacks suffice

Hahaha

presumably the same disagreements apply to core.async discussions

There are some patterns we use in my company (and i’m sure we’re not alone)

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.

hmm is get-shared like context in react?

i guess it's like context but scoped to a specific owner

so you'd still have to pass the through the owner to all the leaf components

not at all

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 om/get-shared

almost like global vars but scoped within your om app.

how is that different from context in React?

in om.next, you can pass a map to :shared in the reconciler configuration

context is defined by a component, not by an app

and context requires you to specify proptypes.

they’re similar in that they provide deeply nested children some data, skipping the middlemen

but context is appropriate for library authors, and i don’t think shared is

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?)

Currently alpha. You can check the om release tags, and see the latest version

are there some big picture problems that remain to be solved? is there an area of om.next that's particularly volatile?

you might like to ask that question on the om channel. That’s where david nolen and antonio monteiro hang out