I have a gap in my understanding of the Query part of a component. I see in examples that Ident is used to figure out what part of the query is used to match changes against the component to re-render, but the component is defined to have a Query that is located somewhere in the db already (it is wrapped as a subquery that targets the component). Is there any way to also query and depend on a 'out of scope' value in the tree, like :current-selected as well, or is it expected that selection markup is dealt with in the parent and passed in as computed values (or something else).

@snoonan: That sounds like what links are for: https://github.com/omcljs/om/wiki/Thinking-With-Links!

Thanks, I remember skimming thru this early, but obviously forgot.

@sineer: you might want to look at om.next/subquery

Has anyone had problems with Om Next and ClojureScript 1.9.293? I tried updating an app that I'm writing and my root component query wasn't executed, instead the reconciler's state (in my case: a DataScript db) was passed to it as props. Odd. I might try again later with a minimal app to see if I ran reproduce it outside my more complex setup.

@jannis yes, you need to be on alpha47

I think I tried that combination. I'll quickly re-run again.

Om relies on some compiler internals to make static methods work in advanced builds

some of that logic changed in ClojureScript 1.9.293

advanced as in advanced optimizations? This is a non-optimized build.

yes, as in advanced. but it doesn't matter, it affects every build

@jannis https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L259-L310

these are the relevant code bits

You're right, I just built again with 1.9.293 and alpha47 and it works. Doh, my bad. Thanks 🙂

glad it works

Me too 🙂

@anmonteiro I filed an issue, but I’d like to confirm a hunch I have. Currently, advanced compilation breaks when dom/clipPath is present. Does this have anything to do with the unsupported tags issue?

@levitanong my first thought would be to include externs for SVG

@anmonteiro what functions and vars would be in the externs? Isn’t clipPath already inside om?

https://github.com/Hunga1/svg-externs

@levitanong right but you need to prevent the Closure Compiler from munging the clipPath prop

e.g.: when we inline stuff, the generated JavaScript will look like: React.DOM.clipPath or something

so the Closure Compiler needs to know that it can't munge clipPath to something random thing

@levitanong try adding the externs above to your build and let me know if it fixed it

@anmonteiro thanks, will do!

can compassus be made to work with datascript ?

@danielcompton Haven't thought about that use case, but I'm happy to make the necessary changes to support it

ups I meant @danielstockton ^

ok, i havent looked into it enough yet, was just wondering if there were any design choices that completely ruled it out

not that I'm aware!

i'll dig a bit deeper then, thanks

@danielstockton oh actually...

I think we actually assume that the app state is an atom 🙂

im asking because i know there are still problems with set-query! and datascript, don't know how it works internally though

right, set-query! is still a problem in Om

but Compassus doesn't use set-query!

ah right, in that case perhaps it can be made to work somehow?

it can

we just need to stop assuming that the app state will be an atom

@danielstockton can you open an issue so that I don't forget to look into that?

ok sure

thanks!

https://github.com/compassus/compassus/issues/18

👍

@anmonteiro Hmm… I’m not sure if I’m using the externs wrong, or if it’s really not working. I gotta run, so I’ll have to put this off. Will study more about it tomorrow or later tonight.

@anmonteiro Do you have ideas on how login could be implemented using compassus? maybe it would be useful to have place to hook auth before route changes?

@tobiash I think that's a userland concern

I give you the set-route! primitive

you can choose to call it or not, depending whether the user is authenticated

or is there something else I'm forgetting?

no, thats fine. I was just asking because many routing libraries include something like that

but i am already wrapping compassus to sync it up with the RN navigator anyway

@tobiash routing in Compassus is about swapping the top-level component that is shown in your app, nothing else

of course we provide hooks for you to implement, e.g. URL navigation

which in your example doesn't make sense because you're building a RN app.

so right there is an advantage of not including it by default 🙂

yes, i like very much how unopinionated it is atm

btw, thank you for the 1.0.0, it's working great so far and it's much easier to write parser and send functions now

awesome, appreciate the feedback. I find it more intuitive as well