Clojurians Log v2

Hey so I just picked up clojure and i’m making a fun little app with it, but I hit a snag in frontend land. I can’t’ figure out exactly what the difference between om and om.next is. So… what’s the difference?

and why would I use old om vs om.next

@benbot om is a thin wrapper around react, and has a forgiving learning curve. It doesn’t take much to learn om if you already know React. Om.next tries to do a bunch of things like incremental rendering, an async render loop, components that specify what information they need, among a bunch of other bells and whistles.

@levitanong so is om.next to om like re-rame is to reagent?

but… built in?

I’d like to say it’s sort of re-frame++ to reagent. 😛

but yes, built in

Do you think I should be using om.next right from the start, or mess around with om by itself first?

Also, if i don’t use om.next

it doesn’t get compiled into the final js right?

@benbot IMHO Any gains you get from om won’t translate into om.next, so if you intend to pick up om.next at any time in the future, you might as well start with it.

@benbot not sure what you mean by the final js thing.

@levitanong Since om.next is built into om, if I don’t use anything from om.next, will that code still be in the compiled JS

also I don’t really like how om.next uses objects 😞 avoiding objects is why i started learning clojure in the first place lol

@benbot ah, i think you’ll have to go on advanced compilation to get rid of the extraneous code. (Will need someone more qualified to confirm this) Ah, you’re talking about the static om/IQuery stuff?

that and the while (defui Object ...) stuff

You can implement methods on objects that were defined with defui it all seems very NOT clojure-y

idk

@benbot but you have to go through that stuff with om anyway. reify

hrm i didn’t know that

protocols are a fundamental part of clojure/script, and are a big reason why they interoperate well with java/script. They’re OOP-esque, sure—but they’re constrained to very specific areas of the code you deal with, so it’s manageable.

@carter.andrewj No, the merge doesn't know where the data came from (AFAIK), but typically what you want to do is have your send (which does know the remote) massage the data as necessary into a uniform format before passing it to the send callback.

@carter.andrewj Stay tuned, I've got some work coming that should make it easier. 🙂

@peeja Thanks, man 🙂 I've got the first bit working now (by precisely the route you're suggesting - so good to know I'm headed in the right direction). Interesting on the coming-soon teaser 😛

I was literally just typing another question while you replied...

🙂

I'm currently trying to get om.next to create a nested set of similar objects - I don't know how many objects there will be ahead of time, so I structured the data as a hierarchy (that gets built from the results of send, as mentioned above). However, to get om to render these components, I needed to add the following to the query: {:children (om/getQuery ThisComponent)} - which has resulted in the app trying querying itself forever and exceeding the maximum call stack size.

Ah! Have I got syntax for you!

I was hoping this would be handled lazily behind the scenes and so just work as-is, but it appears that's not the case

{:children ...}

Ah-ha! I was hoping there was a way to get this sorted 🙂

actually ...?

Actually ...

Or are you pausing for effect? 🙂

Nope, that's it 🙂

Nice!

(Quoted, of course)

Thanks, mate 🙂 I had a moment of "Oh, god - how do I get around this one..." there

So [:foo :bar {:children ...}] will read :foo and :bar off the current thing and then off each of its children, and their children, and so on

You can also limit recursion to a particular depth with a number, like [:foo :bar {:children 5}]

Those come straight from datomic's syntax

A word of warning, though: while that's the syntax to express what you want, there's only so much that Om itself does for you to make that happen (at least for now). Your parser code is going to be responsible for some of it.

So, play with it 🙂

Yes, there's something not working perfectly currently - but it's not throwing any errors, so presumably I just need to take a closer look at my data structures

Currently, I build the nested map manually and call tree->db on the full result

Will that work as expected? Or would I need to call that at a lower-level of the process?

@carter.andrewj tree->db or db->tree?

db->tree will handle the recursion for you. tree->db is for normalizing during merge, and shouldn't care about recursion.

tree-db

But all I need it for is normalization of the data, once it's been received/structured, (I think...)

Yep, that should work fine

@peeja And indeed it does! (after some mis-steps with seqs (that should have been vectors) and malformed idents, etc...)

Thanks again

@carter.andrewj Sweet! Glad to help!