I’ve been looking into this blog post http://blog.circleci.com/local-state-global-concerns/ which describes how to mount the component-local state into the global app state

It’s implemented here: https://github.com/circleci/frontend/blob/04a70704dec726455c5843200c10b8516b13d82c/src-cljs/frontend/state_graft.cljs

I’m not able to figure out whether it’s still used in CircleCI?

Do any other of you have any experience with this approach?

@grav we tried it and ended up ditching it

localstate changes deep in the component tree were causing the whole app to re-render due to writes happening to the root cursor

it shouldn’t have done this, but when i reported it to david, his response was that he sees no-local-state-descriptor as a debugging tool rather than something to use in prod

any effort people are putting into this problem is now happening outside of Om.current

my personal suggestion: don’t bother with it

ok, thanks for the advice. It actually leads to another question in my head - is it a problem with whole-app rerendering? I thought that the way Om checks equality on subtrees of the state would prohibit re-rendering, and next, if the app actually rerenders, it won’t necessarily lead to dom updates because of React’s dom diffing

In another wording: isn’t the performance impact of re-rendering the root-note in a component tree mitigated by 1) clojure’s re-use of subtrees in the state and 2) React’s DOM diffing?

@grav: your understanding is generally correct. it's likely that robert's issue could be mitigated by making sure that the "global local" state map isn't passed down the component tree as props. that said, it's definitely rough around the edges and it's pretty likely that it will cause unexpected behavior in your app that make it impossible to leave in place in production (and you'll definitely want to remove it as a first step when doing any troubleshooting).

i have a couple open issues w/ minimal cases for some of the issues i ran into w/ it

@jackjames: can you link to those?

sorry, i guess i have just one open: https://github.com/omcljs/om/issues/335

bbloom has one as well: https://github.com/omcljs/om/issues/332

@jackjames: I just tried to use no-local-descriptor in my app, and I experienced and error as well - one component-state variable is updated in the :state-map, another isn't

So it seems it’s not usable yet. Pity, we do a whole lot of unfunny book-keeping of the UI state currently

I’m still playing around with the idea of dumping cursors though. To me, it seems cursors do not help performance wise but is more of a state segmentation help, and mostly wrt. updating the state. Any thoughts?

@grav: there seems to be a consensus that cursors were a nice bridge to a better approach. they're not used at all in the only real existing om production app that we have visibility to (circleci frontend). and looks like cursors will not be a part of om-next.

@jackjames: ok, thanks for the input