Live data from Hacker News

What should go into JSX 2.0?

github.com

71–80 of 102 posts

Re: What should go into JSX 2.0?

#71
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'm inclined to agree on all these points, but I do end up doing most of these things now, in one way or another.

For loops I'll create a collection of items in a function (usually done with map against a prop collection) and drop that variable in my JSX.

Basically the same for conditionals. If I want a thing, a var gets a component assigned. Otherwise it's null.

Are these bad patterns, as is?

Re: What should go into JSX 2.0?

#72
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…

[deleted]

Re: What should go into JSX 2.0?

#74
post #71
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'm inclined to agree on all these points, but I do end up doing most of these things now, in one way or another. For loops I'll create a collection of items in a function (usually done with map against a prop collection) and drop that variable in my JSX. Basically the same for conditionals. If I want a thing, a var gets a component assigned. Otherwise it's null. Are these bad patterns, as is?

No, these are good patterns. You've taken an otherwise large chunk of code and broken it down into comprehensible pieces that can be composed together and tested individually. This also leads nicely into refactors, where you can extract these smaller chunks into new components when your old component is handling too many responsibilities.

Unfortunately if control flow gets bolted onto JSX we can expect to see a lot less of this. Others will assume that this is the way business is done. That is, creating hundreds of lines of hard to follow conditionalized pseudo XML. I realize this already occurs in more bastardized forms, but it shouldn't be encouraged by new language features.

Re: What should go into JSX 2.0?

#76
post #56
post #21

Earlier quoted context omitted.

It's the extreme fanboyism there! Wrapping every component that has ` if` attribute with an `if` statement should not result into that: foo // results to if (cond1 && cond2) { return React.createElement('div', null, React.createElement('div', null, 'foo') ); } I'm not sure why this is bad? Because it's looking like Angular?!!

I'd love for them to adopt something similar to Razor (Microsoft server side html engine) note: i've changed your example to show code inside html tags, i'm aware it does something different to yours. conditionals @if(cond1 && cond2) { foo } loops @for(var i in collection) { } variables @variable ternary/longer statement @(variable ? 1 : 2)

The one negative thing I've found with Razor is the ambiguous start and end of statements or expressions vs html. Sometimes a @ is required before a statement and sometimes its a syntax error, conversely statements and and expressions may be rendered as text if they follow html with a @. I think jsx's approach is clearer.

Re: What should go into JSX 2.0?

#77
post #74
post #71

Earlier quoted context omitted.

I'm inclined to agree on all these points, but I do end up doing most of these things now, in one way or another. For loops I'll create a collection of items in a function (usually done with map against a prop collection) and drop that variable in my JSX. Basically the same for conditionals. If I want a thing, a var gets a component assigned. Otherwise it's null. Are these bad patterns, as is?

No, these are good patterns. You've taken an otherwise large chunk of code and broken it down into comprehensible pieces that can be composed together and tested individually. This also leads nicely into refactors, where you can extract these smaller chunks into new components when your old component is handling too many responsibilities. Unfortunately if control flow gets bolted onto JSX we can expect to see a lot l…

Yep, how do we vote against logic inside jsx markup?

Re: What should go into JSX 2.0?

#78
post #14

Earlier quoted context omitted.

Yup, even the issues not marked controversial seem so to me. I think JSX is quite nice but it has its limits/annoyances. One is obviously that it's not real HTML5. I would like to see a successor that is more like HTML5 without the X. No idea how that could be realized though... ;)

Sorry, what do you mean by this? (For those unfamiliar with the deviations)

I started using React/JSX professionally in the last few months, so some of these are fresh in my head. Differences I'm aware of:

1) JSX creates virtual DOM objects, not HTML tags. In places where the DOM and HTML use different names for the same thing, JSX uses the DOM's name. In particular, the "class" attribute is called "className" and the "style" attribute takes an object like { color: "white" } instead of a string like "color: white" (and the keys are like "backgroundImage" rather than "background-image"). The latter rarely comes up, but the former bites me all the time when incorporating markup from designers.

2) JSX requires all tags to be closed, like XHTML and all XML dialects. HTML 5 declares some tags to be self-closing, like IMG.

3) JSX removes whitespace padding inside elements. This usually results in the same visual result, except for those cases where HTML actually cares about extra whitespace (like in PRE and TEXTAREA).

4) Regarding TEXTAREA, you're encouraged not to use the inner content of the tag to define its default value. Instead, you treat it like an INPUT. (I think this is if anything an improvement.)

5) INPUT tags have some special behavior related to default values, but that's really more about React than JSX per se.

Overall I have found JSX pretty easy to get into. I appreciate that it really is just a very thin layer over underlying JS. I'm not totally sold on this approach versus the many, many, many other HTML templating systems out there, but at least it's easy to understand.

Re: What should go into JSX 2.0?

#79
post #78
post #14

Earlier quoted context omitted.

Sorry, what do you mean by this? (For those unfamiliar with the deviations)

I started using React/JSX professionally in the last few months, so some of these are fresh in my head. Differences I'm aware of: 1) JSX creates virtual DOM objects, not HTML tags. In places where the DOM and HTML use different names for the same thing, JSX uses the DOM's name. In particular, the "class" attribute is called "className" and the "style" attribute takes an object like { color: "white" } instead of a str…

Ah, I see, thanks for sharing. Yes, I personally view most of those deviations as positive.

Re: What should go into JSX 2.0?

#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 `` since I mostly avoid setting up data inside JSX. Is it a big deal? Of course not. But it would be nicer to just write `` or `` or whatever syntactic sorcery would be settled on.

A modest advantage of dropping curlies is it reduces the already tiny force of one argument for styling in CSS over JS: "prettier and less typing". I certainly don't think they should be dropped just for this reason of course, but could be a side effect worth noting.

Post reply on HN