This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-19
Channels
- # aatree (33)
- # admin-announcements (70)
- # alda (6)
- # aleph (2)
- # announcements (6)
- # aws (7)
- # beginners (40)
- # bitcoin (1)
- # boot (138)
- # cider (24)
- # cljs-dev (9)
- # cljsjs (18)
- # cljsrn (35)
- # clojars (4)
- # clojure (211)
- # clojure-art (4)
- # clojure-austria (2)
- # clojure-hamburg (8)
- # clojure-russia (66)
- # clojure-sg (3)
- # clojured (1)
- # clojurescript (73)
- # cursive (9)
- # datomic (124)
- # dirac (8)
- # editors (3)
- # emacs (13)
- # euroclojure (10)
- # hoplon (207)
- # jobs (4)
- # ldnclj (27)
- # lein-figwheel (3)
- # leiningen (10)
- # mount (5)
- # music (1)
- # off-topic (9)
- # om (92)
- # onyx (36)
- # perun (30)
- # proton (47)
- # re-frame (11)
- # reagent (11)
- # ring-swagger (7)
- # yada (2)
Sorry, repeating question:
@dnolen: @anmonteiro : Here, in 2nd sinppet https://github.com/omcljs/om/wiki/Components,-Identity-&-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?
@andrewboltachev: just write your own parse function if you need your own behavior
parse
is a function of a specific signature and behavior, anyone can write something that satisfies it
@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
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
trying to use (om/props this)
in either the Query directly or via QueryParams breaks the component ;(
thanks. any opinion about whether to do this or merge the associated entity data in the according read function instead?
@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?
also, thanks for putting together the template and blog posts!
@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
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))
(the :dom-com/props
read method always uses recursive parsing to get whatever it needs)
makes sense, thanks! i’ll give it a try
@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?@stuarthinson: not sure what you mean by the read
method having a problem?
@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?
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.
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
Ideally I would image this to have a simple declarative way of expressing it and I don't see that yet.
With my current understanding, I could use functions, wrappers or macros to achieve it, but this seems very cumbersome for such a common need
and avoid reading stuff (which doesn’t sound like a good idea to me), and setting the query at runtime
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)
which is to say, I don’t have an answer but maybe you can help figure out what it should be
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)
@nblumoe: right, though I’m not really concerned about perceived modeling issues with set-query!
it may not be the ideal solution for your specific case, but that’s just another concern
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...
OK, thanks again. I just thought I might have been missing something, but apparently not.
if this happens after view presentation, then you should be perfectly fine with set-query!
if the id can be supplied before view presentation then what I suggested could be a reasonable alternative
for the B) case you need set-query!
, for A) you could do something else like I’ve already suggested
because I found it not very elegant having to put it into componentDidMount
when actually not needed to rely on the component lifecycle
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?
@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.
the query for any component’s data must be the full query for that component to the root
full-query
is the entire query that leads to that component with the other stuff elided
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.
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?
https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/autocomplete.cljs#L32
or
should be there. (in tutorial it's correct https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial#code )
Should one report (to GitHub) issues as little as this?
I put an observe on app-state and it triggered my rendered-state, but when I observe sub items they don't trigger it.
I recently upgraded to the latest version of ClojureScript, but my version of Om is at .90
@markstang: make a minimal thing and file an issue - don’t link to a project or anything like that