Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2.0] Unify input component APIs #5596

Closed
stsrki opened this issue Jun 27, 2024 · 3 comments · Fixed by #5732
Closed

[2.0] Unify input component APIs #5596

stsrki opened this issue Jun 27, 2024 · 3 comments · Fixed by #5732
Assignees
Labels
Type: Feature ⚙ Request or idea for a new feature.
Milestone

Comments

@stsrki
Copy link
Collaborator

stsrki commented Jun 27, 2024

We have

  • TextEdit: with Text and TextChanged
  • NumericEdit, NumericPicker: with Value, and ValueChanged
  • DateEdit, DatePicker: with Date and DateChanged
  • TimeEdit, TimePicker: with Time and TimeChanged
  • Select: with SelectedValue and SelectedValueChanged
  • etc.

We need to unify all APIs and make them more standardized. My proposal is to have

  • Value, and ValueChanged for all input components.

It will be better for the users as they will not need to remember each API for each component. A lot of times, they try <Text @bind-Value="@value" />, and it surprises them when it doesn't work.

The change will greatly improve our codebase also as we will not need to have many abstraction layers that convert the internal value into the external value via those APIs. We will also be able to centralize most of the validation logic at the BaseInputComponent.


There are some edge-case components like Select that have several APIs, SelectedValue and SelectedValues for Multiple mode. I think naming them Value and Values is a good alternative.


The change is obviously a breaking-change. So, we need to document all and update all examples in the documentation. Not to mention that a migration guide is much needed.

@stsrki stsrki added the Type: Feature ⚙ Request or idea for a new feature. label Jun 27, 2024
@richardschoen
Copy link

Not sure if it makes sense but you could leave current value settings and mark as deprecated but also add the new consistent ones. Depending on your user base size it would allow them to more slowly migrate to the new settings rather than breaking things.

@stsrki
Copy link
Collaborator Author

stsrki commented Jun 27, 2024

Not sure if it makes sense but you could leave current value settings and mark as deprecated but also add the new consistent ones. Depending on your user base size it would allow them to more slowly migrate to the new settings rather than breaking things.

That might be the good way for the time being. We can just propagate Value to internals without breaking anything. And as you said, users will have time to adjust.

@mrpmorris
Copy link

Definitely mark the existing ones [Obsolete], then remove them in the next major release.

@stsrki stsrki added this to the 1.7 milestone Jul 25, 2024
@github-project-automation github-project-automation bot moved this to No Status in Development Jul 26, 2024
@stsrki stsrki moved this from No Status to Considered in Development Jul 26, 2024
@stsrki stsrki self-assigned this Jul 30, 2024
@stsrki stsrki moved this from Considered to Planned in Development Jul 30, 2024
@stsrki stsrki modified the milestones: 1.7, 2.0 Sep 18, 2024
@stsrki stsrki moved this from Planned to In Progress in Development Sep 18, 2024
@stsrki stsrki closed this as completed Nov 27, 2024
@github-project-automation github-project-automation bot moved this from In Progress to Done in Development Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature ⚙ Request or idea for a new feature.
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants