It is considered a good practice to namespace data values. For example right at the top level app is commonly used. So for example app/selected-button. What to call app? Is it a 'selector', or a 'category', or..?

I'm reading https://github.com/omcljs/om/wiki/Quick-Start-(om.next)#a-mutation-function, is there a difference between "thunk", and "function with no arguments"?

I take them as the same

thunk - no arguments, return value might be important. Used for lazy evaluation of a computation.

Is this channel used in place of the #C0N43QHHT one?

Yes - for all om - Sean C got rid of #C0N43QHHT channel I thought.

Has anybody been able to apply remote queries to http://anmonteiro.com/2016/02/routing-in-om-next-a-catalog-of-approaches/.

what do you mean, tawus? is there particular difficulty you're having?

e.g. if we are using set-query and the child component is using remote, we have to make changes to the read method for key :route/data.

hi guys how do we get the current state in componentWillUpdate. I remember that someone has asked it before but I cannot find it ..

@nxqd: om.next/get-rendered-state I think

@tawus thanks I will try this out. this one looks quite new to me

regarding the problem of channel and tap I asked you yesterday, add ^:once doesn't help. I think it's something else. I will try to find it out later today.

@tawus: can you switch on the route?

I am now able to switch using recursive-remote (from om-next tutorial). Still have to figure out a few things.

hi guys in om next, to avoid sending nil query to server what should we do ?

normally in a component we have nil query, we will set the values later ( via query params or whatever ), how do we avoid om to send the nil query when the component first mounted

Running into an “Assert failed: Query violation” with this code. Any insight into why this causes a violation?

(defui X
  static om/IQuery
  (query [this]
    [{:x [:a]}]))

(defui Y
  static om/IQuery
  (query [this]
    [:id]))

(defui Z
  static om/IQuery
  (query [this]
    (conj (om/get-query X) {:z (om/get-query Y)})))

(om/get-query Z)

However, this works by just replacing (om/get-query X) in component Z’s query:

(defui Z
  static om/IQuery
  (query [this]
    (conj [{:x [:a]}] {:z (om/get-query Y)})))

@bnoguchi: try replacing the conj in Z's query with a map or something similar

I got the same error when returning child queries instead of composing them

@marianoguerra: Thanks. Looks like I can’t clobber X’s query’s metadata

Switched it to:

(defui Z
  static om/IQuery
  (query [this]
    (conj (into [] (om/get-query X)) {:z (om/get-query Y)})))

@bnoguchi: from looking at it: you're stealing the query of component X in component Z

You can't just take queries from the children

they need to compose

example:

(defui X
  static om/IQuery
  (query [this]
	 [:a]))

(defui Y
  static om/IQuery
  (query [this]
	 [:id]))

(defui Z
  static om/IQuery
  (query [this]
	 [{:x (om/get-query X)} {:z (om/get-query Y)} ]))

"this component just needs what the child needs" is the red flag for 'stealing queries'

@iwankaramazow: What happens if you “steal” a query from a child component, as follows?

(defui Z
  static om/IQuery
  (query [this]
    (conj (into [] (om/get-query X)) {:z (om/get-query Y)})))

@bnoguchi: one of the things is that if you do (om/transact! this <query>) it will give an error

I think the reason is that since the queries don't compose from the "leafts" to the "root" om can't follow the queries to locate the component or something like that

and I'm sure it may cause other problems

@marianoguerra: Thanks

indeed 😄

@nxqd: can you initialize your query params with some initial values? Would that prevent the nil query issue on mounting?

@nxqd: you're not supposed to have nil queries. If you're using the latest master this should give you an invariant violation. If it doesn't please send me a minimal repro, thanks

@anmonteiro: thanks for the input, I do have "nil" query like this {:location nil} not actually nil. @grzm I have the same thought, would work on this later today

@nxqd: if that nil is a param there's probably no problem. if it's going to be a join things might not work as you expect

I'm trying out anmonteiro's om next devcards (which have been merged into devcards, from what I can tell) http://anmonteiro.com/2016/02/om-next-meets-devcards-the-full-reloadable-experience/

I'm not seeing what I expect as "reloadable". When I make a trivial change to the file and save, all of the counters are reset to 1. I'd expect them to preserve their state. Or am I understanding this wrong?

@grzm: they haven't been merged, what's in devcards is not reloadable

you need to use https://github.com/anmonteiro/devcards-om-next

@anmonteiro: I thought this was merged: https://github.com/bhauman/devcards/pull/91#issuecomment-173391945

that PR had initially what's now in the repo I linked

but then it ended up being just a patch for making it possible to extend devcards externally

ah.

@anmonteiro: so, I should see the state persist for the cases I pass a reconciler to either om-next-root or defcard-om-next. State should not persist if I don't pass a reconciler. Is that correct?

