Yeah, this is why Dave pushed back (and why I said I think it's time for a rethink on node buttons) as there is a strong use case for having both input+button and output+button.
Fwiw, my image-tools viewer node has this arrangement because cloning images when viewing/debugging is super expensive. So you wouldn't be the first.
Just because I strenuously object to it doesn't mean you can't do it... but yes as this is debugging then something like the debugger would not be inappropriate.
I agree - unfortunately, there is a need. Short of redesigning nodes appearance (e.g. inset buttons) or adding a feature (like hover to reveal or right click context menu options) to nodes, we have little choice.
TBH, I really dislike that we have to deploy after toggling a button (especially the debug node). Dont get me wrong, i understand why it is the way it is but there are ways we could solve this. For example, a local store (of overrides) that can be updated without deploy would make the situation a lot smoother (storage on systems permitting) but I'm not trying to solve that here and now.
err - no you don't "have top" deploy - it is flagging that the state of the flow has changed so there are changes - but you don't have to deploy. You can always hit ctrl-z if you want.
do you mean (maybe) that the state of each debug node (and other nodes with toggles) is held purely in the client browser - so always off in the flow by default... (otherwise all would be on for every "new" client)... Interesting idea...
You're right (as usual ;)) I'll me be more explicit. Once you toggle the debug, the workspace is marked dirty. Only a refresh or deploy clears this state. At this point my OCD kicks in and I need to deploy. Sometimes I don't want to deploy. Sometimes I may have actually made modifications that I really do want to deploy. The point is it's just a bit of a pain and suboptimal UX (IMVHO)
That is one option yes. But in this thought experiment I was thinking of a server local state store.
While on the topic of debug button (and probably other nodes with buttons) behavior, not sure if anyone noticed the following bug:
if you deselect the button, debug node stops logging without a deploy (as intended)
if you then reload the page, you get a warning about unsaved changes but you decide to ignore them
upon page reload button is represented with active ON state as it was before changes were made (as intended), but actual state of the debug node is inactive - logs are off, although button represents active state
As of writing (v3.x, v4.x): If you click to disable debug, server side stops sending messages (to all open clients). If you look at the the 2nd browser, the debug is enabled - but no messages are arriving. If I deploy the first, the 2nd does not know or reflect this change and you would be unaware there was a change until you deploy on the 2nd - at which time you are warned about needing to merge. In effect, by having the state in a server side store, anyone refreshing (or deploying) would not get a merge conflict and would (ideally) just get back the updated state. In an ideal world, the state change would actually be transmitted to open editors (meaning they could reflect the users choice - all without ever having to deal with the dreaded "merge"). In fact, a deploy is already communicated to all open editors today (you get a 5sec toast about changes been made) however you have to catch that, review it/merge it, refresh the page (potentially losing local changes) or face the merge issue when you deploy.
Example: I disabled the debug on the LHS and deployed. 10secs later, i look at the RHS and see the debug is enabled but there are no messages coming in! I decide to change something innocuous and I am faced with the merge toast.
Now play that out as server side state (instead of flow modification) and instead of displaying a toast about flows changed, the editor simply updates the state of the debug button on connected clients!
EDIT For the record: This is a thought experiment - what I am suggesting may ultimately not be feasible
Maybe I misunderstood what was being said. It looked as though the idea was to store the current on/off state in browser storage which would certainly result in different instances of the Editor having different behaviours.
I am certainly in favour of things that would make multi-editor use more consistent.
