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?

Do you mean name of originating ui component?

@nidu: this or ideally a real trace, yes

Sounds like a magic to me. I guess there may be some trick with bindings

@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

I think there can be way to do it without console.trace

Automate this somehow

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?

@martinklepsch: https://github.com/Day8/re-frame/issues/164

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...