Clojurians
#om
<
2016-01-19
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

andrewboltachev03:01:21

Sorry, repeating question: @dnolen: @anmonteiro : Here, in 2nd sinppet https://github.com/omcljs/om/wiki/Components,-Identity-&amp;-Normalization#adding-reads are '[:name :points] just for documentation purposes? I mean in this particular case. For me it seems that it isn't ever passed to read-fn, and get-people is doing all the job for deciding on whatever fields would be passed to Person component. Would read-fns in the future accept trees (say, {:list-one [:name :points]}) as a key, instead of single keys, or is that wrong thinking?

dnolen03:01:24

@andrewboltachev: just write your own parse function if you need your own behavior

dnolen03:01:38

there’s nothing about the defaults that say you need to be constrained by them

dnolen03:01:05

parse is a function of a specific signature and behavior, anyone can write something that satisfies it

andrewboltachev03:01:28

@dnolen: I know you said in one talk that there might be different types of clients, e.g. mobile just needs :name and :price, and desktop one :description also. I started to think that these query parts will do exactly this, i.e. fetch needed fields (with arbitrary level of nesting). If I can't get this working now so probably I'm missing something. But thanks, I'll try to write parse fn (and other stuff, if necessary) which does exactly this

nblumoe14:01:16

Is it possible to get lookup refs to associated data resolved, simply with the correct query alone? Or do I need to manually wire this up in a read function? I can get it to work with something like (query [this] [{[:users/by-id 10] [:user/name]]) But instead of a hardcoded id 10 I would need to retrieve the id from the component's props

nblumoe14:01:58

trying to use (om/props this) in either the Query directly or via QueryParams breaks the component ;(

dnolen14:01:15

query needs to work without instantiating the component so you can’t do that

dnolen14:01:31

you could invoke set-query! on the component when it mounts

nblumoe14:01:57

thanks. any opinion about whether to do this or merge the associated entity data in the according read function instead?

stuarthinson14:01:12

@anmonteiro working on my first om next app with aemette - should my remote parser’s read be aware of dom-com/props? if not, any tips on writing the read in clojurescript such that only the contents of dom-com/props are requested from the remote?

stuarthinson14:01:44

also, thanks for putting together the template and blog posts!

anmonteiro14:01:46

@stuarthinson: the remote parser should not be aware of dom-com/props; this is a made-up thing to hold the query for the current route. What actually matters is parsing whatever is inside it

anmonteiro14:01:30

here's an example:

(defn recurse-remote
  [{:keys [parser target query state ast] :as env}]
  (let [v (parser env query target)]
    (if (or (empty? v) (nil? target))
      {:value v}
      {target (update ast assoc :query v)})))

(defmethod read :dom-com/props
  [{:keys [parser query ast target] :as env} k params]
  (recurse-remote env))

anmonteiro14:01:05

(the :dom-com/props read method always uses recursive parsing to get whatever it needs)

stuarthinson14:01:26

makes sense, thanks! i’ll give it a try

stuarthinson15:01:10

@anmonteiro thanks! i needed to tweak recurse-remote to

(defn recurse-remote
  [{:keys [parser target query state ast] :as env}]
  (let [v (parser env query target)]
    (if (or (empty? v) (nil? target))
      {:value v}
      {target (om/query->ast v)})))
is that an indication that the read corresponding to the component’s query has a problem?

anmonteiro15:01:18

@stuarthinson: not sure what you mean by the read method having a problem?

dnolen17:01:21

@nblumoe: your approach just seems a bit backwards to me

dnolen17:01:42

obviously the parent component has the ident if you’re going to pass it as props

dnolen17:01:07

so I don’t really see why the child component needs it at all in this case

nblumoe18:01:59

@dnolen so, the child component should have the "foreign key" in its query and the parent component would use that on rendering to inject the relevant foreign attributes into the child components props?

dnolen18:01:28

@nblumoe: no

dnolen18:01:41

construct your queries like all the example show

dnolen18:01:03

the join key is in the parent, the query is provided by the child

dnolen18:01:07

in this case the join key is an ident

nblumoe18:01:08

Whereas the ident cannot specify an ID then, at least not in the static methods

dnolen18:01:50

right that doesn’t change at all

dnolen18:01:57

just talking about overall approach

nblumoe18:01:44

Oh yeah, that's fine and I think I have the proper understanding of why this has to be like that in the static methods, thanks.

nblumoe18:01:56

Nevertheless, there is the need to resolve a specific foreign entity and I can see at least the two approaches of doing it from the reader or via runtime query modifications

nblumoe18:01:09

Ideally I would image this to have a simple declarative way of expressing it and I don't see that yet.

nblumoe18:01:42

Something is missing for me to get this I guess

dnolen18:01:20

you can probably do this with an inline link

nblumoe18:01:39

With my current understanding, I could use functions, wrappers or macros to achieve it, but this seems very cumbersome for such a common need

dnolen18:01:46

and avoid reading stuff (which doesn’t sound like a good idea to me), and setting the query at runtime

dnolen18:01:05

@nblumoe: none of those approaches seem desirable or necessary

dnolen18:01:31

read the Thinking With Links tutorial and see if you can see how it can be done

nblumoe18:01:02

Will have a look again. But I am afraid I read this often enough already (too often? ;), also the other resources. And it does not have an example for a dynamic link, but only a simple root attribute (which was easy to get working)

dnolen18:01:15

what I’m suggesting is that maybe it should work and you should try it

dnolen18:01:28

if it doesn’t work then maybe we should make it work

dnolen18:01:49

which is to say, I don’t have an answer but maybe you can help figure out what it should be

nblumoe18:01:15

set-query! worked out course, but I found it less than ideal having to define the query twice (yes, can be dry with another function/var) and also to retrieve that data from the props then without having to reshape it beforehand upstream (e.g. in reader or parent component)

dnolen18:01:25

{[:current-user _] …}

dnolen18:01:50

where that resolves to yet another link, which itself will get resolved

dnolen18:01:00

then you don’t need to bother with all this extra stuff

dnolen18:01:54

@nblumoe: right, though I’m not really concerned about perceived modeling issues with set-query!

dnolen18:01:04

it works how it works and I’m not interested in changing it

dnolen18:01:43

it may not be the ideal solution for your specific case, but that’s just another concern

nblumoe18:01:06

Hm, but there is no single for state I could resolve to. Of course I have users/by-id but obviously this needs an ID to resolve it. And I want to show multiple associated entities on a single page...

dnolen18:01:34

but the id must come from somewhere

nblumoe18:01:38

OK, thanks again. I just thought I might have been missing something, but apparently not.

dnolen18:01:46

if this happens after view presentation, then you should be perfectly fine with set-query!

dnolen18:01:26

if the id can be supplied before view presentation then what I suggested could be a reasonable alternative

nblumoe18:01:31

Yes, the ID is an attribute of entity A pointing to an entity B, simple foreign key

dnolen18:01:45

this part is not relevant for the discussion we’re having

dnolen18:01:56

only the two points I said above

dnolen19:01:12

either A) you have the data before your view renders or B) you don’t

