Blazorise: [Proposal] Rename input components

[stsrki]

This is just a proposal and I would like to get some help from anyone who can give me feedback.

Currently (almost) all input components have suffix Edit. Edit was introduced long ago when Blazor was lacking support on naming components that are similar to regular html tags. eg. <Form> - <form>

I think now is the time to revisit some of the naming conventions and prepare Blazorise for final v1.0. Bellow is the list of potential names for existing component. Again, any feedback is welcome.

| Current Name | New Name | Or | Or | Reason |
|--------------|------------|--------------|----------|----------------------------------------------|
| TextEdit | TextBox | TextInput | Input | |
| NumericEdit | NumericBox | NumericInput | | |
| DateEdit | DateBox | DateInput | | |
| CheckEdit | CheckBox | Check | | |
| CheckEdit | RadioBox | Radio | | This one is going to be split from CheckEdit |
| FileEdit | Upload | FileInput | | |
| MemoEdit | MemoBox | MemoInput | Textarea | |

PS. We can do the communication in this thread or on Blazorise Gitter

[richbryant]

I favour the "box" suffix. It's nice and clear.

[MarkStega]

My suggestion:

TextEdit -> TextField
NumericEdit -> NumericField
DateEdit -> DateField
CheckEdit -> CheckField
CheckEdit -> RadioField
FileEdit -> FileUpload
MemoEdit -> MemoField

[MarkStega]

In second place I also like Rich's consistency with "box"

[tleylan]

I'm leaning towards "Input" rather than Box because they are variations of the HTML input. An input is a particular type and it can be enabled or disabled, etc. An enabled "box" seems odd?

The term Input is extensible. If you were to create specific ones for password or email they can be PasswordInput and EmailInput. While they could be PasswordBox and EmailBox that again sounds odd.

"RadioBox" is odd in that they are typically called radio buttons. RadioInput is closer but it could be RadioButtonInput and CheckBoxInput. And finally FileUploadInput.

[stsrki]

I can already see this is going to be fun. Generally I agree with @tleylan. Box can sounds strange, especially for Radio and File components. If we're going to have suffix on all of the components then Input sounds better then Field.

But having CheckInput or RadioInput is also strange for me.

[WillianGruber]

In my opinion Field is nice. That's how users see: "Oh I should fill that field in the page".
Input that is disabled is not an input, so its strange...
Box is only fine with a larger-than-common field, like the Memo. Anyways I dont like the "memo" name.
So, I would rename it this way:

TextEdit -> TextField
NumericEdit -> NumericField
DateEdit -> DateField
CheckEdit -> CheckField
CheckEdit -> RadioField
FileEdit -> FileUpload
MemoEdit -> TextBox

But Im ok with MemoField for consistency

[richbryant]

I dislike Input precisely because it's HTML and not specific to Blazorise.

[WillianGruber]

Also, Check and Radio are more like buttons than fields (in a way that you dont fill them, you just click them), so an alternative is:

TextEdit -> TextField
NumericEdit -> NumericField
DateEdit -> DateField
CheckEdit -> CheckButton
CheckEdit -> RadioButton
FileEdit -> FileUpload
MemoEdit -> TextBox

[stsrki]

I also forgot to mention there are going to be some new components in v0.9 that are named:

• Switch
• Slider

[stsrki]

I dislike Input precisely because it's HTML and not specific to Blazorise.

Cannot argue with this!

[stsrki]

@WillianGruber Not sure about CheckButton and RadioButton.

[WillianGruber]

Check, Radio, FileUpload, Switch and Slider are not components you "fill", so maybe just call them this way:

TextEdit -> TextField
NumericEdit -> NumericField
DateEdit -> DateField
CheckEdit -> Check
CheckEdit -> Radio
FileEdit -> FileUpload
MemoEdit -> TextBox
Nothing -> Switch
Nothing -> Slider

[WillianGruber]

Components that could be misunderstood in the code could have the Field sufix. That is for text, numeric and date, they are inside data. Checks and Radios for example are an exclusive UI concept, so no need for Field sufix

[MarkStega]

Minor mod to WG suggestion to use more familiar terms:

TextEdit -> TextField
NumericEdit -> NumericField
DateEdit -> DateField
CheckEdit -> CheckBox
CheckEdit -> RadioButton
FileEdit -> FileUpload
MemoEdit -> TextBox
Nothing -> Switch
Nothing -> Slider

