Fork me on GitHub

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


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


if using compassus counts as funky...


in essence it switches part of the root query as routes are changed


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


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 ( reconciler) and then use get-query


and pass this to (! 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


how are query params different from just using regular state in queries?


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


@arohner the 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


aha! thanks