This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-21
Channels
- # 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?
@fasiha: hard to say with such limited information. The pages under "Reagent Tutorials" at the bottom of this page might help: https://github.com/Day8/re-frame/wiki
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->:index
and :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.
Am I missing something? Are there any plans to improve this?
@nidu: this or ideally a real trace, yes
@nidu: console.trace()
does all the required magic as far as I can tell
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 binding
. 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 dispatch
everywhere. 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
@danielcompton: ah! I even remember reading that
@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.
That sounds familiar...