[WillianGruber]

@WillianGruber Not sure about CheckButton and RadioButton.

That is my SAP ABAP background speaking, sorry. That's the way it is named there.

[WillianGruber]

Minor mod to WG suggestion to use more familiar terms:

TextEdit -> TextField
NumericEdit -> NumericField
DateEdit -> DateField
CheckEdit -> CheckBox
CheckEdit -> RadioButton
FileEdit -> FileUpload
MemoEdit -> TextBox
Nothing -> Switch
Nothing -> Slider

You are right, it is CheckBox

[stsrki]

Well, Edit comes from my background with DevExpress. We all have some history it seems :)

[richbryant]

The preference for *box probably comes from XAML, which this resembles in many ways. I haven't mentioned this before but I think maintaining that connection to XAML is a good thing, especially ICommand is now supported. What it means is, millions of desktop devs now feel instantly comfortable with web programming. Can't be bad.

As well as a public service, it will also help with uptake.

[tleylan]

It should be CheckBox and RadioButton as has been pointed out. I liked "Field" as well far more than "Box". And Switch and Slider are fine like that. Field is equally extensible so PasswordField (for instance) would clearly imply an input for passwords. TextBox sounds like something you might drop a TextField into.

[tleylan]

One shouldn't endeavor to make XAML people happy at the risk of annoying all the other users.

[WillianGruber]

It should be CheckBox and RadioButton as has been pointed out. I liked "Field" as well far more than "Box". And Switch and Slider are fine like that. Field is equally extensible so PasswordField (for instance) would clearly imply an input for passwords. TextBox sounds like something you might drop a TextField into.

True...

[stsrki]

I like having an idea of components without any suffix or prefix. Most of the time this is not possible for Text, Numeric, or Date. So for those components where you need to enter something I agree to have them like TextField, NumericField etc.

On the other hand, Check and Radio can be named without any suffix. Maybe it's not _standard_ but it still _feels_ good.

[WillianGruber]

I like having an idea of components without any suffix or prefix. Most of the time this is not possible for Text, Numeric, or Date. So for those components where you need to enter something I agree to have them like TextField, NumericField etc.

On the other hand, Check and Radio can be named without any suffix. Maybe it's not _standard_ but it still _feels_ good.

I agree.

So for me:
TextEdit -> TextField
NumericEdit -> NumericField
DateEdit -> DateField
CheckEdit -> Check
CheckEdit -> Radio
FileEdit -> FileUpload
MemoEdit -> Please something without Memo word, that resenbles a large TextField. Maybe LargeTextField? MultilineTextField? ExpandableTextField?
Nothing -> Switch
Nothing -> Slider

[tleylan]

They become textarea elements don't they? So TextAreaField?

[WillianGruber]

They become textarea elements don't they? So TextAreaField?

Fine for me.

TextEdit -> TextField
NumericEdit -> NumericField
DateEdit -> DateField
CheckEdit -> Check
CheckEdit -> Radio
FileEdit -> FileUpload
MemoEdit -> TextAreaField
Nothing -> Switch
Nothing -> Slider

[stsrki]

So, to summarize so for we have this:

| Current Name | New Name |
|--------------|--------------|
| TextEdit | TextField |
| MemoEdit | TextArea or TextAreaField? |
| NumericEdit | NumericField |
| DateEdit | DateField |
| CheckEdit | Check |
| CheckEdit | Radio |
| FileEdit | FileUpload |
| SelectEdit | Select |
| - | Switch |
| - | Slider |

[WillianGruber]

TextArea +1

Select could be Dropdown?
But it can go not only down, so maybe Select is better.
My point is that select remembers too much of sql. But it is also what a user would call it

[stsrki]

@WillianGruber There is already a Dropdown component but it's not an _input_. It's more of a menu.

[WillianGruber]

I see. Select is nice.

[tleylan]

Are you going to address the classes within and "without" the ones listed? Select isn't bad but it contains option elements. That suggests it is an OptionGroup with Option elements. The Radio for instance exists in a RadioGroup. If it is Select then SelectItem seems appropriate. The mix of names always struck me as a little odd.

[stsrki]

@tleylan Select is already renamed for v0.9 and as you also mentioned it has SelectItem elements. That will stay the same as before.

