in om.next: how can I pass computed props down from parent to grandchildren implicitly, sort of like clojure binding macro

I’m trying to use dom/use, and i’m getting a Cannot read property ‘apply’ of undefined error. Any ideas?

It does seem to render properly anyway though.

@levitanong probably because React.DOM.use doesn’t exist

I have a feeling that the use tag shouldn’t be in om.dom

It actually is in there though 😮

try js/React.createElement “use”

https://github.com/omcljs/om/blob/master/src/main/om/dom.cljc#L138

what is there?

the use tag

I know. I have a feeling it shouldn’t be though

as in, we should remove it.

ahh. Why though?

oh wait

because React.DOM.use doesn’t exist

https://github.com/omcljs/om/blob/master/src/main/om/dom.cljc#L142

Wham, I have a comprehension problem

haha! okay I get it now

np

That’s odd though, because react supports the xlinkHref attribute

which afaik, only use uses

my feeling is that JSX translates to React.createElement

so that it can work with user-created components

so they don’t really maintain React.DOM elements that much?

dang, that’s a cryin’ shame

will try out your suggestion, brb

ooof, that’s tricky. server side rendering 😛

right, you can still use dom/use on the server though

ah, and that’s why it seems to work client-side

because the server is sending the use tag already rendered. Is that it?

That fixes the issue, thanks @anmonteiro!

I guess that’s a case for keeping use in dom

yeah that might be right

for the prerendering

yeah

Perhaps in that case we can make dom/use switch to createElement instead of react.DOM?

@levitanong IMHO what we should have is a function on the server side that acts like React.createElement

so that we can render all elements that React doesn’t support on the server too

That sounds good

@levitanong can you open an issue please?

@anmonteiro happy to. would dom/____ still be the call though? or would there be a new public function altogether?

@levitanong should be a new funcition like dom/create-element or something

@anmonteiro done

👍

Any obvious reason that I am missing that om/component? returns false on a component specified with defui … ?

(om/component? ColumnList)

(defui ColumnList
  static om/IQueryParams
  (params [this]
          {:id nil})
  static om/IQuery

@alex-glv that’s because ColumnList is not a component

this is probably not clear to everyone, but by component we mean the instance

and ColumnList is a component class

ok, so

((om/factory ColumnList))

yeah

sorry that was wrong

(om/factory ColumnList) will return a factory

((om/factory ColumnList)) will return a component, yes

Makes sense now, cheers!

Does send always receive the entire root query as processed by the parser?

or does it sometimes only get a subset when part of the page changes?

@peeja send will receive a map of {target => query}

and query will be what you return from your parser’s target

if you return true, it’ll be the root query, I suppose

but you can transform the AST

Right, I get that

What I mean is, will it be the transformation of the entire root query, or will it sometimes only be the transformation of one or two keys' worth?

if you return target ast, it’ll be ast->expr of the AST you return

The parser doesn't always run against the entire root query, does it?

Or, rather, the non-target reads don't. Do the target reads?

@peeja oh I get what you’re asking. I think full-query is only ever passed to the parser in local mode

If I set-query! a component, will my remote only get a part of the query that it gets when the page loads, because that's all the parser had access to this time around?

I guess the easiest way to think about it is: if my reads all have {target true}

so the send would normally get the raw query

https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L1352

it’ll be the root

Ah, perfect, that's exactly what I'm after. Thanks!

Still trying to get my head around what's incremental and what's not

the incremental part is only in the async rendering loop

Has anyone found a good approach to spec the parser’s read and mutate fns?

@jfntn Is it especially difficult?

(I haven't tried, but I'm curious)

I’ve found it tricky yes

I had a hack using a multimethod on the dispatch key for spec’ing the args, but you end up defining a predicate rather than a real spec so that doesn’t compose as well for complex params

Is it just that multimethods themselves are tricky to spec?

And for return values I came up dry so far

Yeah I don’t think there’s any om-specific here

I mean, I'm not sure I can imagine a spec that wouldn't cover all reads and mutates in all apps

Is it appropriate for a spec to get more specific than that?

not sure what you mean?

@jfntn May we see a code snippet to get more context?

Possibly anyone working on om.next app that implements navigation and traditional CRUDy things. I’d like to take a look for some implementaion patterns, ie how to pass filter / constraints, navigate between entities etc.

@levitanong scraped my last attempt, will make sure to post here when I try again