Fork me on GitHub

there is an example of using props in the query in "Routing with subquery" in


(not to necessarily suggest that what you are doing is sensible. I dunno.. 🙂 )


@tomjack: I know that article, it’s not answering my question though


static om/IQuery
  (query [this]
    (let [subq-ref (if (om/component? this)
                     (-> (om/props this) :app/route first)
          subq-class (get route->component subq-ref)]
      [:app/route {:route/data (om/subquery this subq-ref subq-class)}]))


that doesn't answer your question?


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


right there is an example of how to get props in IQuery when they are available


check if they are available with (om/component? this) and then get them as usual if so


@tomjack: the props won’t be available in the query, via om/props


it’s not as straightforward as it looks


I probably can do it in willMount and willReceiveProps of child with update-query! but I’m hoping there’s simpler way


they won't be available when query is called statically, of course


right, but do I have access to query params?


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 thing


or 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


Ah. I haven’t used dynamic queries at all so I probably can’t help you out 😕


@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


Every time I feel that I’m close, I realize it’s not working


I am utterly frustrated right now, it’s been 2 weeks and I can’t build even simple stuff with Om Next.


I avoided routing as well because I don't understand its purpose either.


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)
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

Yehonathan Sharvit13:06:36

Hey, I’m reading om/transit.cljc and I see:

Yehonathan Sharvit13:06:50

(:require [cognitect.transit :as t]
   #?(:cljs [com.cognitect.transit :as ct])

Yehonathan Sharvit13:06:06

Why are there 2 transit namepsaces?

Yehonathan Sharvit13:06:20

what is com.cognitect.transit


transit-cljs also requires that


is there a good way in to track pending remote queries?


@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


network protocol


some state management (markers in state for the progress indicators)


These are the trade-offs that Untangled makes: make some reasonable decisions for the general case, so that these kinds of things can be provided as a turn-key solution


@tony.kay: that makes sense, thanks. seems like a very common thing to need in an app.


Yep. Om is a library of lego blocks. Untangled is trying to be a turn-key wrapper for it.