4 ms·

DOM.div() vs <div/> seems like a bad example. IMHO, when you get an element with tons of event handlers and conditional classes, or when you have a deep chain o

by lhorie 10y ago

DOM.div() vs <div/> seems like a bad example. IMHO, when you get an element with tons of event handlers and conditional classes, or when you have a deep chain of ternaries that's where angled bracket syntax starts to become unwieldy. The className thing is a big deal too, in my opinion. Preact and Mithril do what you would expect, and perf doesn't suffer, so why can't React/JSX normalize it as well?

Bahamut 10y ago
className was named that to avoid conflict with the JS class syntax originally I believe, since JSX is inline - they probably could put in the work to change it at this point, but it seems like a minimally beneficial change but massively disruptive at this point.
- jmtulloss 10y ago
  It was named that to match the DOM api[0], which React does whenever possible. The DOM api is probably named for the reason you state. [0]: https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
  - rmetzler 10y ago
    And the reason why the DOM API uses className is: class is a reserved keyword in JavaScript for a long time.
- lhorie 10y ago
  There's also stuff like onClick, readOnly, xlinkHref... I would guess that a healthy number of React-related google searches are related to these gotchas
debaserab2 10y ago
If you have deep chains of ternarys, that's a symptom that you should be splitting your rendering code into another function or component. This would be true regardless or what approach you are taking to templatihg. That's one thing I really appreciate about jsx: the lack of rich template code syntax makes it glaringly obvious when your template code is doing too much and should be refactored. It does a really good job of keeping your logic in javascript and out of your template.
- lhorie 10y ago
  Refactoring into functions/components doesn't magically make a complex ternary tree go away. It helps the body of each branch be less noisy but the ternary tree will still be there. You're talking about taking something like `foo && bar || baz && quux` and turning it into `isSomeCondition()`, but that's a pretty obvious refactor in any templating system. I'm talking about things like return ( <div>{ x.type === 'foo' ? <Something/> : x.type === 'bar' ? ( <div> <h2>More stuff</h2> <Another data={x.data}/> </div> ) : x.type === 'baz' ? <Another data="baz"/> : null }</div> ) At this point, I think it's perfectly valid to have the opinion that JSX isn't helping much, since the JS-to-HTML ratio in this case is relatively high. Refactoring would just make it more difficult to mentally piece things back together given you would end up with sparse component instantiations scattered amidst otherwise-procedural js code, as opposed to the more ideal single-root, declarative virtual dom tree.
  - debaserab2 10y ago
    Without understanding what x.type is, I'd be inclined to write that without any ternary operator at all using plain old if statements with each returning JSX markup. I try to keep logic in JSX to simple ternary operators and loops at most. JSX is really just shorthand for DOM.div() for me. I imagine the code structure looks pretty similar to actually using DOM.div though. I'm not seeing how programmatically creating markup with DOM.div results in significantly different code, although if you have some good examples I'd love to understand them better.
    - lhorie 10y ago
      Those are two different aspects of template code. Pulling things out into plain if statements is fine if you only have one or two, but in my opinion, it gets progressively harder to understand the code as the number of if statements increase (for the same reason that writing vanilla DOM creation code does). In my experience, when this type of refactor is allowed, it's common to pull just about everything up to the top of the render function (conditional className compositions, conditional components, even loops). This increases cognitive load because now the maintainer has to mentally piece everything back together on every read. Having been that maintainer, I'd say it's the sort of code that it's fun to write, but not fun to read. The rationales in favor of hyperscript are largely cosmetic (e.g. JS indents more naturally), and I think that's very much a potato-potahto kind of discussion. Personally, I feel that hyperscript is more readable (because of the terser CSS selector syntax), but likewise, I totally understand that some people find angled brackets easier to read even if that entails super long attribute lists.
nkohari 10y ago
Ternary operators should never be nested, whether you're using JSX or not. If you have that many conditionals you should use variables and/or decompose the optional pieces into sub-components. Pretty much any time you have a tag that has a huge number of attributes, it's a smell that you need to decompose something. Variable assignment is the simplest answer, which takes advantage of the fact that null or undefined values are ignored in JSX: const Dashboard = (props) => { let avatar; if (props.user) avatar = <Avatar user={props.user} />; return ( <div> {avatar} ...some other content... </div> ); }; Regarding class vs. className: class is a reserved word in JS. It's not really a perf thing, it's the fact that JSX was intended as a very simple transform. If JSX used class instead of className, the transpiler would need to be contextual since "class" would sometimes mean "css class" and sometimes "JavaScript class". The baseline complexity for the parser would be higher and could lead to all sorts of complexity. Rather than deal with that the React team avoided the problem by using className instead, keeping things simple.
- duncanawoods 10y ago
  I think this proves lhorie's point. Markup syntax is dominated by code when you are building complex dynamic apps instead of static documents. What do you really gain by putting angle brackets around Avatar instead of calling a function? FWIW I believe new react devs are slow to realise they can use local variables like this because JSX looks like it is doing string templating instead of object instantiation.
  - nkohari 10y ago
    The example I gave was simplistic, but the value of JSX is the ability to easily nest elements. For instance, let's take my previous example and say we're creating a profile link: const Dashboard = (props) => { const {user} = props; let link; if (user) { link = ( <a href="..."> <Avatar user={user} /> <span>{user.name}</span> </a> ); } return ( <div> {link} ...some other content... </div> ); }; If you want, you could create a `createProfileLink()` function, or you could create a `ProfileLink` component, or you could keep it as a variable in the `render()` function. This flexibility is what makes JSX powerful.

