This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # beginners (22)
- # boot (223)
- # cider (161)
- # cljs-dev (19)
- # cljsrn (4)
- # clojure (186)
- # clojure-austin (6)
- # clojure-beijing (1)
- # clojure-boston (3)
- # clojure-china (1)
- # clojure-czech (1)
- # clojure-france (1)
- # clojure-greece (10)
- # clojure-russia (17)
- # clojure-uk (154)
- # clojurebridge (3)
- # clojurescript (82)
- # component (12)
- # cursive (12)
- # datomic (71)
- # dirac (3)
- # editors (2)
- # emacs (29)
- # flambo (31)
- # hoplon (21)
- # immutant (11)
- # instaparse (17)
- # jobs (2)
- # jobs-discuss (2)
- # jobs-rus (1)
- # lein-figwheel (12)
- # leiningen (2)
- # off-topic (44)
- # om (78)
- # onyx (38)
- # parinfer (1)
- # re-frame (34)
- # reagent (32)
- # spacemacs (56)
- # untangled (74)
- # vim (12)
- # yada (2)
Assume I'm using
[my-svg-component] and re-frame is under the hood making React classes for it and its children. If I change the attributes of
my-svg-component, say the viewBox in
<svg viewBox="…">, but don't change any of its children, will re-frame/React still have to re-render all those children, because their parent changed?
Probably a quite common question: What is best practice on doing multiple db updates in the same handler? Say I want to update both
:nav->:children in the same handler. Can I do this atomically somehow? Like a transaction? Or do I just stack my
(update-in db …) after each other?
@vikeri: not sure I understand the problem. Wouldn't
(-> db (update-in ...) (update-in ...)) already do what you want?
True… A little rusty on the functional side after battling in JS land for a while now.
since you're most likely using the
pure middleware (i.e. no
swap! in handlers) "transactionality" is nothing you need to worry about
Does GraphQL or similar query language have a place within Re-Frame? The way I understand it is the React components in Re-Frame are already declarative of the data in
app-db so subscribing to a remote resource from the component level would not conform to the framework's principles. Is there any examples of updating
app-db directly from a GraphQL data source? Appreciate any insight on this
One thing I'm constantly missing from re-frame is an easy way to see where my event comes from. Sometimes events are dispatched that shouldn't but it's hard to figure out where they are dispatched.
Unfortunately I don't think it can be done as middleware since the processing/dispatching is so separate
Just tried to make following:
defn is changed to custom macro
defnc where component name is set into some global var with
dispatch is wrapped with method which prints contents of this global variable and passes arguments to initial dispatch. This way you can get log message each time you call
dispatch with current component (or event component tree) name. Unfortunately i couldn't make these bindings work. Probably due to async nature of callbacks.
@martinklepsch: I'm assuming you want this for debug purposes. If so, I'm wondering if you could write your own function called, say,
emit and use it in place of
emit would look something like this:
(defn emit [event-vec] (when ^boolean js/goog.DEBUG console.trace((str v)) (re-frame/dispatch event-vec))
The 2nd line of the consoled stack would be the point where the emit happened. The first line would be the emit function itself.
@nidu: there are known limitations to using bindings in async contexts (i.e. they don't work)
@mikethompson: yes that would work. I actually stumbled upon console.trace() after asking here. Might still be a helpful addition to re-frame maybe?
I have been thinking about that issue for a while and made that issue yesterday
@mikethompson: what's the point of emit as a macro? couldn't we attach the trace as metadata to the event or otherwise expand the data passed into the queue?
I was thinking that macros gets line number and file etc. So the "trace" information is more direct
Newbies don't need to know to look at the 2nd line of the trace, and ignore the first.
Regarding "attaching the trace" as metadata, that is possible, i think, with some skullduggery.
But ... is there an advantage to having trace on the event itself, or is simply seeing the dispatch site in the console sufficient.
My problem is looking at an error stack trace to figure out where the dispatch was called
@danielcompton: you might want to star/watch this feature request in devtools: https://bugs.chromium.org/p/chromium/issues/detail?id=332624
also there is a way how to grab stack trace from error object, something like new Error().stack or something like that
> For a variety of reasons some frameworks and libraries implement their own taskQueues.