trying to force a component to re-render/read (remotely) from a sibling component that mutates. i know a mutation should include read keys of affected components: > The second argument is a query expression that includes mutation. The query expression should contain any additional keys which should be re-read following the mutations (e.g. :todos/list). These reads will schedule components which depend on the specified keys to re-render. the problem is: nothing happens. i've tried all sorts of combinations of queries. does it need to be the rooted absolute query? relative query? single key of a query?

hey guys, little feedback welcome, at what point do you use db->tree to write your read function ?

Versus manually

another one =>

(dom/input
               #js {:type "text"})
(dom/button
               #js {:onClick (fn [e]
                               (om/transact! this `[(add/person {:id ~id})]))}
               "Add Person")

You should pass it through as a parameter in the transact call.

And if the content of your button can change, then it should be in your app's state, and your add/person mutation has access to all the state.

ohhhh ok

makes sense

@danielstockton how to do it ? the use case is : 1) I enter some text in my input 2) I click on the button to submit the content

from what I understand I have to get an onChange handler on my text input which modifies the app-state then once I click on my button, I pass the value to my mutation method

Actually, you don't need to pass it through if you know the key on state that you're reading to get the value. The add/person parser method will be passed the app-state. You just need the input to transact values onto the app-state onChange. There is another way, which is to have the input update component local state and then pass that through in the transact! Using app-state might be better, for time travelling purposes...

the update-state!has been made for local state right ?

You can use a link (https://github.com/omcljs/om/wiki/Thinking-With-Links!) in this component query to get the current input value. Yep, update-state! is for local state.

so why using componentDidUpdate to set local state instead of the ILocalState in the todoMVC of David Nolen

https://github.com/swannodette/om-next-demo/blob/master/todomvc/src/cljs/todomvc/item.cljs#L87

ILocalState is for initializing state, componentDidUpdate is a hook that is run after updating props (not called on iniital render).

Nothing specific to om, they're standard react lifecycle methods.

ok, thanks 🙂

is there any example of using ILocalState

?

Object
(initLocalState [this]
   {:count 1})

you don’t implement the protocol .

?

Nope, don't think there is one: https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L60

There is: https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L645 but it's a protocol on the component, defui takes care of this for you.

oh right

it’s all new for me...

@danielstockton all is working

I still have this but i’ll take care of it later

Constructor is changing an uncontrolled input of type text to be controlled. Input elements should not switch from uncontrolled to controlled (or vice versa). Decide between using a controlled or uncontrolled input element for the lifetime of the component

It's new to most people at the moment, that's why I keep looking things up in the source.

To fix that, you need to set a :value on the input.

Probably an empty "" at first and then it will read whatever you're setting on app-state or local-state.

ok thx

another question ^^ I have got my normalized data which looks like this =>

{:list/one [[:people/by-id 1] [:people/by-id 2] [:people/by-id 3]],
 :list/two [[:people/by-id 2] [:people/by-id 5] [:people/by-id 6]],
 :people/by-id {1 {:id 1, :name "John", :points 0},
                2 {:id 2, :name "Mary", :points 0, :age 27},
                3 {:id 3, :name "Bob", :points 0},
                5 {:id 5, :name "Gwen", :points 0},
                6 {:id 6, :name "Jeff", :points 0}},
 :om.next/tables #{:people/by-id}}

(defui PersonList
  static om/IQuery
  (query [this]
    '[{[:people/by-id _] [:name]}]))

(defui PersonList
  static om/IQuery
  (query [this]
    '[{[:people/by-id 1] [:name]}]))

can’t figure out how to do it

@baptiste-from-paris the likely reason the latter works and the former doesn't is you have a default read method which does something like (get-in state key)

nope

it makes sense, I don’t know how om is supposed to know that I want all the nested elements wihtout giving him a key 1 or 5

I juste wanted to know if it was possible

yeah you'd have to write a custom read function for that

I know how to do it with the read function but I hoped to do it with the db->tree helper

Has anyone ever run into an issue with om.next and figwheel where clojurescript will compile the first time through when including [om.next :as om] but if figwheel is restarted compiliation will fail with a null pointer exception and the only way to resolve the issue is to stop figwheel, delete the public/js folder and start figwheel again?

have you tried lein clean ?

@baptiste-from-paris _ isn't a wildcard, so that's not going to do what you're trying to do

When db->tree reads [:foo 1], it reads (get-in state [:foo 1])

When db->tree reads [:foo _], it reads (get state :foo)

right I find that but does it means that my query suxxx ?

I wouldn't use those words…but yes. 🙂

lol

is it possible anyway ?

There isn't a built-in way to get "every person that's in the app state", because that's normally not useful

Which people do you want?

Your query should express your complete intention

If you really want "all people in the system", you might define a key that means that, such as :all-people, or maybe :app/all-people

ok, that’s what I thought

but it’s a duplicate of my people/by-id

If your app is backed by a server, "all people" may include people your app state doesn't know about

and you want to make sure you ask the server about it

Note, though: you don't want to add a new key to your app state to do this

it’s for learning purpose 😉

Because, as you've just said, that would just be duplicate data

no back

(Right, but conceptually, that's why asking about all the things that happen to be in the local app state isn't a common thing to do)

You want to create a custom read for :app/all-people

ok, let’s try it

Something like:

(defmethod read :app/all-people
  [{:keys [state] :as env} key params]
  (let [st @state]
    (vals (get st :app/all-people))))

so in my case (without a backend) I still have to duplicate data by hand right ?

No, not at all!

Just put that in your parser

Then your query becomes [{[:app/all-people _] [:name]}]

Oh, actually, I've done that a bit wrong

That implementation will give you all the people, but it doesn't apply the subquery to each person

I think it'll actually work in this case, though

yep I’ve tried this one and it’s working with one little hint

when I update on person rendering only applied on my Person component and PersonList is not rendered

but it’s ok, thank’s for you help, this community is amazing 🙂!

Off the top of my head, it should be more like:

(defmethod read :app/all-people
  [{:keys [state query] :as env} key params]
  (let [st @state]
    (map
     #(om/db->tree query % st)
     (vals (get st :app/all-people)))))

Happy to help! 😄

Good luck!

Question of my own, speaking of things like :person/by-id…

Is there a particular philosophy behind Om using idents like [:person/by-id 1] and not [:person/id 1], which would match Datomic lookup refs?

The major reason that comes to mind is that the app state wouldn't match the spec for :person/id, because you'd have :person/id mapped to a map. But that doesn't feel like a terribly strong reason to me.

I ask because my team is working on something Om-y and Datomic-y with Postgres, and considering using the equivalent of :person/id for the analog of this, and I wonder what the room thinks

I really don’t know but I guess it’s more of a documentation thing; all docs have been made with person/by-*

but that’s just a guess

*a newbie point o view ^^

Yeah, I haven't questioned it until now

@peeja there have been questions like that for a while, my take on it is that it was just David's choice when doing the tutorials that people took on because everything was so new to them

I don't think it has any semantics to it, and has made some people confused

so feel free to use whatever naming scheme you want

Makes sense. Thanks!

has anyone run into an issue where importing om.next in the JVM and then building an om.next based project with cljsbuild.api with :advanced optimzations causes issues with static protocol implementations? Specifically, (om.next/iquery? SomeComponent) returns false. It looks like the closure compiler elides some of the internal protocol data on the SomeComponent class object

(not sure if I’m using the correct terms for cljs compiler internals)

@matthavener yes, Om Next 1.0.0-alpha47 requires you be on ClojureScript 1.9.293 at least

@anmonteiro yep, this is on alpha47 with 1.9.239

sorry do you mean 1.9.293? because there's also 1.9.229 and that's confusing

oh sorry, yes, 1.9.293 🙂

it doesn't make any sense to me what you're getting then

did you clean your build?

yeah, I’ll try to figure out a testcase

if you're still seeing issues after cleaning your build and rebuilding the project, can you put together a minimal repro I can look at?

anmonteiro: figured out a testcase https://github.com/matthavener/om-iquery-testcase

@matthavener works for me

check1  true
testcase.js:674 check2  true

hrm, must be something in my environment, it failed for @cmcfarlen as well

what java version are you using?

java version "1.8.0_112"

just looks like a caching issue

I don't know

well, we first saw the issue running builds inside docker.. which should be pretty clean 😕

I would say Cursive has some issues around caching too much, but I think @cmcfarlen uses Vim

right, and Docker should be pretty clean

your example didn't work right away for me, btw

I had to tweak user.clj

(removed the om.next require)

ah, that’s the line that breaks it 🙂

requiring om.next into the JVM before running cljsbuild/build is what triggers the issue

oh..!

I definitely get “true true” if I remove the om.next require

right but I was having a completely different symptom

so I know what the issue is then

we use clojure.main/demunge but never require clojure.main

🙂

over my head, is clojure.main not implicitly required by the lang itself?

I don't know

well, I updated the repo with clojure.main for other’s convenience

@matthavener I can definitely repro your issue now

clojure.main stuff apart

sweet! It literally took me 2 days to minify so I was happy to get it small enough 😛

this is going to be hard to fix

my suggestion is you change your build step?

if that's something you can do

yeah, we may have to

its not blocking us anymore, I just needed ast->expr which I grabbed from om.next.impl.parser instead

@matthavener the problem seems to be the dynamic require

or not even that, hrm

yeah, I’m not sure. I know if its AOT’d then it seems OK

that makes sense

so the problem is how we make statics work in advanced compilation with the Google Closure Compiler

@matthavener https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L280-L312

we need to replace those internal cljs.core functions before compiling anything Om Next

it's basically an ugly hack

and just like every ugly hack, it comes to bite you when you least expect 🙂

in this case, bite me, because I put it there

because its a dynamic require its not properly hooking into cljs.core early enough? or hooking in before it should?

something like that

but it shouldn't be a problem for most people

and you can work around it too

i blame @cmcfarlen 😛

We ran into it because we are running the cljs compiler from the same jvm as our server app

Its all my fault

so the way you fix it is you guarantee that cljs.build.api is required before om.next

which may not be possible

ooh

we can totally do that

hrm nope, even that doesn't fix it for me here

but you can always try

In our case, cljs.build.api is required before om.next

But we can require om.next after running the build step

yeah, that should be possible

meanwhile there were some situations where clojure.main wasn't loaded somehow

so https://github.com/omcljs/om/pull/848

@anmonteiro The initial symptom of this problem was our compassus Wrapper class was treated as not having IQuery, so the wrapped factory wasn't in computed, but in props. Its feels strange that the factory is obtained differently in the Wrapper depending on if you have a query or not. I understand why it is so, but it is a bit jarring.

@cmcfarlen feel free to open an issue

we can probably change that behavior

might be hard if the wrapper component transacts

then factory won't be there

hrm

just something to think about

I was thinking always have them in computed. I'll open an issue and we can discuss there

👍

or having them in both places if not iquery?

^ not a breaking change, and it'll be in computed anyway

yeah, that would work backward too