This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-02
Channels
- # boot (227)
- # carry (1)
- # cljs-dev (3)
- # cljsjs (2)
- # cljsrn (19)
- # clojars (2)
- # clojure (93)
- # clojure-belgium (1)
- # clojure-dev (2)
- # clojure-italy (1)
- # clojure-spec (22)
- # clojure-uk (5)
- # core-async (15)
- # cursive (33)
- # emacs (8)
- # ethereum (1)
- # hoplon (3)
- # jobs (2)
- # leiningen (1)
- # off-topic (24)
- # om (32)
- # perun (1)
- # protorepl (1)
- # re-frame (13)
- # reagent (53)
- # rethinkdb (4)
- # ring-swagger (1)
- # vim (12)
- # yada (14)
@dzannotti: have you looked into om/computed
and om/get-computed
?
@levitanong thanks 🙂
@levitanong doesn't seem to be exactly what i was looking for sadly, i was looking for computed values in query rather than apply them to props
Anyone has experience with compassus + bidi + goog.History for implementing routing in om.next? I have a route with :id param, but struggling to pass it to my component to constrain the query.
Now that om.next
is written in .cljc
we can run fullstack - client and server - tests in a single jvm. Powerfull stuff!
In testing this out, I ran in to 1 problem where I'm accessing om.next.cache
in my client code, so I had to port it to .cljc
. Patch here: https://github.com/petterik/om/commit/8d63f7e6690252a72e42767fff431f1967c692a3
It'll be very interesting to see how far this sort of testing can go and how many bugs it can find.
@dzannotti: it seems what you're currently doing is correct then. :)
@levitanong you can use om.next/react-type
@anmonteiro Indeed, I feel silly now, after having made that PR 😛
lol right
Will add to documentation
@levitanong https://github.com/ladderlife/cellophane#getting-a-component-instances-class--type
make sure to mention that limitation for the server-side part, please
Oh wait, it’s already documented
will add the limitation instead
@anmonteiro that bit seems to fit more as an entry in the FAQ, which could reference the react-type
entry in the documentation. What do you think?
@levitanong nothing against that
@dzannotti nothing I’m aware
for log/google purposes - the closest thing i found to an om.next parser in python after some digging is https://github.com/dvcrn/om-react-native-demo/blob/master/server/api/views.py
please double check in case i got anything wrong 😛 https://github.com/omcljs/om/wiki/Om-Next-FAQ#how-do-i-get-the-class-of-a-component-instance
@anmonteiro Any chances https://github.com/compassus/compassus/commit/9a92c185d71615284b40a71eb049bbf38d01ec96 will hit a release any time soon?
@alex-glv I still have a few things to get to for the next Compassus release, but I’m happy to make a pre-release tomorrow if you want
I’ll ping you tomorrow when it’s done
@alex-glv actually got around to doing it now. bump your deps to [compassus “0.3.0-SNAPSHOT"]
@dzannotti I'm running into this case too. We already have domain helper functions for calculating these values; my approach is going to be to annotate those functions with queries, so a component which uses those functions can query for the raw data they'll need. We'll see if it's viable. (I think querying for calculated values using keys that aren't in the app state, as you're describing, is also a reasonable approach.)