In Om.now, if you want to make a "higher-order" component, how do you pass it the constructor functions for the components it uses?

If you include the function in props, it messes with the equality check in shouldComponentUpdate. Or I think that's what's happening.

Do you pass functions as :opts?

@stuartsierra: I think the way to do it is to use :opts

just like in this example: https://github.com/swannodette/om-sync/blob/master/src/om_sync/core.cljs#L130

thanks

when sending normal queries to the server, are people usually removing the parts that have no reification in the database?

If I get the latest om build from clojars, will that contain a usable version of om.now?

like om.now and next are in the same jar could that be?

@martinklepsch: I believe that is the case, yes

The om.core namespace is Om.now.

@stuartsierra: thanks!

kind of weird from a packaging perspective but dealing with a legacy app I appreciate it

Is there something special needed to use the SVG <use> tag? It's in om.dom since Nov. [1] but when I use it I just get React.DOM.use is not a function. React + React.DOM v0.14.7 loaded. [1] https://github.com/omcljs/om/commit/9f7d988a427e47b2d496fccce3f992b4d025e0ab

@martinklepsch: it's there, but shouldn't be, really

it's not supported by React

https://facebook.github.io/react/docs/tags-and-attributes.html#svg-elements

you can use js/React.dangerouslySetInnerHTML

@anmonteiro: I'm using it in another project without dangerouslySetInnerHTML

this issue/comment makes me think it's supported: https://github.com/facebook/react/issues/1657#issuecomment-197052674

I guess maybe that was merged after 0.14.7

strange that there's no mention about this in the changelog though

(the other project is reagent - forgot to mention)

@martinklepsch: I suppose that's a JSX thing

converted the fiddle in that issue to use React.DOM and it also produces the error

https://jsfiddle.net/chhj2aog/

I don't know how Reagent makes it possible though

maybe that's worth looking into

There's a generic React.createElement, maybe it's using that.

React.createElement("use", {xlinkHref : "#shape", x : "50", y : "50"}) this does indeed work

ah yeah, makes sense since reagent does this whole hiccup transform anyways

I really miss my hiccup

@martinklepsch: you can definitely use Sablono with Om

@anmonteiro: thanks for clearing that up, I'm now just using the danger way

@anmonteiro: yeah I know. This codebase is using om.dom everywhere though and I don't yet feel like breaking with that (yet)

hrm, maybe (js/React.createElement "use" #js {:props ...}) looks better than dangerouslySetInnerHTML

I’m sure this is a common newbie question for Om (and I suppose Datomic), but what’s the value of {:person/name “Jane”} over {:name “Jane”}? Is it to help the code author keep track of context, or is it more meaningful than that?

Reading Datomic Pull documentation, it appears to allow queries to cross relationship boundaries, but how does that relate to Om?

with om.next you define ‘root’ parse methods, but after that its up to you. one common method is to recursively call parse for relations

but its not required at all

Okay, that makes sense, and I suppose recursive parsing loses value when more than one object share the same keys?

e.g. [{:user [:user/name {:user/friends [:user/name]}]}], om.next will call the parser on ‘:user` but its up to you how you want to handle the query part

I’m not sure of all the reasons behind namespaced keys, but in practice I’ve found them handy

just a bit of context~

K, I’m essentially trying to separate out style (and culture) from what’s required (as I learn).

the only area where I’ve found namespace useful apart from style is mutations … e.g. (todo/create {:text ~text}) … if you isntead do (todo-create {:text ~text}) you have to make sure you quote things so as to not namespace todo-create

I’m not sure how to show a ` inside of a code block

K, but that’s a case where you’re namespacing your query names, as opposed to raw data.

the mutations yah, not the query props

for query props not sure other than style, although as you mention if you recursively parse it is then very helpful as how to parse :person/name is always clear vs :name

but recursive parsing is not a requirement

its just one way to do things

Thanks much, this has been super helpful. I thought for sure I was missing out on some deep detail.

Namespaces are mostly to disambiguate similar attributes, and to model domain objects. Similar attributes can just be put into similar namespaces. For example, time/created might make sense for some domains, whereas, person/birthdate might be more accurate for a person.

This is straight from the Om tutorial…

'[:app/title (:animals/list {:start ?start :end ?end})]

Better stated:

(query [this] '[:app/title (:animals/list {:start ?start :end ?end})])

Appears hear that the query is also cutting across object boundaries.

In which case, the namespaces are essential, right?

this might be ‘bad’, but I personally draw a distinction of some queries as ‘root’ and some as inner … like a query [:user/name :user/date-of-birth] … this could be a valid component query, but my parser doesn’t know how to handle it … those aren’t ‘root’ keys

so your root keys need to be unique

since that is what the parser dispatches on

in this case [:app/title] is unique … but it could also be [{:app [:title]}]

where :app is root, etc

or [{:current-app [:app/title]}] or [{:selected-app [:app/title]}] etc

this is probably not useful discussion tho

I'm having trouble merging path-optimized query results

I'm querying on an ident to the remote

stuff comes back, and somehow the state gets bonked

is there a canonical :merge override?

this is with alpha31

@kendall.buchanan: om keeps a map from 'prop' keywords to the component classes querying for them in the indexer

in general the merge functions have gone from 2 to 4 args since i checked last..

if you don't have sufficiently unique prop names, I think too much could wind up there, which could maybe lead to some troubles -- e.g. I think 'follow-on reads' after mutations which use a not-unique-enough key will lead to unnecessary rerendering

@kovasb: have you looked already at overriding just :merge-tree?

yes ive instrumented all those things

theres a number of calls happening an unfortunately its a little tricky to see which one is corrupting

will instrument some more..

I don't think there is a canonical merge override. so far I have only had to override merge-tree, which is called from the default merge (but maybe your situation is different)

the default merge-tree is basically useless

have you gotten it to work with path optimized server reads?

no, I don't even know what path optimized server reads are. but in any case the default merge-tree seems unlikely to work correctly