guys, if I need to change a local state of a component when there’s a click anywhere in the document, how do I prevent this from happening for all instances of the component? e.g: if I do something like this:

(componentDidMount [this]
           (let [d (gdom/getDocument)]
             (goog.events/listen d 
              goog.events.EventType.CLICK 
                (fn[e] (om/set-state this {:activated? true})))))

@ag If there are multiple instances of the component, how do you know which one you want to respond to the click?

so there’s a context of the component, right?

@ag Went AFK for a bit. Not sure I follow: what context are you referring to?

@peeja the context of the component. So you see, this snippet would addEventListener on document object, every instance of the component will be triggering this event, but I want the state change to be happening for only specific instance of the component. There has to be a way to tell "if the context is such and such” then set-state, otherwise do nothing

Right, that's what I'm asking: how do you know which component is supposed to get the event?

What makes the right answer different from the wrong ones?

https://stackoverflow.com/questions/39457036/global-events-and-state

there has to be a canonical way of dealing with this problem in React. I guess it wouldn’t be very different in Om.Next

@ag https://stackoverflow.com/questions/39457036/global-events-and-components-local-state/39457214#39457214

so what you’re saying we never, ever should have components that add global listeners, or any listeners outside of their scope?

@ag I wouldn't

I added a comment that may work here, but it still feels pretty wrong to me

Is there a way to have a join, such as {:blah/selected (get-query BlahView)} actually read :blah/by-id (with an id param) on the serverside, and then rewrite the response top level key from :blah/by-id to :blah/selected ? I currently modify the ast used as the value to the :remote key in the return value from my client-side read handler, e.g., {:remote (assoc ast :key :blah/by-id …)}, but I can’t figure out how to get om next to place the result under :blah/selected. (All of this is being done using :query-root true to rewrite the response under some UI-specific key-paths. I thought similar rewrite support might exist to decomplect the client-side join attribute names from the dispatch keys on the severside).

@anmonteiro It looks to me like a Compassus wrapper has no way to query for data itself. Is that correct?

@peeja that’s right https://github.com/compassus/compassus/issues/3

also not a very straightforward thing to solve 🙂

If you’ve skimmed through the Compassus code, suggestions accepted!

yeah, I'm thinking about ideas

do you have a particular use case for that need?

I will. I'll be hitting essentially the same issue: the signed-in user

right

you don’t want to declare a link or w/e in every top-level component

But I'm noticing it because I'm essentially recreating Compassus to implement sub-pages on one of my pages, and ran into the same issue 🙂

I agree we should support that

I wonder if there's a piece of Compassus that could be mounted recursively to deal with routing like this

Basically, a route component that's sometimes a root component with its own routes

@gardnervickers deployed [omify “0.1.1”] to Clojars with those 2 fixes

Oh nice! That was fast

Thank you

you should see a bunch of warnings but they’re safe to ignore

let me know if anything doesn’t look right

warning such as:

When calling super() in `omify$tests$OMFY_1_Component_2`, make sure to pass up the same props that your component's constructor was passed.

Hey, I'm new to Om and am trying to run the examples from the repo. When I try 'lein cljsbuild once hello", i get this error