3 ms·

Does everyone think that wrapping almost each and every html element into a react component is a good thing? Why do I need a <Button /> element if I already hav

Does everyone think that wrapping almost each and every html element into a react component is a good thing? Why do I need a <Button /> element if I already have a <button></button> element? You're not really saving bytes here as much as creating confusion and new stuff to learn. Take, for example, the <FormField label="Input name" htmlFor="input-name" /> component. It takes two props which have totally different meaning. htmlFor is react's substitute for the native html "for" attribute, but the label is being created as an html element. So I have to learn this new mixed up syntax. Why? Existing html syntax is nice already and what everyone's used to. On the other side, such elements as <Spinner /> are nice to have. We don't have any native html spinner elements, so it's a good unifying wrapper for arbitrary spinner html+css magic, which can be easily changed once someone on the project wishes to change how the spinners look.

the_gipsy 11y ago
You will most likely attach an event listener to the button. You could just use `element.addEventListener`, but that's not consistent if you use React for other form elements. Next, you might want to dynamically change the button's text, color, visibility etc. At that point, if you are using pure DOM API, the code will start to look like spaghetti, unless what you're doing is a really simple one-off form page.
- everdimension 11y ago
  I'm not sure I understand your answer. The event listener is added via react's 'onClick' attribute which is consistent across all elements. Things like button's text, color, visibility is nicely controlled via adding/removing classes. And this <Button /> element can create enough spaghetti of its own, too, with attributes like "size", "type", etc, if overused. And with some attributes it can be hard to distinguish native html attributes from component-specific attributes.
  - chillacy 11y ago
    > Things like button's text, color, visibility is nicely controlled via adding/removing classes Isn't the whole point of using React that I don't have to manually manage state like this? When text, color, visibility are all changed independently in different places for more than a handful of states, suddenly it isn't so nicely controlled.
Cshelton 11y ago
So one example that we use is for many input fields to have formatting done based on the client and their 'settings'/locale. It's basically just a wrapper around the html 5 input with the different types. So decimal places, right aligned, currency symbol, certain client validation that may be different per customer, etc. At the same time we name those components different than something like < Button /> so that it is very clear it's not just a UI wrapper, it has functionality.
dominotw 11y ago
You can use polymer/webcomponents with react if you don't care about server side rendering.
wvenable 11y ago
> So I have to learn this new mixed up syntax. Why? Existing html syntax is nice already and what everyone's used to. I assume you'd learn it because it fits with the majority of your use case; having labels immediately attached to fields. So not only are you enforcing a particular style but your saving keystrokes and mental energy on two tags when you only need one.
- everdimension 11y ago
  That's exactly the problem: "it fits with the majority of use cases". What happens when I want to create a form-group element where label comes after the input? Do I need another component like <FormGroupReversed /> or do I need to add an attribute "reversed" to the initial component? I guess I have to go look in the documentation. So here I am, searching documentation to find a way to simply change the order of html elements. And that's just an example. Not to mention that in a week I won't remember what exactly the "reversed" attribute means. The thing with html, you're gonna start fighting it sooner or later. And when this moment comes, i would prefer to find solutions to the wide-known html problems, not to the problems specific to this library, which may kind of create them in the first place. One of the advantages of React compared to Angular is that you don't have to learn specific angular syntax — you are encouraged to use native javascript as much as you can. Same goes for html — i'd like to use native html as much as I can. It has enough problems of its own, but at least I know those problems, and which I don't, i'm pretty much sure i can google solution for. But these component-wrappers are not solving html problems, they are creating shortcuts which are definitely shorter, but rarely intuitive and introduce new syntax and may introduce new problems.