(that's the behavior I'm seeing)

exactly

I started toying with defonceing the reconciler inside of the macro

but I didn't have more time to pursue that

and I'm not even sure if it should be opinionated like that

whenever you don't defonce your reconciler and pass it to the macro it will not be reloadable anyways

thanks for confirming. And it's easy enough to pass a reconciler.

right

Messed up my brackets in a ref with :ui/signup [[:user/by-name] "ar"] and got a vector as the return value of om/db->tree. Not sure if this is considered a bug?

@rauh: was the db->tree result :ui/signup [[:user/by-name] "ar"] ?

@anmonteiro: Nope, it was [{<query-result>}, {<query-result>}]

and what should it have been?

I thought it would always return a map, no?

it can return a vector

I see, then ignore what I said. Sorry for the noise. Still all new to me

@grzm: confirmed this works :hugging_face:

(defn custom-merge-tree [a b] (if (map? a) (merge-with into a b) b))

(defonce reconciler
  (om/reconciler
   {:state app-state
    :parser (om/parser {:read p/read :mutate p/mutate})
    :send (utils/transit-post "/api")
    :merge-tree custom-merge-tree
    }))

basically you don't overwrite existing key/values with this merge

might come in handy when building a stairway to cache heaven

Hey guys, I have another question. I have a list of items, one of which is selected. This is defined in my original set of data as follows:

(def init-data
  { :list/users {:selected-user [{:ID 1 :selected true}]
                 :users [{:ID 0 :userName "Jimmy"}
                         {:ID 1 :userName "Robby"}
                         {:ID 2 :userName "Bobby"}]}})

I guess another point to ask, is that even the right approach to take?

@dnolen: eliding data-paths is a parser option, but e.g. default-ui->props relies heavily on the component's path to pass the appropriate props to the component that's re-rendering

@anmonteiro: data path elision is a hack

I'm looking to understand the rationale behind this option: is this supposed to be server thing?

if you use it you better be ready for everything to break

I can live with that

perfect

I'm still working on the query stuff

and I'm also relying on component paths

we should be able to remove it when data path annotation happens by using the query

so I was wondering if it's OK for stuff to break if path ellision was turned on

I might leave it in there just for the weird cases where it’s desirable for some weird perf reason

yes breakage can be expected if you use it

cool

btw, after 3 failed implementation attempts, I think I'm going somewhere

kudos to you for the indexer stuff, this thing is powerful 😉

I might have something to show soon. should I open a PR for it? link you the commit in my branch?

@jamesmintram: You have to write your own mutate method that is in your parser and call it with om/transact!.

@cjmurphy: So the current mutate method looks like this:

(defmethod mutate 'users/select
  [{:keys [state] :as props} _ {:keys [ID]}]
  {:value {:keys [:list/users :selected-user]}
   :action (fn []
     (swap! state assoc-in
            [:list/users]
            {:selected-user {:ID ID :selected true}}))})

You might need the last one to be :selected false as well.

@jamesmintram: since your data is normalized at that point you need to put an ident under the :selected-user key

the :selected true might not even be necessary

@anmonteiro: So I tried that as well (using the mutate below) - and it correctly updates the :selected-user value in the state, but that doesn’t propagate to the associated user in :list/users

(defmethod mutate 'users/select
  [{:keys [state] :as props} _ {:keys [ID]}]
  {:value {:keys [:list/users :selected-user]}
   :action (fn []
     (swap! state assoc-in
            [:list/users]
            {:selected-user [:user/by-id ID]}))})

@jamesmintram: because that's just a reference

Needed is something that checks that mutates have not taken your state away from normalized, and pops up a message in the browser to say where the problem is. I've written a library does that - will release it tomrrow or very soon. But for now manually look at it and see if Idents are everywhere they should be, which is everywhere.

you then need to update the actual user data structure with whatever new fields you want

@anmonteiro: Hah! Ok, that would probably explain it - I will go away and re-read the docs. @cjmurphy thanks for the advice - I will check it out!

@jamesmintram: what I mean is go ahead and update the entry under :user/by-id ID

which is where your "entities" live in a normalized state

Ah Ok - so in my case, the :selected-user reference is actually redundant - and I am better off using assoc/dissoc on the normalized data.

Where the entities live is the 'tables' part of default db format.

@jamesmintram: disagree

what is redundant IMO is the :selected key under the user.

since it'll cause you pain once you want to select another user... You'll have to deselect the currently selected

2 operations instead of one

That is what I originally thought, but then I ended up down this path. So an ideal solution would involve each User component checking itself against the :selected-user ID - and if it matches do something special (in this case, apply a CSS class)

Without any other info that's probably what I'd do

OK thanks!