by lhorie 10y ago

Bahamut 10y ago

className was named that to avoid conflict with the JS class syntax originally I believe, since JSX is inline - they probably could put in the work to change it at this point, but it seems like a minimally beneficial change but massively disruptive at this point.

jmtulloss 10y ago
It was named that to match the DOM api[0], which React does whenever possible. The DOM api is probably named for the reason you state. [0]: https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
- rmetzler 10y ago
  And the reason why the DOM API uses className is: class is a reserved keyword in JavaScript for a long time.
lhorie 10y ago
There's also stuff like onClick, readOnly, xlinkHref... I would guess that a healthy number of React-related google searches are related to these gotchas

debaserab2 10y ago

If you have deep chains of ternarys, that's a symptom that you should be splitting your rendering code into another function or component. This would be true regardless or what approach you are taking to templatihg. That's one thing I really appreciate about jsx: the lack of rich template code syntax makes it glaringly obvious when your template code is doing too much and should be refactored. It does a really good job of keeping your logic in javascript and out of your template.

lhorie 10y ago
Refactoring into functions/components doesn't magically make a complex ternary tree go away. It helps the body of each branch be less noisy but the ternary tree will still be there. You're talking about taking something like `foo && bar || baz && quux` and turning it into `isSomeCondition()`, but that's a pretty obvious refactor in any templating system. I'm talking about things like return ( <div>{ x.type === 'foo' ? <Something/> : x.type === 'bar' ? ( <div> <h2>More stuff</h2> <Another data={x.data}/> </div> ) : x.type === 'baz' ? <Another data="baz"/> : null }</div> ) At this point, I think it's perfectly valid to have the opinion that JSX isn't helping much, since the JS-to-HTML ratio in this case is relatively high. Refactoring would just make it more difficult to mentally piece things back together given you would end up with sparse component instantiations scattered amidst otherwise-procedural js code, as opposed to the more ideal single-root, declarative virtual dom tree.
- debaserab2 10y ago
  Without understanding what x.type is, I'd be inclined to write that without any ternary operator at all using plain old if statements with each returning JSX markup. I try to keep logic in JSX to simple ternary operators and loops at most. JSX is really just shorthand for DOM.div() for me. I imagine the code structure looks pretty similar to actually using DOM.div though. I'm not seeing how programmatically creating markup with DOM.div results in significantly different code, although if you have some good examples I'd love to understand them better.
  - lhorie 10y ago
    Those are two different aspects of template code. Pulling things out into plain if statements is fine if you only have one or two, but in my opinion, it gets progressively harder to understand the code as the number of if statements increase (for the same reason that writing vanilla DOM creation code does). In my experience, when this type of refactor is allowed, it's common to pull just about everything up to the top of the render function (conditional className compositions, conditional components, even loops). This increases cognitive load because now the maintainer has to mentally piece everything back together on every read. Having been that maintainer, I'd say it's the sort of code that it's fun to write, but not fun to read. The rationales in favor of hyperscript are largely cosmetic (e.g. JS indents more naturally), and I think that's very much a potato-potahto kind of discussion. Personally, I feel that hyperscript is more readable (because of the terser CSS selector syntax), but likewise, I totally understand that some people find angled brackets easier to read even if that entails super long attribute lists.

nkohari 10y ago

Ternary operators should never be nested, whether you're using JSX or not. If you have that many conditionals you should use variables and/or decompose the optional pieces into sub-components. Pretty much any time you have a tag that has a huge number of attributes, it's a smell that you need to decompose something. Variable assignment is the simplest answer, which takes advantage of the fact that null or undefined values are ignored in JSX: const Dashboard = (props) => { let avatar; if (props.user) avatar = <Avatar user={props.user} />; return ( <div> {avatar} ...some other content... </div> ); }; Regarding class vs. className: class is a reserved word in JS. It's not really a perf thing, it's the fact that JSX was intended as a very simple transform. If JSX used class instead of className, the transpiler would need to be contextual since "class" would sometimes mean "css class" and sometimes "JavaScript class". The baseline complexity for the parser would be higher and could lead to all sorts of complexity. Rather than deal with that the React team avoided the problem by using className instead, keeping things simple.

duncanawoods 10y ago
I think this proves lhorie's point. Markup syntax is dominated by code when you are building complex dynamic apps instead of static documents. What do you really gain by putting angle brackets around Avatar instead of calling a function? FWIW I believe new react devs are slow to realise they can use local variables like this because JSX looks like it is doing string templating instead of object instantiation.
- nkohari 10y ago
  The example I gave was simplistic, but the value of JSX is the ability to easily nest elements. For instance, let's take my previous example and say we're creating a profile link: const Dashboard = (props) => { const {user} = props; let link; if (user) { link = ( <a href="..."> <Avatar user={user} /> <span>{user.name}</span> </a> ); } return ( <div> {link} ...some other content... </div> ); }; If you want, you could create a `createProfileLink()` function, or you could create a `ProfileLink` component, or you could keep it as a variable in the `render()` function. This flexibility is what makes JSX powerful.