lobster_johnson 11y ago
Not defending this particular library, but there are some good reasons to use React abstractions even for simple things like a button. Some examples: * If the form deals with state and validation, then <Button> (as opposed to <button>) can automatically disable itself if the form's input isn't valid. * It can incorporate useful features like preventing redundant clicks (to prevent duplicate submits) and showing submit progress (eg., replace button label with a spinner while it's pending). * You can more easily add features that you would have to manually wire with an HTML <button>: For example, let it take a "tooltip" prop that will automatically show a tooltip on hover. As an aside, I should add that I wouldn't code up a "form with submit and cancel" like this. I would have the form component itself render the submit and cancel buttons, and call it something like SubmittableForm. This way, it can be in control of the UI (eg., validation, button placement, etc.) and submit logic. As for that htmlFor thing, I don't know why this library does it that way. There's no reason it couldn't correctly wire up a "for" attribute itself on the HTML label element.
- afshin 11y ago
  Just a guess, but it might be that because "for" is a JS restricted word, they picked an attribute name that wouldn't maybe trip up a syntax highlighter or something of that nature.
  - lobster_johnson 11y ago
    That's not what I was referring to. There shouldn't be any reason for the FormField component to need to know the name of what the label is referring to, since it has access to its children through the "children" prop.

the_gipsy 11y ago

You will most likely attach an event listener to the button. You could just use `element.addEventListener`, but that's not consistent if you use React for other form elements. Next, you might want to dynamically change the button's text, color, visibility etc. At that point, if you are using pure DOM API, the code will start to look like spaghetti, unless what you're doing is a really simple one-off form page.

everdimension 11y ago
I'm not sure I understand your answer. The event listener is added via react's 'onClick' attribute which is consistent across all elements. Things like button's text, color, visibility is nicely controlled via adding/removing classes. And this <Button /> element can create enough spaghetti of its own, too, with attributes like "size", "type", etc, if overused. And with some attributes it can be hard to distinguish native html attributes from component-specific attributes.
- chillacy 11y ago
  > Things like button's text, color, visibility is nicely controlled via adding/removing classes Isn't the whole point of using React that I don't have to manually manage state like this? When text, color, visibility are all changed independently in different places for more than a handful of states, suddenly it isn't so nicely controlled.

Cshelton 11y ago

So one example that we use is for many input fields to have formatting done based on the client and their 'settings'/locale. It's basically just a wrapper around the html 5 input with the different types. So decimal places, right aligned, currency symbol, certain client validation that may be different per customer, etc. At the same time we name those components different than something like < Button /> so that it is very clear it's not just a UI wrapper, it has functionality.

dominotw 11y ago

You can use polymer/webcomponents with react if you don't care about server side rendering.

wvenable 11y ago

> So I have to learn this new mixed up syntax. Why? Existing html syntax is nice already and what everyone's used to. I assume you'd learn it because it fits with the majority of your use case; having labels immediately attached to fields. So not only are you enforcing a particular style but your saving keystrokes and mental energy on two tags when you only need one.

everdimension 11y ago
That's exactly the problem: "it fits with the majority of use cases". What happens when I want to create a form-group element where label comes after the input? Do I need another component like <FormGroupReversed /> or do I need to add an attribute "reversed" to the initial component? I guess I have to go look in the documentation. So here I am, searching documentation to find a way to simply change the order of html elements. And that's just an example. Not to mention that in a week I won't remember what exactly the "reversed" attribute means. The thing with html, you're gonna start fighting it sooner or later. And when this moment comes, i would prefer to find solutions to the wide-known html problems, not to the problems specific to this library, which may kind of create them in the first place. One of the advantages of React compared to Angular is that you don't have to learn specific angular syntax — you are encouraged to use native javascript as much as you can. Same goes for html — i'd like to use native html as much as I can. It has enough problems of its own, but at least I know those problems, and which I don't, i'm pretty much sure i can google solution for. But these component-wrappers are not solving html problems, they are creating shortcuts which are definitely shorter, but rarely intuitive and introduce new syntax and may introduce new problems.

lobster_johnson 11y ago

Not defending this particular library, but there are some good reasons to use React abstractions even for simple things like a button. Some examples: * If the form deals with state and validation, then <Button> (as opposed to <button>) can automatically disable itself if the form's input isn't valid. * It can incorporate useful features like preventing redundant clicks (to prevent duplicate submits) and showing submit progress (eg., replace button label with a spinner while it's pending). * You can more easily add features that you would have to manually wire with an HTML <button>: For example, let it take a "tooltip" prop that will automatically show a tooltip on hover. As an aside, I should add that I wouldn't code up a "form with submit and cancel" like this. I would have the form component itself render the submit and cancel buttons, and call it something like SubmittableForm. This way, it can be in control of the UI (eg., validation, button placement, etc.) and submit logic. As for that htmlFor thing, I don't know why this library does it that way. There's no reason it couldn't correctly wire up a "for" attribute itself on the HTML label element.

afshin 11y ago
Just a guess, but it might be that because "for" is a JS restricted word, they picked an attribute name that wouldn't maybe trip up a syntax highlighter or something of that nature.
- lobster_johnson 11y ago
  That's not what I was referring to. There shouldn't be any reason for the FormField component to need to know the name of what the label is referring to, since it has access to its children through the "children" prop.