Fork me on GitHub
#om
<
2016-06-03
>
tomjack00:06:27

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/

tomjack00:06:05

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

ag00:06:40

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

tomjack00:06:08

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

tomjack00:06:24

that doesn't answer your question?

ag00:06:34

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

tomjack00:06:22

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

tomjack00:06:36

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

ag00:06:46

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

ag00:06:07

it’s not as straightforward as it looks

ag00:06:15

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

tomjack00:06:49

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

ag01:06:14

right, but do I have access to query params?

ag01:06:45

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

ag01:06:47

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

noonian01:06:08

[{: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.

noonian01:06:14

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)

noonian01:06:43

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.

ag02:06:17

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

noonian02:06:43

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

cjmurphy02:06:19

@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.

ag02:06:32

@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

ag02:06:55

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

ag02:06:01

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

cjmurphy02:06:12

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

ag02:06:20

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

cjmurphy02:06:51

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.

cjmurphy03:06:54

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.

cjmurphy03:06:02

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.

hlolli09:06:57

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.

anmonteiro09:06:04

@hlolli: yeah I'd never do that but if it works for you

anmonteiro09:06:34

IMHO React has its lifecycle methods for a reason, and you could take advantage of that

anmonteiro09:06:38

You might not realize this, but you have access to (om/props this) in the lifecycle methods as well

anmonteiro09:06:01

So instead of doing async stuff you can simply check that the prop you want is there

anmonteiro09:06:12

Then component is pure again!

hlolli09:06:08

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

anmonteiro09:06:18

@hlolli: as I said yesterday it'll probably not be there in componentDidMount but it should be there after the remote call in componentDidUpdate

hlolli09:06:44

there exists componentDidUpdate, I read about it many times, but totally forgot about that lifecycle part.

mitchelkuijpers09:06:55

{:value {:keys [:ui.entities/selected]}
 :action (fn []
           …)}

mitchelkuijpers09:06:34

what does :value :keys do exactly i could not figure this out from the docs it only says it has no effect on rendering

hlolli09:06:48

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.

anmonteiro09:06:23

:value :keys doesn't do absolutely nothing

anmonteiro09:06:17

It's just there as documentation so that you remember which keys you should put after the transact! call

mitchelkuijpers09:06:11

Aha ok.. seems weird to not to just use them then.. Is there a particular reason for this?

mitchelkuijpers09:06:21

Thanks for clearing it up though @anmonteiro

anmonteiro09:06:38

No reason, they existed as :value only before tempids were implemented so as to have a common shape between the result of mutations & reads

anmonteiro10:06:04

@mitchelkuijpers: feel free to add this to the FAQ if it's not there, it comes up a lot

anmonteiro10:06:12

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

anmonteiro13:06:31

transit-cljs also requires that

isak16:06:12

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

tony.kay20:06:15

@isak: Om has you write the plumbing and logic for all of that...part of the reason Untangled exists.

tony.kay20:06:30

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

tony.kay20:06:52

network protocol

tony.kay20:06:14

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

tony.kay20:06:50

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

isak20:06:40

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

tony.kay20:06:27

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