breadboard
breadboard copied to clipboard
Editing the configuration of a node doesn't persist
I added an invoke node, I set the path to my board JSON. Click off the node, then click back and the data is gone.
This seems to now create a new issue where we eagerly try and load the path. @dglazkov, what do you make of it?
Oooh - actually I was hoping for that to happen. I wanted to see the what the board outputs are so I can connect them easily...
It might be worth us putting some try-catch stuff around it, because it somewhat spams the console as it tries (and fails) to load the board as you type its path out. I'm not sure what the right answer is there, though; we will want to communicate that the URL is (or isn't) valid, but I think it's still good that we eagerly update the configuration as someone types in values.
Reopening because I think there's something for us to figure out with respect to paths & configurations being "live updated".
Here's what I am thinking:
- The node editor needs to know if it should live-edit a property within a node or whether it's something like a URL that is definitely not valid until fully typed in.
- The current way we have of informing the editor of such interesting behaviors is the
behaviorhint. - So maybe we have the logic in the node editor that, if a special hint is present, it will not live-edit the field and instead have a UI affordance for the user to say "yep, this is now ready to update". WDYT?
I guess we'd need the board behavior hint for this instance so that we know it's not just a string, but something more. That said I'm very mindful of the UX impact of having things that sometimes live update and sometimes don't. If live-updating is too greedy (which it seems to be) then maybe we need to switch it to a "you have pending changes - apply now?" scenario?
Playing with the board picker, I just realized something. Maybe this is solved with UI? If we want to have atomic input (no live-editing), then we pop up a window and you have select something from it or hit "OK" or whatever to make the change. While inside of the window, the changes are not live. They are only committed when the window closes.
This might also help with #1381 as we could make the editing UI more prominent. I'm mindful of us having too many overlays... but maybe it would work?