Not sure if this is a bug, but I have stripped out everything from my main.js file other than the onDidChange() method and am just simply logging the new value to the console.
I have changed the key that gets passed to onDidChange() and the callback still get invoked 7 times.
See the screen capture here.
I created a brand new extension and made a single config item with an onDidChange() on it. The console outputs multiple times as in my original case, however I had two windows open at the time and one outputed 7 times and the other 5. Don’t know what to make of that, but seems it’s not something in my project.
Oh hey, I actually ran into this same bug (or a very similar one, at least) not too long ago while trying to integrate a PR into my Stylelint extension:
Weirdly enough in my case, the first couple times I would trigger the listener with a config change, it worked as expected (i.e. it logged the old/new values to the console one time)… but then after that it would start running the callback multiple times whenever I invoked it.
Soon enough, every successive config change would result in the callback getting called exponentially more times on each change event, but this seemed to be localized each individual listener instance. Meaning, even if I toggled the same config a bunch of times to the point where it logs dozens of lines every time, for a different config I’d have to similarly change it many times to get it’s listener into the same state.
The GitHub comment linked above has a screenshot that shows this. Took me a good couple hours of frustrated debugging before I decided to throw in the towel lol.
I’ll have to test this out again in the version 11 beta soon.
I’m seeing something similar when registering a Command, and manually invoke()'ing it from my code. The registered function is called 7 times for each invoke() call.
Nova 11.4 build 540540
This should probably be moved to the “Bug Reports” category, but I’m not sure how to do / ask for this?
Sorry for the late reply, but I’ve not seen any fixes either.
I had thought about working around this issue (in a different project) by throttling the callback via setTimeout, but I thought masking the issue that way may or may not just end up allowing runaway resource usage to slow down the editor depending on what the root cause of the bug is. So I just avoided using this method altogether.
Another workaround I thought about—but haven’t actually tried to implement—was to directly watch for file changes on relevant config files directly (e.g. .nova/Configuration.json in the current workspace), either via the nova.fs.watch API or some external process.
For my use cases, I’d rather just wait for a bug fix and make do with manually restarting/reloading extension configs though…
I’ve also been noticing (potentially) similar/related behavior in other event-handler-like APIs here and there, though I’ve not tried to verify this.