Clojurians Log v2

I don't think there is a problem with coupling it to a namespace, thats kinda what i assume i just need to do here if i want to keep track of where things came from.

by coupling, i mean, you could you either (and this also seems like a irrelevant difference) pass namespace keywords down (fn [{:keys [nsA/n nsB/x] (swap! x + n)) Or make the the state global to the namespace and pass it in the require: (fn [] (swap! nsA/x + nsB/n))

so now we can jump to where this state was defined, but it's also coupled by that ability.

so again, a trade off.

I have no idea what the problem you're describing is exactly, to be honest. If the initial choice is irrelevant, why mention it at all? > you can't tell where the arguments came from Which is the case with every single function out there, it's not related to #reagent at all. You can tell where something came from during debugging - by checking the callstack. > You can solve this by coupling the function to it's starting location First of all, why is this in need of solving? What's the actual problem? Second of all, how would tying a function to a location tell you about the provenance of the arguments? Where did 17 come from, if the function is foo.bar/f?

Well, i said "i feel like irrelevant" not that it is, im talking about it to get a sense of weather to lean one direction or another, or maybe another route. > Which is the case with every single function out there, it's not related to #reagent at all. Agreed. > You can tell where something came from during debugging - by checking the callstack. Only if it throws right? But i take your meaning. > First of all, why is this in need of solving? What's the actual problem? The problem i ran into, for example, being unable to quickly jump to where the (fn [x] ... in (fn [n] (fn [x] (swap! x + n)) is being called to see if the right arguments are being passed. The same issue exists if your looking at a component down the call tree that receives a lot of arguments. > Second of all, how would tying a function to a location tell you about the provenance of the arguments? Where did 17 come from, if the function is foo.bar/f? I don't think i was suggesting we tieng the function to it's arguments, but rather i was thinking about what it would be like to tie the arguments to a location. For the first time im having to work on an app that isn't using re-frame or anything like it, it's just pure reagent, ans so as the apps complexity grows, more state is having to centralized higher up the tree so it can coordinate and trickle down the branches. What i describing is the two ways i can see to do that: You can either pass state (the ratoms) or function that manipulate that state. What, if anything, is the real difference here? Looking past that, the frustrating part for me, is usually when im looking at some local context, where the arguments have been wrangled, and realize i'm not passing in the right ones. How do i quickly jump to all the spots it's being used? I suspect in about 10 minutes i'll figure my real headache is that broke something into pieces the wrong way, and it has nothing at all to do with what i'm rambling about here.. to your point, this, and i agree, probably has nothing to do with reagent.

> Only if it throws right? But i take your meaning. No, by using breakpoints (with breaking or with just logging) or specialized tools like FlowStorm that trace everything. > The problem i ran into, for example, being unable to quickly jump to where the (fn [x] ... in (fn [n] (fn [x] (swap! x + n)) is being called to see if the right arguments are being passed. That's exactly what a debugger is for. Just put a breakpoint inside that closure - either via DevTools or with a (js-debugger) in there.

> You can either pass state (the ratoms) or function that manipulate that state. What, if anything, is the real difference here? Nothing in principle. In practice, ratoms usually stay the same but functions change when the outer function is called again. So, extra redraws. > How do i quickly jump to all the spots it's being used? By debugging with proper tools. It won't necessarily be quick, but it's likely to be much quicker than studying the whole set of potential call sites that can be dynamic and only known at run time.

trying js-debugger....

Yeah, good point, i'm basically lamenting that i made things dependent on the run time, so ill either need to inspect that, or undo it lol.