This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-03
Channels
- # admin-announcements (2)
- # alda (4)
- # beginners (15)
- # boot (89)
- # cljs-dev (88)
- # cljsrn (75)
- # clojure (149)
- # clojure-belgium (16)
- # clojure-france (2)
- # clojure-greece (6)
- # clojure-russia (108)
- # clojure-spec (39)
- # clojure-taiwan (3)
- # clojure-uk (7)
- # clojurescript (70)
- # css (3)
- # cursive (17)
- # data-science (2)
- # datascript (7)
- # datomic (41)
- # dirac (3)
- # hoplon (12)
- # instaparse (1)
- # juxt (3)
- # lambdaisland (9)
- # mount (4)
- # off-topic (6)
- # om (71)
- # om-next (4)
- # onyx (22)
- # other-languages (56)
- # perun (15)
- # proton (6)
- # re-frame (32)
- # reagent (42)
- # specter (34)
- # spirituality-ethics (7)
- # tmp-json-parsing (5)
- # untangled (13)
- # vim (4)
- # yada (6)
there is an example of using props in the query in "Routing with subquery" in https://anmonteiro.com/2016/02/routing-in-om-next-a-catalog-of-approaches/
static om/IQuery
(query [this]
(let [subq-ref (if (om/component? this)
(-> (om/props this) :app/route first)
:app/home)
subq-class (get route->component subq-ref)]
[:app/route {:route/data (om/subquery this subq-ref subq-class)}]))
in a parent component I am passing props to a child, I want to filter data in the child based on some property thatās passed via props
check if they are available with (om/component? this)
and then get them as usual if so
I probably can do it in willMount and willReceiveProps of child with update-query!
but Iām hoping thereās simpler way
guys if I have data (props) that look like this:
{:app/foo ({:id "cd137a51-6591-449b-9ad9-871d3216b3f7", :name āfooā, :description ā⦠etc
how should my query look like if I only need name
and description
?
I am so confused with this whole query thingor should I do om/tree->db
before passing the props, because when I do my data looks like this:
:app/foo [{:id "cd137a51-6591-449b-9ad9-871d3216b3f7", :name "foo", :description "⦠etc
[{:app/foo [:name :description]}]
would be the root query, but you might have a bug because the value there is a list (not a vector) and afaik Om doesnāt support querying on lists.
So in your parser you are probably returning the result of map
or for
. If thats the case you could fix it by dumping the result into a vector e.g. (into [] (map some-fn some-coll))
or (mapv some-fn some-coll)
Sorry, I just read above and it sounds like you are doing this in your render function. In that case queries donāt have too much to do with it. The child component will get the props you pass it in the render function.
Iām trying to dynamically change query of the root based on query of a child and the pass the right data to the child
@ag There is a chance that what you are trying to do with dynamic queries could be done without them. I'm sure they must have a purpose, but I don't understand why the dynamic part (say what has been selected to be sorted on or whatever) can't just be stored in the app state.
@cjmurphy: I need to 1) for a given route in :app/current-route
find a matching component class, 2) get its query, and 3) render that component in my root component, thatās it. 4) Also I need to be able to pass route-params into the component and somehow filter data based on those params
I am utterly frustrated right now, itās been 2 weeks and I canāt build even simple stuff with Om Next.
I picked up @anmonteiroās tutorial (without his blogposts I wouldāve completely lost) and Iām trying to make something very basic⦠I have navbar with menu items, and components that Iād like to render dynamically. Rendering part is easy. Manipulating data with queries is extremely confusing
You can do stuff as dynamic as you like without set-query, IQueryParams. You have to get pretty familar with altering the default db format - but that's kind of the only hard bit. My experience is that you can do what you like on the client without touching the AST. I happen to use Untangled. But I think the only feature of it I use is for loading some of the state hand normalized.
I guess I should say I actually don't use Om on the server at all. But even if I was I would be using Untangled for the reason that with Untangled you don't have to fiddle with the AST on the client, only on the server.
One of the great things about Jannis's Kanban is that he avoided all the complex stuff. And yet showed you could do reasonably complex things.
Ok @anmonteiro so I solved getElement error I was getting by doing this
(componentDidMount [this]
(go (while (nil? (gdom/getElement "node4"))
(<! (timeout 20)))
(.addEventListener (gdom/getElement "node4") "mouseover" #(js/alert "hello nĆŗmer 4"))))
(where timout is this function)
(defn timeout [ms]
(let [c (chan)]
(js/setTimeout (fn [] (close! c)) ms)
c))
Bit un-omish, but works perfectly.@hlolli: yeah I'd never do that but if it works for you
IMHO React has its lifecycle methods for a reason, and you could take advantage of that
You might not realize this, but you have access to (om/props this)
in the lifecycle methods as well
So instead of doing async stuff you can simply check that the prop you want is there
Then component is pure again!
hmm, yes I need to access the properties here, but just not shown in this example, there I have all the styling and info for popup windows I need to generate on element clicks. But you gave me one thought tough, to access the name for "node4" trough the properties, which I have in a map (along with all elements that I need to target). I never tried that, hopefully it will wait for the string to arrive... 5 mins...
@hlolli: as I said yesterday it'll probably not be there in componentDidMount
but it should be there after the remote call in componentDidUpdate
there exists componentDidUpdate
, I read about it many times, but totally forgot about that lifecycle part.
{:value {:keys [:ui.entities/selected]}
:action (fn []
ā¦)}
what does :value :keys
do exactly i could not figure this out from the docs it only says it has no effect on rendering
If this is a transactor, then :value tells which key the reconciler needs to re-render and action would be the function, many times atom swapping.
:value :keys
doesn't do absolutely nothing
It's just there as documentation so that you remember which keys you should put after the transact!
call
Aha ok.. seems weird to not to just use them then.. Is there a particular reason for this?
Thanks for clearing it up though @anmonteiro
No reason, they existed as :value
only before tempids were implemented so as to have a common shape between the result of mutations & reads
@mitchelkuijpers: feel free to add this to the FAQ if it's not there, it comes up a lot
Would be nice to have a place to link to
@anmonteiro: Will do
@anmonteiro: https://github.com/omcljs/om/wiki/Om-Next-FAQ#what-does-value-keys--do-from-a-mutation-result-map there you go
Hey, Iām reading om/transit.cljc
and I see:
(:require [cognitect.transit :as t]
#?(:cljs [com.cognitect.transit :as ct])
Why are there 2 transit namepsaces?
what is com.cognitect.transit
transit-cljs also requires that
https://github.com/cognitect/transit-cljs/blob/master/src/cognitect/transit.cljs#L17
it would be great if something like this was built in to om next: https://github.com/untangled-web/untangled-client/blob/a179b7624382556fd1abdf74755dcded5f3e4405/src/untangled/client/impl/data_fetch.cljs#L60-87
@isak: Om has you write the plumbing and logic for all of that...part of the reason Untangled exists.
The only way to pre-provide those kinds of things is to nail down things that Om is trying to keep open, such as knowledge of the database format