@devth think it should work if you use shouldcomponentupdate react lifecycle method.

https://github.com/omcljs/om/wiki/Documentation-%28om.next%29#react-set-state @devth

@danielstockton yep, used that. expected it to not re-render/re-query but it is.

Curious, what is this state for? Why do you need it to be component state if it has no effect on the component?

i probably do need it to take affect in the end. what i'm really trying to figure out is why the re-query/re-render takes 300+ms. the component has a text field and typing in it is painfully laggy since onchange updates state -> re-renders the component.

in this case it's a tree of components A -> [B] -> [C] and any C's text-field causes A's state to be updated forcing the entire tree to be re-queried/rendered

so one idea was that C would update its own state, correctly causing re-render, but also send an event up to A via B so that the state of the entire tree state would be represented in A itself. but in the latter case, A does not need to re-render/query itself or its children.

I'm not sure I follow, it sounds like C affects A and therefore it's natural to re-render A. Perhaps you can try using debounce to prevent updates happening too fast?

C only affects A when it's time to transact. for the purposes of rendering state C only affects itself. the only reason A needs to collect all the Bs and Cs state is because it is responsible for persisting the state of the whole tree in a remote mutation.

i can try debouce but the issue is so bad/noticeable that hitting a single key causes a half second delay before the character shows up in the text field

i'm going to experiment more with react-set-state

Do you definitely need to update state on C? How about just pulling the values out of the fields by ref when you call transact?

the textfield in C has a :value set to pull state out of C (that's how it's normally done, right?)

:value (or (om/get-state component :attribute/value) "")

i thought about traversing the component tree at transact time too. didn't find fns to do so in om next, though i'm sure it's possible.

also wasn't sure if it's a good idea for parent components to reach into their children.

It depends, you can have an uncontrolled component and just assign it a :ref and pull the value out with (om/react-ref this "ref") when you need it.

oh, i see. didn't realize you had to explicitly give it a :ref

i had assumed it was set automatically according to the Ident of the component

I'm talking about the (dom/input #js {:ref "name-field"}) element, not necessarily the component.

oh directly on the input. i see

It's just a convenient way to refer to the element and get its value.

can the same be done for components?

what I was looking for yesterday was a way to iterate over the children components of a component.

(`:ref` idea will probably work - just curious)

react-ref
(om.next/react-ref some-component :foo/widget)

I believe you can add a :ref to the root element of a component, yes. There is usually more than one way of doing things. Using the shouldComponentUpdate react lifecycle method is another option, as mentioned above ^^ This can allow you to 'ignore' certain state changes.

got it. thanks! will experiment with these options.

anyone else following the same pattern of circleci's parser? https://github.com/circleci/frontend/blob/master/src-cljs/frontend/parser.cljs#L150 wanted to read more examples of recursive parsing in larger use cases.. but the bodhi dependency is not on github

@pedroteixeira Hi! 🙂 We're in the midst of an engineering push at the moment, but we plan to open up Bodhi soon.

Mostly we wanted to prove that it works for us before leading anyone else down a garden path

If you’re in the DFW area tomorrow, we’re talking about Om Next and Datomic at the Clojure Meetup: https://www.meetup.com/DFW-Clojure/events/239721041/

struggling a bit if it's best to make conventions (on namespacing for ex) to make parser logic easier.. and still pondering about untangled's way that only reads local data (relies on component didComponentMount for ex. instead of routing on parser, but that seems to be not om.next's way)

Say, this has only just occurred to me: in old-Om, collections in state were always supposed to be vectors so they had keys for cursors. In Om Next, does that matter anymore? Is it fine to have non-vector seqs in app state now?

I’m doing some cleanup to Untangled and have a beta of 1.0.0 out at https://github.com/awkay/untangled. Of potential interest is the new Getting Started guide, which shows the constructs that Untangled places on top of Om Next to make development simpler for the common full-stack case. Would love feedback. Questions should be directed at #untangled. The new Getting Started Guide is: https://github.com/awkay/untangled/blob/develop/GettingStarted.adoc