Fork me on GitHub
#om
<
2016-02-10
>
jamesnvc00:02:16

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?

tony.kay02:02:38

@jamesnvc: See above: om/computed

tony.kay02:02:26

syntactically, I guess you could make a helper function simple_smile

jamesnvc02:02:28

Ah, cool; thanks!

nblumoe07:02:11

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

malcolmsparks11:02:25

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.

doddenino12:02:02

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?

anmonteiro12:02:07

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

anmonteiro12:02:14

like in defrecord & deftype

stuartsierra13:02:41

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

doddenino13:02:46

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!

kauko17:02:50

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

kauko17:02:09

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

frankiesardo17:02:47

Currently hit a roadblock with om.next routing

frankiesardo17:02:08

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

frankiesardo17:02:16

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.

frankiesardo17:02:57

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

frankiesardo17:02:38

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

tony.kay17:02:01

@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?

dnolen17:02:23

@tony.kay: yes, go for it

dnolen17:02:03

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

pupeno17:02:34

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

dnolen17:02:37

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

dnolen17:02:50

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

frankiesardo17:02:15

I see, thanks for the answer

dnolen17:02:34

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

frankiesardo18:02:26

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

frankiesardo18:02:53

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

dnolen18:02:35

you can experiment something which I’ve suggested many times

dnolen18:02:59

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

dnolen18:02:58

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

frankiesardo18:02:43

Thanks, will do

pupeno18:02:36

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.

pupeno18:02:08

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?

pupeno18:02:07

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

pupeno18:02:51

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.

pupeno19:02:05

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?

hueyp19:02:34

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)

hueyp19:02:45

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

iwankaramazow19:02:50

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

hueyp19:02:24

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

iwankaramazow19:02:11

It probably depends on what your app does with that nil

hueyp19:02:50

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

pupeno19:02:53

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

hueyp19:02:09

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

hueyp19:02:27

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

hueyp19:02:51

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

pupeno19:02:18

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

pupeno19:02:33

I’m glad it’s not just me.

tony.kay19:02:42

@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?

tony.kay19:02:25

docs reverted for the time-being

dnolen19:02:55

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

dnolen19:02:15

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

tony.kay19:02:28

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

tony.kay19:02:42

there is no way to get that combo

dnolen19:02:46

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

dnolen19:02:53

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

tony.kay19:02:13

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

tony.kay19:02:47

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

tony.kay19:02:51

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

anmonteiro19:02:12

@tony.kay: yep I confirm that

dnolen19:02:45

PR welcome no need for an issue

anmonteiro19:02:50

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

anmonteiro19:02:11

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

anmonteiro19:02:18

I think the order is wrong

dnolen19:02:40

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

anmonteiro19:02:57

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

mangr3n19:02:58

@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.

pupeno20:02:26

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?

iwankaramazow20:02:03

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

tony.kay20:02:03

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

pupeno20:02:47

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

peeja20:02:45

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

dnolen20:02:37

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

peeja21:02:14

Damn. Fair enough. simple_smile

peeja21:02:39

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

minimal21:02:28

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

peeja21:02:53

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 simple_smile

peeja21:02:13

@minimal: Well, that's good to hear

minimal21:02:49

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

minimal21:02:58

I needed react 0.14 and devcards too

minimal21:02:00

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

tony.kay21:02:33

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

anmonteiro21:02:36

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

tony.kay21:02:57

I'm submitting PR now

tmorten21:02:41

@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...

hueyp21:02:07

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

hueyp21:02:40

ah nvm, is mount setting it as the root?

hueyp21:02:10

:thumbsup:

tmorten21:02:33

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

hueyp21:02:55

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

hueyp21:02:55

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

tmorten21:02:07

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.

hueyp21:02:08

e.g. before something like the id is set

hueyp21:02:21

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

hueyp21:02:30

but this is another good perspective to think about

tmorten21:02:34

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

hueyp21:02:05

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?

hueyp21:02:42

maybe all that jazz is queued so it only happens once

hueyp21:02:50

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

tmorten21:02:05

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

tmorten21:02:21

I set initial parameter to nil

tmorten21:02:34

(params [_] {:id nil})

hueyp21:02:13

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

tmorten21:02:34

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