@dimiter: one thing: you need a query on your root component

Even when I do that the subcomponents don't get re-rendered.

you have a new problem, then, I think

the root query should include (om/get-query AutoCompleter) and you should pass the props from that into AutoCompleter's factory

making that work does not seem like it will be trivial..

I’m getting some mutation issues when I turn on either simple or advanced compilation. Is that expected?

App works fine with whitespace compilation, and I’m doing any js interop directly.

I fixed it but I’m not sure how. When I had :simple compilation optimizations on, this code would throw a null error whenever a transaction originated from inside ui-widget.

[:div
       (ui-new-widget-menu (om/computed {:ui/widget-modal? widget-modal?
                                         :dash-id          id}
                                        {:toggle-widget-modal toggle-widget-modal
                                         :create-widget       create-widget}))
       (map #(ui-widget
              (om/computed % {:delete-widget delete-widget :dash-id id}))
            widgets)]

Then by putting the ui-new-widget-menu and ui-widget collection into seperate divs the null error when away.

[:div
       (ui-new-widget-menu (om/computed {:ui/widget-modal? widget-modal?
                                         :dash-id          id}
                                        {:toggle-widget-modal toggle-widget-modal
                                         :create-widget       create-widget}))
       [:div
        (map #(ui-widget
               (om/computed % {:delete-widget delete-widget :dash-id id}))
             widgets)]]

Well looks like it was a laziness issue, changing map to mapv also fixes it.

Maybe this is why David Nolen doesn’t like these dom dsls 😄

interesting

why would laziness there only break with optimizations, I wonder?

I wish I knew, probably a sablono issue though.

hi i’m trying this tutorial

Warning: flattenChildren(...): Encountered two children with the same key, `.$undefined`. Child keys must be unique; when two children share a key, only the first child will be used.warning @ react.inc.js:19287instantiateChild @ react.inc.js:4132traverseAllChildrenImpl @ react.inc.js:17621traverseAllChildrenImpl @ react.inc.js:17637traverseAllChildren @ react.inc.js:17709instantiateChildren @ react.inc.js:4158_reconcilerInstantiateChildren @ react.inc.js:11737mountChildren @ react.inc.js:11774_createInitialChildren @ react.inc.js:6958mountComponent @ react.inc.js:6804ReactDOMComponent_mountComponent @ react.inc.js:12403mountComponent @ react.inc.js:13065performInitialMount @ react.inc.js:5649mountComponent @ react.inc.js:5596ReactCompositeComponent_mountComponent @ react.inc.js:12403mountComponent @ react.inc.js:13065mountComponentIntoNode @ react.inc.js:11202perform @ react.inc.js:16006batchedMountComponentIntoNode @ react.inc.js:11223perform @ react.inc.js:16006batchedUpdates @ react.inc.js:9262batchedUpdates @ react.inc.js:13735_renderNewRootComponent @ react.inc.js:11376ReactMount__renderNewRootComponent @ react.inc.js:12403_renderSubtreeIntoContainer @ react.inc.js:11453render @ react.inc.js:11473React_render @ react.inc.js:12403(anonymous function) @ core.cljs:13
utils.cljs:38Figwheel: trying to open cljs reload socket

@sergiodnila: I wonder which Om version you’re using?

everything seems to be working fine for me

@sergiodnila: actually managed to reproduce it

@anmonteiro: the same version as the tutorial says "1.0.0-alpha24”

@sergiodnila: I’ve edited the tutorial to use alpha34

and I’ve added one more thing regarding the react-key

should fix the problem

this is a consequence of react15

@anmonteiro: thanks will try it

@tomjack: my whole idea behind using Subcomponents with their own queries is that I don't want the root to be concerned with sub queries.

@dimiter: that means your Subcomponents are roots on their own... ???

I guess you could put it that way. Im not sure that how OM Next is designed though. Essentially, I want to prevent the main root from re-rendering on any small state change not concerning it.

Let say I have a Notification Widget mounted somewhere under the root, I want it to be able to make its own queries without relying on the root to pass through the props.

That's not going to work 🙈

unless you mount multiple roots...

Let's say I want to refresh the app (from root) every couple of seconds as time progresses. To schedule an update, do I have to go through transact!? So just transact! some '[(app/refresh)] query? Or is there a way we should use without making a mutate query?

Yes, transact! is the only way to update the state, you answered your own question

Ok, thanks!

Thanks @iwankaramazow that clears things up quite a bit. I was just a little confused since my examples were getting the data. Just not in the right order.

@francoiswirion: there's force-root-render!

@anmonteiro: Oh, thanks, I've never heard of that function

I'm trying to work through the tutorial for untangled, and at this point it's probably 100% similar to just pure om. Could anyone help me with the queries and state exercise? Drop me a PM

Nevermind, I got some help

Hello. I started to use Om.Next and can't understand how to update data in inner component. I receive the following error: {:message "No queries exist for component path (om-next-starter-kit.core/OuterView om-next-starter-kit.core/InnerView)", :data {:type :om.next/no-queries}}. There is the code:

I don't know what query should be in OuterView component if I just want to update data in InnerComponent (something like om/get-query)

hm, I'm looking on om/computed, maybe this is the solution...

OuterView query should be something like [{:inner (om/get-query InnerView)}], and you should pass (:inner props) to inner-view

the root query should express the entire query tree with get-query on subcomponents (and so should they), and with the defaults the app state graph is supposed to be shaped according to the component query structure. in your specific example you could just turn InnerView into a function (maybe using om/computed to pass callbacks in) and the app state would not need to mention it

maybe if you make it a function, there is no point to om/computed, because the function can't go using unknown subcomponents anyway -- it would just return html