eg

<Select>
    <SelectItem>One</SelectItem>
    <SelectItem>Two</SelectItem>
</Select>

Regarding the Radio, I plan to also add RadioGroup.

eg.

<RadioGroup Name="mygroup">
    <Radio>One</Radio>
    <Radio>Two</Radio>
</RadioGroup>

[tleylan]

I'll accept it however it arrives but we see yet another difference for no apparent reason. Why isn't it a SelectGroup? Or why aren't they RadioItem?

Like English It will never be perfect I suggest that you shoot for as much consistency as you can reasonably manage people will adapt.

[mrpmorris]

Input is the better choice. You should be naming then based on what they do (input) rather than how they look (like a box).

For example, a text box is merely a box with text in it, it doesn't imply it can be edited. A text input speaks for itself.

[stsrki]

@tleylan Select and SelectItem are consistent with other components that also have parent>child relationship. I removed *Edit from Select as there is no editing, just select.

On the other hand, Radio is basically a Check(box) with the name attribute that will group multiple Radios into one category.

I can leave as it is now and that will make perfect sense:

<Radio Name="Numbers">One</Radio>
<Radio Name="Numbers">Two</Radio>
<Radio Name="Numbers">Three</Radio>

But by introducing additional group I think it will look cleaner: (Name on RadioGroup can be optional with this approach)

<RadioGroup>
    <Radio>One</Radio>
    <Radio>Two</Radio>
    <Radio>Three</Radio>
</RadioGroup>

[WillianGruber]

Input is the better choice. You should be naming then based on what they do (input) rather than how they look (like a box).

For example, a text box is merely a box with text in it, it doesn't imply it can be edited. A text input speaks for itself.

@mrpmorris I disagree. A disabled field is like an output-only field. An output-only input field, i.e. something named for accepting inputs, that is not accepting them is weird. Field is more generic, it can be input field or output field. Naming it input binds to a behavior that isnt always true

[stsrki]

@mrpmorris @WillianGruber Going with Input will also be confusing as a lot of people will replace it with Blazor native components: InputText vs TextInput. The same is for other versions of input(s). That's why Field can be better way.

[mrpmorris]

Then go for TextEdit. It still describes what it does, but uses an alternative word to avoid confusion.

[mrpmorris]

@WillianGruber that's just a different state, it is still a control that allows input. An HTML input control doesn't stop being an input control when it's in a readonly state.

[WillianGruber]

I still think it is best to name it what it is, not what it does. It is a field, that may or may not allow input.

[mrpmorris]

It's an input that may or may not be enabled :)

[WillianGruber]

I read that as "an input that may be an input or an output" :)
I think everyone has its own point of view in this matter.

[mrpmorris]

Is a disabled button not a button because it cannot be pressed? :)

[stsrki]

i think this has gone a little too far. I agree with @mrpmorris. Disabled doesn't mean the control is stopped being control. It has just gone into diferent state, in this case it cannot act on user actions, for some period of time.

[David-Moreira]

In my opinion, Input to be on par with html / blazor naming conventions. If you find that ends up being too similar to blazor's inputs, I guess the most similar would be Field.
Personally I don't like box at all. :P Maybe control...
Maybe you could setup a poll?

[jbennink]

Late to the game. I like the Field suffix, but find the Check and Radio odd. It's a Checkbox so CheckboxField and RadiobuttonField are more in line with the Field suffix.
In Winforms a TextBox has a Multiline property to distinguish between the html input type="text" and textarea perhaps Blazorise could also adopt something like that?

| Current Name | New Name
| - | - |
| TextEdit | TextField
| MemoEdit | TextField (with Multiline=true)
|NumericEdit | NumericField
|DateEdit | DateField
|CheckEdit | CheckboxField
|CheckEdit | RadiobuttonField
|FileEdit | FileUpload
|SelectEdit | DropdownField
| - | Switch
| - | Slider

Not sure about FileUpload it feels more like a FileUploadControl as do the Switch and Slider they are less fields and more controls.

[stsrki]

@jbennink I also tend to go with Field suffix for the input elements. It feels most _natural_.

The exception is Check, Radio, Switch, and Slider since they are not _fields_ like other inputs, as in, you don't enter values into them. So for them, the suffix is not needed. I know it's not common, but some convention need to change sometimes :)