This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-25
Channels
- # 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)
@anmonteiro maybe you are looking for this: https://github.com/jakemcc/lein-test-refresh
This is my custom merge and send, "Login" is printed but the route doesn't change, nor any errors.
Anyone know why?
I seem to be able to (compassus/set-route! reconciler :some-junk-non-existent-route)
too, without error
I can get it to work with this, without any custom merge
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
or in the root component when i mount the app
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
could be worse
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
no, im using compassus as well and use tree->db with the root query
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
i havent really come across that yet
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
there is a second argument to the callback in send, which accepts a query...
so in send, im passing the query back to the send callback
this isnt well documented
ah ok, thats quite clever. But then again I'm missing the unsubscribe feature, if I would implement that in send
you can see it here https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L2454
hmm, thats true
so in my case I'm using componentDidMount
and 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 get-query
and pass this to (om.next/merge! reconciler novelty query)
my biggest complaint about om is that it gives me too much freedom that i don't know what to do with š
im also struggling to work out the best way to do various things
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
if the component only defines a query fragment for example
is your component a top level component rendered by compassus?
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.
@arohner the om.next
namespace doesn't require React
React
and ReactDOM
are required by the om.dom
namespace
if you don't want to require om.dom
in that namespace you can work around it by requiring cljsjs.react