[Proposal] Rename input components #596
Comments
|
I favour the "box" suffix. It's nice and clear. |
|
My suggestion: TextEdit -> TextField |
|
In second place I also like Rich's consistency with "box" |
|
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. |
|
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. |
|
In my opinion Field is nice. That's how users see: "Oh I should fill that field in the page". TextEdit -> TextField But Im ok with MemoField for consistency |
|
I dislike Input precisely because it's HTML and not specific to Blazorise. |
|
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 |
|
I also forgot to mention there are going to be some new components in v0.9 that are named:
|
Cannot argue with this! |
|
@WillianGruber Not sure about CheckButton and RadioButton. |
|
Check, Radio, FileUpload, Switch and Slider are not components you "fill", so maybe just call them this way: TextEdit -> TextField |
|
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 |
|
Minor mod to WG suggestion to use more familiar terms: TextEdit -> TextField |
That is my SAP ABAP background speaking, sorry. That's the way it is named there. |
You are right, it is CheckBox |
|
Well, Edit comes from my background with DevExpress. We all have some history it seems :) |
|
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. |
|
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. |
|
One shouldn't endeavor to make XAML people happy at the risk of annoying all the other users. |
True... |
|
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: |
|
They become textarea elements don't they? So TextAreaField? |
Fine for me. TextEdit -> TextField |
|
So, to summarize so for we have this:
|
|
TextArea +1 Select could be Dropdown? |
|
@WillianGruber There is already a Dropdown component but it's not an input. It's more of a menu. |
|
I see. Select is nice. |
|
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. |
|
@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> |
|
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. |
|
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. |
|
@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> |
@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 |
|
@mrpmorris @WillianGruber Going with Input will also be confusing as a lot of people will replace it with Blazor native components: |
|
Then go for TextEdit. It still describes what it does, but uses an alternative word to avoid confusion. |
|
@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. |
|
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. |
|
It's an input that may or may not be enabled :) |
|
I read that as "an input that may be an input or an output" :) |
|
Is a disabled button not a button because it cannot be pressed? :) |
|
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. |
|
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. |
|
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.
Not sure about FileUpload it feels more like a |
|
@jbennink I also tend to go with 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 :) |
|
On a similar note, wouldn't it also be a good idea to add a prefix to all controls? When I added Blazorise to my project I had a few naming conflicts (for example Something like |
|
Personally I also take the approach of using a prefix on my own components. That also means you could have already taken that approach yourself... :P But yes, personally I do also agree with adding a prefix if we go for breaking changes. That pratically makes sure there arent conflicts and helps with intelisense for who does not like to use namespacing. |
|
I'm not a fan of prefixes as it adds noise to the code. And as others are already said, that is why namespaces are there. |
|
Probably something to look for dotnet/razor#7670 |
|
I dunno for you guys but most of WPF programmers are using Blazor because of convenient C# code in front-end. So many of us would like to see XAML convention here :) TextEdit - TextBox |
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.
PS. We can do the communication in this thread or on Blazorise Gitter
The text was updated successfully, but these errors were encountered: