Fork me on GitHub

I remember reading in the re-frame readme about the difference between calling a component as (component) vs [component]—but I'm having a hard time locating it again in the readme (or even in the wiki)—is a description of that distinction still around somewhere?


@fasiha: probably in the re-frame wiki


I wrote a ~1000 line SVG-heavy app using (component). Going back and fixing that. Pretty easy, except those cases where the component function returned an seq via map (just have to wrap the map in [:span …] or div)


heya guys, what’s an idiomatic re-frame way to initialize a piece of app-state when a handler is fired? say, for example, I have two tabs running across the top of the app. when a handler receives [:tab-context-changed :tab2] … do I build up initial state for tab2 in that handler and assoc into the db? Is that initial state already in the DB as part of an init process? do I have a tab2 registered-subscription that watches the first, and provides a default value as part of the reaction?


@lwhorton: i don't know about idiomatic, but i often create an 'empty' value for a piece of state alongside its schema - then pick (all or part of) that empty value to initialise or reset in the app-db


do you do the resetting/initializing as part of a higher-level handler, or a handler on the “same level” as the tab2?


it varies - i reset the entire app-db from such a value in the init handler, and then create new 'empty' bits of state, or reset existing state, as required by app flow


@lwhorton: you can either initialise it at startup (we have a :bootstrap event we call for stuff that has to happen before we start), or you could do it when you switch tabs, it’s kind of up to you and what makes sense


for now I settled on subscriber-blending as a way for siblings to talk to each-other


basically, subscribe to sibling, when changes, dump initial state into db (if not there already)


i like that approach because in my mind it’s not that different from queue-d communication, which is about as decoupled as it gets


just encountered a quite hard-to-find bug involving a tree of reactions joining two collections from the app-db - if one of the collections started out empty then it seemed that the dependency of the joined collection on the other collection was never recognised - see L20 of this sub -


i don't know enough yet about how reaction dependencies are gathered to know whether this is expected behaviour or not...


When you are using two reactions (A and B) in a third reaction (C), beaware that there is no guarentee about ordering. A might "run" triggering "C" even though "B" is yet to run.


In the FRP world, running the C computation before the B is run is known as a "glitch". it means that when C runs it might be seeing an updated A, but an old B. Some FRP systems topologically sort all the nodes in the Signal graph, but, reagent doesn't do that. This world is a little too dynamic.