nblumoe19:01:13

Just said, WHERE the ID come from

dnolen19:01:22

that’s not what I’m talking about

dnolen19:01:43

for the B) case you need set-query!, for A) you could do something else like I’ve already suggested

nblumoe19:01:21

Ah okay, gotcha!

nblumoe19:01:55

Will play around with the options for A)

nblumoe19:01:10

because I found it not very elegant having to put it into componentDidMount when actually not needed to rely on the component lifecycle

nblumoe19:01:27

Thanks for taking the time, David! :+1:

hugod19:01:48

In a list with a component for each item in the list, deleting an element from the list causes reconcile! to look at the item’s row component, and try to calculate new props for it. Unfortunately, the query it uses for this is the component’s local query rather than the full query. The row component has an ident, but it doesn’t seem to be used to calculate the result from full-query. It has a parent set, but path returns nil on the component. I’m at a loss to see what to change so that the reconcile! uses the correct query. Should it have a path set? Why isn’t the ident being used?

dnolen19:01:26

@hugod: too little and too much information here - some minimal case would be useful.

hugod19:01:36

@dnolen: ok, I’ll try and extract something - this is with React Native if it makes a difference. It seems I don't understand the logic around how full-query works.

dnolen19:01:31

the query for any component’s data must be the full query for that component to the root

dnolen19:01:51

full-query is the entire query that leads to that component with the other stuff elided

dnolen19:01:39

it has to work that way for the obvious reason that child queries are contextless

dnolen19:01:47

they don’t mean anything without the parent query

hugod19:01:36

Right, that is the theory, but it seems to be using an unrooted query in this case, and I’m not sure which mechanism for going back to the root is not working.

hugod19:01:52

It seems it could do it through parent or ident or path

dnolen19:01:56

right this just grabbing at straws

dnolen19:01:06

it could be bug in your code or in Om

dnolen19:01:10

need a minimal case

jlongster20:01:44

I'm using (om/factory Component {:keyfn :id}) and id is definitely a proper id, but it doesn't look like the component is getting a key property (looked at the component tree with React devtools). anyone else seen this?

jlongster20:01:22

it's probably my fault

jlongster20:01:47

oh, nm yep it's my fault.

markstang22:01:29

Has anything changed with ref-cursors with the new release of ClojureScript?

markstang23:01:12

Or has anyone had any issues with ref-cursors not firing?

dnolen23:01:45

I haven’t heard anything so far

markstang23:01:18

I put an observe on app-state and it triggered my rendered-state, but when I observe sub items they don't trigger it.

markstang23:01:46

I recently upgraded to the latest version of ClojureScript, but my version of Om is at .90

markstang23:01:06

[org.omcljs/om "0.9.0"]

dnolen23:01:35

@markstang: make a minimal thing and file an issue - don’t link to a project or anything like that

dnolen23:01:47

you should be able to demonstrate the problem with a few lines of code inline in the issue