@therabidbanana so did you guys end up doing some of your data as "blobs" instead of as components with queries to avoid db->tree overhead?

Not specifically for that reason, but yeah, a lot of our deeply nested data is blob-like

(It gets passed to C3 charts, so there's a bit of a wrapper component, but mostly the data is internal concern of C3)

I'm working with one of our teams, and I'm seeing 5s+ frame times due to overhead in db->tree and path-meta

the detail/denormalization just kills it, and path-meta goes to hell

I was surprised that it was that easy to "tip" into bad performance. I'd have thought we had a lot more headroom on that

Yeah, I recall trying to dig into some performance issues and seeing that db->tree can get pretty expensive

I wonder if this is a case where some hidden mutation in place as an optimization is justified

Potentially

well, first step is to fix the queries to not put so much in front of it in the first place

@tony.kay I would not be afraid of the change that root mutations don't do a root rerender anymore. We fought that quite a few times. But I thought this was on purpose 😛

Not root mutations...post mutations after a load.

A mutation run from root will render root

Sorry I meant post-mutations

brainderp

just pushed 0.6.1-snAPSHOT of client. Has the performance enhancement I spoke of yesterday

note that you may need to add :refresh to your loads if your rendering stop updating afer loads...I removed a forced root render after post mutations

Hi, I'm new to clojurescript & om. Would you recommend I get started with untangled (after going through om.next docs) or should I focus on setting up my project with om.next ?

The documentation for untangled seems to be amazing. (Nicer then what I could find for om.next)

I would start with untangled first, personally. We did our current Untangled app first in raw Om.next as a prototype (before we heard about Untangled), and Untangled solved a lot of the problems we struggled with building that prototype out-of-the-box