Fork me on GitHub
#om
<
2016-04-06
>
stuartsierra14:04:20

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?

stuartsierra14:04:05

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

stuartsierra14:04:16

Do you pass functions as :opts?

anmonteiro14:04:28

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

isak14:04:19

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

martinklepsch15:04:52

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

martinklepsch15:04:07

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

stuartsierra15:04:19

@martinklepsch: I believe that is the case, yes

stuartsierra15:04:33

The om.core namespace is Om.now.

martinklepsch15:04:32

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

martinklepsch15:04:55

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

anmonteiro15:04:38

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

anmonteiro15:04:42

it's not supported by React

anmonteiro15:04:12

you can use js/React.dangerouslySetInnerHTML

martinklepsch15:04:07

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

martinklepsch15:04:42

I guess maybe that was merged after 0.14.7

martinklepsch15:04:12

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

martinklepsch15:04:52

(the other project is reagent - forgot to mention)

anmonteiro15:04:04

@martinklepsch: I suppose that's a JSX thing

anmonteiro15:04:16

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

anmonteiro15:04:05

I don't know how Reagent makes it possible though

anmonteiro15:04:09

maybe that's worth looking into

stuartsierra15:04:55

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

anmonteiro16:04:05

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

martinklepsch16:04:08

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

martinklepsch16:04:35

I really miss my hiccup

anmonteiro16:04:09

@martinklepsch: you can definitely use Sablono with Om

martinklepsch16:04:22

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

martinklepsch16:04:02

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

anmonteiro16:04:17

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

kendall.buchanan21:04:33

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?

kendall.buchanan21:04:50

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

hueyp21:04:52

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

hueyp21:04:06

but its not required at all

kendall.buchanan21:04:00

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

hueyp21:04:01

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

hueyp21:04:55

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

hueyp21:04:04

just a bit of context~

kendall.buchanan21:04:15

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

hueyp21:04:23

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

hueyp21:04:41

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

kendall.buchanan21:04:17

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

hueyp21:04:37

the mutations yah, not the query props

hueyp21:04:13

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

hueyp21:04:21

but recursive parsing is not a requirement

hueyp21:04:25

its just one way to do things

kendall.buchanan21:04:56

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

taylor.sando21:04:09

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.

kendall.buchanan21:04:24

This is straight from the Om tutorial…

kendall.buchanan21:04:26

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

kendall.buchanan21:04:43

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

kendall.buchanan21:04:55

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

kendall.buchanan21:04:15

In which case, the namespaces are essential, right?

hueyp22:04:47

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

hueyp22:04:53

so your root keys need to be unique

hueyp22:04:01

since that is what the parser dispatches on

hueyp22:04:25

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

hueyp22:04:39

where :app is root, etc

hueyp22:04:28

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

hueyp22:04:13

this is probably not useful discussion tho simple_smile

kovasb22:04:01

I'm having trouble merging path-optimized query results

kovasb22:04:12

I'm querying on an ident to the remote

kovasb22:04:23

stuff comes back, and somehow the state gets bonked

kovasb22:04:40

is there a canonical :merge override?

kovasb22:04:18

this is with alpha31

tomjack22:04:27

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

kovasb22:04:10

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

tomjack22:04:34

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

tomjack23:04:25

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

kovasb23:04:56

yes ive instrumented all those things

kovasb23:04:30

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

kovasb23:04:57

will instrument some more..

tomjack23:04:18

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)

tomjack23:04:26

the default merge-tree is basically useless simple_smile

kovasb23:04:51

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

tomjack23:04:50

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