This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-29
Channels
- # arachne (3)
- # bangalore-clj (6)
- # beginners (246)
- # boot (57)
- # business (1)
- # capetown (1)
- # cider (2)
- # clara (1)
- # cljsjs (36)
- # cljsrn (1)
- # clojure (150)
- # clojure-austin (4)
- # clojure-brasil (7)
- # clojure-china (2)
- # clojure-france (3)
- # clojure-greece (3)
- # clojure-japan (3)
- # clojure-russia (38)
- # clojure-spec (25)
- # clojure-uk (25)
- # clojurescript (320)
- # clojurex (1)
- # cursive (38)
- # datascript (48)
- # datomic (23)
- # emacs (29)
- # events (1)
- # funcool (2)
- # hoplon (64)
- # jobs (3)
- # luminus (10)
- # off-topic (26)
- # om (27)
- # om-next (1)
- # onyx (1)
- # parinfer (38)
- # perun (5)
- # planck (19)
- # re-frame (38)
- # reagent (19)
- # remote-jobs (1)
- # rum (2)
- # schema (2)
- # spacemacs (1)
- # specter (8)
- # test-check (10)
- # vim (7)
- # yada (14)
@anmonteiro should i be able to call compassus/set-route!
on the reconciler in merge?
It prints redirecting to... but nothing happens
This is for redirecting after logging in, and also redirecting unauthorized reads to /login
If an update happens to my app-state causing the root component to re-render, does this trigger re-reads of the whole query or just parts of it that were updated? I'm having trouble working out why I get two identical remote reads happening in quick succession.
It happens each time I change route
question: I couldn't figure out how to use db->tree
without finding an example usage on the net and was wondering if a change like this would be acceptable:
I renamed ref
to app-state
, and created another arity for more basic usages e.g. (om/db->tree [:people] app-state)
@haywood I think calling that app-state
is a bit too concrete. It's not necessarily the state of an app, it's just a map you can look up idents in.
It's good to point out in the docstring that that's usually the root of the app state, but I wouldn't rename the argument
ok yea that makes sense, would still prefer if it was something a bit more descriptive, I couldn't figure out what a ref map
could be. map-with-idents
Hey guys, quick question. When having a hierarchy of components, I find myself using this pattern over and over:
(render [this]
(let [props (om/props this)]
[:div
(ui-foo-component props)
((bar-component-fn "bar") props)
;; bar-component-fn returns a factory
]))
So, if I have to pass props all the time, maybe there's a way to reduce this boilerplate? Maybe some kind of macro. e.g. (ui-> bar-component "bar")
(macro that takes a factory instance, or a fn that returns one, some arbitrary params and calls it passing (om/props this)
?
hmmm, I guess I do most of the time. And then filter out whatever is needed down the chain
looked at the code, and looks like just async, unless there is no reconciler, which looks like can happen if you dont use add-root!
@haywood Not sure if that's possible- The way I usually handle this situation is to just make the :current-user
reader just access the global state directly, so I can just write [:name :email {:current-user [:email]}]
@haywood My own rule of thumb is "Keep the queries simple, put the complexity in the parser reader methods"
@haywood (The downside of this rule of thumb is that eventually you have stuff in the parser functions that prevents tree->db
from working and then you have to write your own merge/migrate functions for server syncs)
since [:top-level-key _]
is allowed I wonder how hard it would be to add that bit of extra functionality