Fork me on GitHub

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)]
             ( d 
                (fn[e] (om/set-state this {:activated? true})))))
for every instance of the component it will fire that event and set the state for all of them.


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


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


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

Joe R. Smith19:09:12

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?


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


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


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