Live data from Hacker News

What should go into JSX 2.0?

github.com

81–90 of 102 posts

Re: What should go into JSX 2.0?

#81
post #16

I like how the if proposal is down voted, probably because it's mentioning Angular. Conditional rendering in React is not always very clean. Most codebases end up resorting with something similar to this in a container to show a spinner while data is loading and rendering it when done. Problem is that the inner component will still be parsed and fail with cannot read property person of undefined. Yes, you can do this…

In what sense is it not declarative anymore?

I usually use tests at the top of the render function to make sure that data is there, and return cleanly if it isn't. It just makes development easier as React components tend to get re-used. Within the data.person, in your example, the caller should make sure that it is complete, or pass nothing at all.

In the case you show I would either return or the content, but never nest them. Have a conditional and two return statements, or one return statement with a ternary operator.

Re: What should go into JSX 2.0?

#82
post #80
post #59

Nothing. Seriously, JSX works really well as it is. These proposals seem like small enhancements, some of them for the wrong reasons. > Computed attribute names. If you need this, you're probably being too clever. If there's a legitimate use for this, I've never seen it in the past 2 years I've been using JSX with React. > Object short hand notation. > Drop the need for curlies around attribute values if they're a si…

I personally agree with this in the big scheme of things. Computed attribute names seem overkill and I worry about adding logic to JSX. But, honestly, I could care less if they were added if such features get other people all fired up. My personal taste though often does wish for object shorthand and dropping curlies. My sense off the top of my head is that the majority of my actual props look something like ` ` sinc…

It's worth noting that if you want to go above and beyond what JSX gives you, it's not hard to write a Babel plugin to make the syntax more trite. You could (relatively) easily write "the coffeescript of JSX" that compiles to vanilla JSX if you want something that's "prettier and less typing" while not making it the standard.

Re: What should go into JSX 2.0?

#83
post #80

Earlier quoted context omitted.

I personally agree with this in the big scheme of things. Computed attribute names seem overkill and I worry about adding logic to JSX. But, honestly, I could care less if they were added if such features get other people all fired up. My personal taste though often does wish for object shorthand and dropping curlies. My sense off the top of my head is that the majority of my actual props look something like ` ` sinc…

It's worth noting that if you want to go above and beyond what JSX gives you, it's not hard to write a Babel plugin to make the syntax more trite. You could (relatively) easily write "the coffeescript of JSX" that compiles to vanilla JSX if you want something that's "prettier and less typing" while not making it the standard.

Standard syntax sugar is good not because syntax sugar is hard to accomplish, but it's something everyone implicitly agrees to understand. Custom schemes are not as maintainable

Re: What should go into JSX 2.0?

#84
My only real gripe about JSX is the crazy attribute casing rules. If it looks like HTML then attributes should be case-insensitive just like HTML. The worst of it is (unless this has changed) they are just silently dropped without any error message.

Re: What should go into JSX 2.0?

#85
post #83

Earlier quoted context omitted.

It's worth noting that if you want to go above and beyond what JSX gives you, it's not hard to write a Babel plugin to make the syntax more trite. You could (relatively) easily write "the coffeescript of JSX" that compiles to vanilla JSX if you want something that's "prettier and less typing" while not making it the standard.

Standard syntax sugar is good not because syntax sugar is hard to accomplish, but it's something everyone implicitly agrees to understand. Custom schemes are not as maintainable

I'd otherwise agree, but JSX is already syntax sugar. Once you start making the syntax ambiguous or minimalist to the point of confusion, you should break off into a new syntax.

Re: What should go into JSX 2.0?

#86
post #16

I like how the if proposal is down voted, probably because it's mentioning Angular. Conditional rendering in React is not always very clean. Most codebases end up resorting with something similar to this in a container to show a spinner while data is loading and rendering it when done. Problem is that the inner component will still be parsed and fail with cannot read property person of undefined. Yes, you can do this…

I down voted that proposal as well, but not because the mention of Angular, but because I don't like the `ng-if` way of doing conditionals. One of the reason I like JSX is because it is "just Javascript". Putting the flow control logic into component attributes like that is a terrible idea for JSX.

Re: What should go into JSX 2.0?

#87
post #84

My only real gripe about JSX is the crazy attribute casing rules. If it looks like HTML then attributes should be case-insensitive just like HTML. The worst of it is (unless this has changed) they are just silently dropped without any error message.

The React ESLint plugin's no-unknown-property rule is handy for catching (and automatically fixing) this:

https://github.com/yannickcr/eslint-plugin-react/blob/master...

Re: What should go into JSX 2.0?

#88
post #87
post #84

My only real gripe about JSX is the crazy attribute casing rules. If it looks like HTML then attributes should be case-insensitive just like HTML. The worst of it is (unless this has changed) they are just silently dropped without any error message.

The React ESLint plugin's no-unknown-property rule is handy for catching (and automatically fixing) this: https://github.com/yannickcr/eslint-plugin-react/blob/master...

Good to know, thanks.

That's a good stop-gap, but the tool itself should either pass through everything to the HTML or throw errors on anything that isn't going to get passed through. The silent failure mode is a UX bug.

Re: What should go into JSX 2.0?

#89
post #59

Nothing. Seriously, JSX works really well as it is. These proposals seem like small enhancements, some of them for the wrong reasons. > Computed attribute names. If you need this, you're probably being too clever. If there's a legitimate use for this, I've never seen it in the past 2 years I've been using JSX with React. > Object short hand notation. > Drop the need for curlies around attribute values if they're a si…

It does seem really good right now. If they go crazy imperative on it, they'll end up with jsp. If they go crazy functional on it, they'll end up with xslt.

I'm good with how it is right now. The sour stuff is in the js, and the sugar in the jsx.

Re: What should go into JSX 2.0?

#90
post #88
post #87

Earlier quoted context omitted.

The React ESLint plugin's no-unknown-property rule is handy for catching (and automatically fixing) this: https://github.com/yannickcr/eslint-plugin-react/blob/master...

Good to know, thanks. That's a good stop-gap, but the tool itself should either pass through everything to the HTML or throw errors on anything that isn't going to get passed through. The silent failure mode is a UX bug.

If I understand your comment correctly, this is checked in more recent versions of React: https://facebook.github.io/react/warnings/unknown-prop.html
Post reply on HN