Confusing CTAs in the queryState editor

[prakhargupta1]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Current behavior 😯

Confusing CTAs in the queryState data binding dialog box.

Expected behavior 🤔

It should be Cancel and Update.

Steps to reproduce 🕹

Steps: Try editing a queryState

Context 🔦

No response

Your environment 🌎

No response

[Janpot]

Currently the CTAs are in line with the behavior. the input is immediate, i.e. the changes are immediately reflected in the application. Mentioning this because the solution entails more than merely updating the button texts, the behavior needs to be updated as well.

[oliviertassinari]

This makes me think of a generic UX problem: When should we use the autosave pattern (A) vs. manual save (B)? I guess:

• when it's code: B because it's how VS Code behaves by default?
• when it's the UI canvas: A because it's how Figma behaves by default in the canvas and with states/props?
• when it's a form full screen (e.g. in a modal): B because it's how forms usually behave?
• when it's a small form inside the canvas? 🤷‍♂️

[Janpot]

In the case of code: B because code is in a broken state half of the time while editing

[prakhargupta1]

Closing this issue. New query dialog box has: Cancel, Remove, Save which avoids confusion.

[bytasv]

when it's code: B because it's how VS Code behaves by default?

That's not true:

By default, VS Code requires an explicit action to save your changes to disk, Ctrl+S

@prakhargupta1 I think either this issue or new issue could serve to resume discussion about auto-save vs manual save - we still have places where we auto-save (component editor) and others where we have to manually save.

I think no matter which approach is used it should be consistent through the app. Having auto-save everywhere might not be always possible? 🤔 I think explicit save with a good UI indicator would work better and could be used everywhere without creating a confusion or unexpected behaviour

[Janpot]

I think no matter which approach is used it should be consistent through the app.

It is consistent. The application auto-saves every atomic change that doesn't result in a broken application. The goal is to protect the user's work as much as possible. Atomic changes that result in a broken application (e.g. code in an editor is invalid most of the time while typing) have to be committed manually. I believe we need to differentiate:

1. auto-saving the application state after a change (e.g. drag component in the view, update property value)
2. committing a set of staged changes as a single atomic update. (e.g. code updates to a binding, code component). auto-saving each keystroke here only results in storing tons of broken application states.

[bytasv]

Oh right, thanks for clarifying. I guess what gets me confused some times is that changing a name of query/connection gets saved automatically, while all other props require explicit "save" click - that part IMO would be worth unifying and putting under save, same as other fields behave in the dialog 🤔

[Janpot]

Yes, we should revise those name change flows.

• I'd like to turn them into similar components as how we rename the app in the overview page. The EditableText. Just output by default, but can be turned into editing mode, with a commit. e.g. similar to how PR title update works in GitHub
• I'd like to revise a bit how we avoid duplicating names. We should probably not make any naming choices for the user. And we should probably allow more duplicates (e.g. you should be able to have two pages with a component that is named the same)

[bytasv]

I'd like to revise a bit how we avoid duplicating names. We should probably not make any naming choices for the user. And we should probably allow more duplicates (e.g. you should be able to have two pages with a component that is named the same)

If I'm not mistaken I read that we are using names for data binding? Wondering if we could use Id's instead so we can allow even duplicate names to be used if users prefer

[Janpot]

Wondering if we could use Id's instead so we can allow even duplicate names to be used if users prefer

That would make the logic in bindings hard to follow. In Pro code we use descriptive variable names to increase readability, we should let users do the same in Toolpad.

[bytasv]

Ahhh, ok, now I understood... 🤦 yeah, it makes total sense to keep it that way, ignore my comment...

[prakhargupta1]

Based on the above discussion, I'll create a new issue for name change, auto-save, manual-save occurrences. cc @gerdadesign