is there an equivalent to how in Om Now you could have a third opts argument to your components (e.g. (defn my-view [data owner opts] …) in om.next?

@jamesnvc: See above: om/computed

syntactically, I guess you could make a helper function

Ah, cool; thanks!

welcome

@danielstockton @anmonteiro thanks, the remote fetch tutorial part by @tony.kay addressed my issue! 👍:skin-tone-5:

I've written up some course notes about Om Next remotes here: https://blog.juxt.pro/posts/course-notes-2.html?accessid=MagicAccessHack - of course, this material may have some factual errors in it, I'm still on the learning curve - if you see any do please point them out and I'll fix them.

Hi! Sorry for the very noobish question. I'm following om.next's quick start, and I have a doubt: is Object in the defui macro a protocol?

@doddenino: this is not Om Next related, it's a clojure(script) thing

like in defrecord & deftype

It's JavaScript Object, the base type of all objects.

Sorry if I asked in the wrong channel. I haven't still gotten to the protocols/records/types part, and the syntax confuses me a little!

Do you gives have any thoughts on this? http://programmers.stackexchange.com/questions/309779/what-are-the-disadvantages-of-storing-your-state-in-a-single-immutable-atom

I don't think you're right in thinking that Om Next doesn't have the idea of a "single immutable atom". While it may be true that each part of your application only gets what it needs, the apps current state still lives in a single, immutable place

I don't think it's that different at all compared to Om.

Currently hit a roadblock with om.next routing

I’ve explored the various samples on the internet and seen this page https://github.com/omcljs/om/wiki/Routing-Support

Questions like how to propagate or modify parameters from the top-level means users have not yet seriously considered the various tools around query - the simple AST. They should be encouraged to explore the possibilities and enumerate what further helpers or additional primitives may be missing.

Exactly that: how do I propagate parameters down the ast tree? I have a path parameter that is needed way down the UI hierarchy.

Bonus question: isn’t set-query! against everything we value in CLJS? I thought the UI should be a function of the app state.

@dnolen: It looks like add-root supports setting :normalized in the app state itself to prevent initial normalization. I'm hoping to be able to supply a pre-normalized app state from the start, but have :normalize turned on. I assume this is meant to be a publicly supported thing, but it isn't in the docs. Should I document it?

@tony.kay: yes, go for it

thx

@frankie set-query! actually gets recorded into the application state

Do you end up building a factory for pretty much all components?

so doesn’t really effect anything like time travel - that said if you are going to explore routing you are on your own for now until I have time to get to it

errors are a far more pressing design area for me as far as I’m concerned

I see, thanks for the answer

plenty of people have come up with things that work for them in this channel, hopefully someone will chime in at some point

Tried some of the existing solutions and none worked for me. We have a quite heavily nested app that we’re converting to om next. I will keep on exploring

Do you think manipulating the ast is a valid option tho?

you can experiment something which I’ve suggested many times

write your own query managing thing, the fact that set-query! can take the reconciler as the 1st argument is for this

while I can see how the AST bits might be useful I don’t really see why you need to go there for basic stuff

Thanks, will do

Does anybody know why removing :count from the query here: https://gist.github.com/pupeno/2a67bca78ee0627aa2aa#file-layout-cljs-L75 would cause the app not to load? I get no error but the root component doesn’t seem to get mounted.

Also, why is current-route nil here: https://gist.github.com/pupeno/2a67bca78ee0627aa2aa#file-layout-cljs-L38 how should I call the sub-component for it to get the proper data?

Ah, figured that one out. I still can’t understand why removing :count from the query breaks the application. It’s not used anywhere.

It doesn’t have to be count. When the query is [:current-route] the component doesn’t get mounted, when it’s [:current-route :whatever] it gets mounted.

Ha! so, :current-route is nil at the beginning, if I set it to something else, it works, if it’s nil, it doesn’t. Does Om Next skip mounting components where the values of the queries end up being nil?

I don’t know the exact behavior, but it does something like that … when I did a small experiment starting with an empty app state and getting data from the remote it did not render my root component until the remote return value (instead of nil)

i’m not sure if it was just initial or what tho

hmm I just checked my routing logic, my app doesn't complain about my initial route not being a part of the appstate

I had nothing to do with routing though, it just was the parse result was nil for the component

It probably depends on what your app does with that nil

(defui Root
  static om/IQuery
  (query [_]
    [{:current-user (om/get-query User)}])
  Object
  (render [this]
    (dom/div nil
             (user (-> this om/props :current-user)))))

My app is just printing it out. componentDidUpdate doesn’t even run.

it didn’t even call render if :current-user was nil on at least add-root!

I didn’t go back and forth tho, just noticed it on add-root! … so no idea the full behavior

I had put logic in there to render loading if nill and was like ‘whats going on!’ 😜

Ok… this feels annoying… I guess I could replace nil for {} for current-route.

I’m glad it’s not just me.

might be this logic : https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1506-L1515

@dnolen: Ooops. I just tried it, and it turns out I mis-read the code (@state was the reconciler state not app state). Mind if I add an option to the construction of the reconciler to allow hand-normalization of the initial state?

docs reverted for the time-being

@tony.kay: I think maybe the docs should just be more clear how to allow hand normalization

if you pass an app-state atom I believe the default is that it’s not normalized for you

I'm looking for the combo of hand-normalized initial state, but with normalization turned on

there is no way to get that combo

@tony.kay: pass app-state atom + :normalize true

if that doesn’t work, then that’s a bug

OK...then I'll test that and submit a PR if it is broken (which I think it might be)

add-root has this `(when (and (:normalize config) (not (:normalized @state)))`

and nothing sets normalized...it is just false going in...no way to change it

@tony.kay: yep I confirm that

the fix is simple: change this line https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1829 to norm?

@tony.kay: @anmonteiro beat me to it

PR welcome no need for an issue

there should also be something to do wrt. to :normalize though

(or (not norm?) normalize) -> (or normalize (not norm?))

I think the order is wrong

@anmonteiro: ha that too, fine if in the same PR

I'm just chiming in, I think @tony.kay will do it

@aria_ I think the single immutable atom is an implementation detail that’s orthogonal to the way a component expresses what it wants to see of the world. I think that om.next separates how the world is represented(one or more atoms or some other state strategy) from how the component thinks about the world.

Depending on the current-route, I dispatch and call different factories to render different subcomponents, but I also need the queries of these subcomponents. Should I do it by calling om/set-query or is there a better way?

https://github.com/omcljs/om/wiki/Routing-Support

Yes, om/set-query is currently the way to go.

sorry...had (and have more) meetings. @anmonteiro if you want to fix that...go for it!

Does this make sense, to update the current-route (app state) and the query (to include the query of the sub-component): https://gist.github.com/pupeno/2a67bca78ee0627aa2aa#file-layout-cljs-L16-L20

Is om.core in the latest 1.0 alphas considered "production-ready"?

@peeja: not really, haven’t done any testing on that stuff

Damn. Fair enough.

It looks like there's no way to use Devcards without Om 1.0 (ie, React 0.14)

I’ve been using the om 1 alphas for old om in production for a bit

I'm going to try using the alphas in a devcards-only profile, which should work, but obviously just running 1.0 in production would be simpler

@minimal: Well, that's good to hear

Get some react warnings in dev and had to replace one function get-node

I needed react 0.14 and devcards too

I removed (.getDOMNode)from my version of get-node

@anmonteiro: not sure what you're talking about on order. OR is commutative, and the short-circuit doesn't matter

@tony.kay: right, maybe that line doesn't need changing after all

I'm submitting PR now

@tony.kay: cool

@frankie: For basic routing I have been using a mix of secretary and OM.next. I usually have a parameter on the Root UI view that I set via set-query! from my “defroute” to pass in anything additional from route info...

@tmorten: do you have a more-root-than person-dashboard/RootView ?

ah nvm, is mount setting it as the root?

:thumbsup:

might not be the most straight forward or “cool” but works for me

no I really like it … I don’t know why I that hadn’t cross my mind to switch out roots like that on routing

do you know what the behavior is like between the add-root! and set-query!?

I know some people like to flip-out the different “views” inside a root view based upon state, but that just never works that great for me.

e.g. before something like the id is set

yah, for some reason that is where my mind just immediately went

but this is another good perspective to think about

The RootView needs to be mounted before you can actually set-query! on the component

yah, and so it kind of reconciles twice? once without an id, once with? or do you just not notice any kind of in between state?

maybe all that jazz is queued so it only happens once

maybe reconcile is not the word … but like parsing, e.g. sending a remote query once on add-root! and once on set-query!

It does but I think I have it handled via lifecycle methods in component

thanks!

I set initial parameter to nil

(params [_] {:id nil})

thanks for description it does seem like it would be nice to be able to set initial params on add-root!

@hueyp: no problem. I have a small app in production and this method has been working for me thus far