This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (5)
- # beginners (225)
- # boot (36)
- # cider (1)
- # clara (2)
- # cljsjs (1)
- # clojure (76)
- # clojure-belgium (1)
- # clojure-conj (1)
- # clojure-india (4)
- # clojure-italy (5)
- # clojure-korea (1)
- # clojure-russia (22)
- # clojure-spec (35)
- # clojure-uk (52)
- # clojurescript (67)
- # community-development (17)
- # core-logic (2)
- # cursive (2)
- # datascript (28)
- # datomic (44)
- # emacs (1)
- # funcool (3)
- # hoplon (14)
- # lein-figwheel (2)
- # leiningen (2)
- # luminus (3)
- # midje (3)
- # mount (2)
- # nyc (2)
- # om (54)
- # om-next (1)
- # onyx (30)
- # re-frame (57)
- # reagent (19)
- # ring-swagger (23)
- # slack-help (10)
- # spacemacs (2)
- # specter (1)
- # vim (23)
This is my custom merge and send, "Login" is printed but the route doesn't change, nor any errors.
I seem to be able to
(compassus/set-route! reconciler :some-junk-non-existent-route) too, without error
After trying out om for a while now, my biggest complaint is that it doesn't seem to work well with push-based, event-driven backends eg like firebase. I have to subscribe in the component's didMount method and merge! novelty after normalizing explicitly against the component's the query, so it is all very much coupled to the component and I feel like not benefitting much from Om. Are there better ways of doing a smthg like this?
I think it would be great if remotes had some way of streaming values. I know I can use the callback to send multiple times, but there is no unsubscribe mechanism
@tobiash Do you have to benefit from om for push-based things? It seems like thats always going to be tied to the component and at least om doesn't make this more difficult that it might otherwise be?
You can always subscribe somewhere else than the components didMount, if it isn't coupled with the component (if more components need the data)
Where would you subscribe? Somewhere in the reconciler? Though as I said, it's unclear to me when to unsubscribe then
i'd probably find the common ancestor in the tree of components to all the components that potentially need the data and subscribe there
the only thing you're coupling is the place you subscribe, at least you still benefit from om queries and a unidirectional flow of data
I think routing is part of the problem - something that needs conceptual sorting out. Because when I merge novelty, I have to use tree->db against a specific component (versus the root), because I don't know if its mounted and part of the global query at that moment.
Aren't you always calling tree->db using the root query? All your components queries should compose down to the root query, unless you're doing something quite funky
i understand there are times when you want to modify the ast to mark a deeper components query as a root query, thats what i meant
ok.. how does that work then? which component do you give to tree->db? maybe I'm doing it wrong, but I couldnt get it to normalize my data
and from reading compassus' code it kinda makes sense because the subquery might not be there when I'm calling tree->db
actually, i removed my custom merge code because the default-merge is doing it for me
ah ok, thats quite clever. But then again I'm missing the unsubscribe feature, if I would implement that in
you can see it here https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L2454
so in my case I'm using
componentWillUnmount to subscribe and unsubscribe, and
merge!. That obviously does not allow multiple components to share the subscription
if you're calling
merge! presumably you're getitng the reconciler with
get-reconciler inside that component?
if you have the reconciler, you can find the root component
(om.next/app-root reconciler) and then use
my biggest complaint about om is that it gives me too much freedom that i don't know what to do with 😛
yes, but since I have to do the subscribe/unsubscribe in the component in question, I can also just use the query of the component. But your solution makes since if there are other components that might influence the normalization of the novelty.
i haven't dug into untangled much yet, perhaps this is what i need, an opinionated framework on top
doesn't it depend on the component query? i know i have component queries that definitely won't work with tree->db
I think in general you should do tree->db against root, yes. In my case, it works with route component though. but that's not the issue 🙂
yes, in your case your component query is the root query (compassus just switches the root query)
you could subscribe in the parser potentially, which solves part of the coupling problem you see, but its hard to see how you would tear down...
I think it would be possible to subscribe given a certain query, and then check if the query ast still contains that query at later times. However, I am not sure there is a reliable hook for getting notified of query changes? Maybe compassus route changes, but there is also query params which ideally should also be able to trigger a re-subscribtion with the new parameters
also, if I want a param to be based on the value of a piece of state, I have to set-query! at runtime, during e.g. componentWillMount, right?
I’m suddenly getting "React is not defined” in one .js file of an otherwise working om next project. Only in one namespace, which is just a simple
(defui). the NS requires om.next.
if you don't want to require
om.dom in that namespace you can work around it by requiring