Clojurians Log v2
untangled
@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