6 ms·

Nothing. Seriously, JSX works really well as it is. These proposals seem like small enhancements, some of them for the wrong reasons. > Computed attribute name

by jameslk 10y ago

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 single literal, or parenthesis. Is it really that much more work? > Implicit do expressions. > Conditionals > Loops If you need control statements in your JSX, you're doing it wrong. When you need these things, this is a sign you need to break your code into smaller chunks. Move this logic into separate functions, lambdas or variables and interpolate them in. Now you've labeled your code and made it more composable. This is called self-documenting code and it's a lot easier for others and your future self to read. All of these wouldn't be so bad if it wasn't a proposal to justify breaking changes. I really don't want to have to deal with two versions of JSX that are incompatible. That just sounds like hell.

abritinthebay 10y ago
Agree wholeheartedly - this smacks of the repeated mistake that most template tools make which is trying to do language logic inside. The whole point of JSX is that it isnt a template language and is just a wrapper around objects with properties.
- matt4077 10y ago
  Most template tools made the major mistake of existing. They start out as some attempt to limit the functionality available in templates but pretty soon they always add functions and conditionals and formatters etc... ending up with what is essentially a turing-complete language, except needing an extra step to parse, less well tested and usually much uglier than the host language. Oh, and you have to learn it as well, because someone had a fetish of avoiding python/php/perl/... in templates, inventing <loop start=1 end=15 step=1> to replace (1..15).each. Nowadays we're replacing loops with recursion or map but fundamentally, there's no difference. If you have a collection and you want to render it, you need the logic of repetition in a template, and there's nothing wrong wit h putting it there. 10 years ago, you would often see html with interspersed business logic, even SQL. That just doesn't happen anymore. Now, fruitless attempts to further reduce logic in templates just lead to convoluted overengineering who at best try to hide the logic.
  - abritinthebay 10y ago
    > Most template tools made the major mistake of existing. haha, harsh. I don't disagree but there are cases where they make sense (pure, designer focused, flows for example). But anywhere where a dev will be involved generally a template language is solving the wrong problem. JSX is quite an elegant solution to the issue: provide abstraction, but allow underlying logic to be in the same language.
dcd0101 10y ago
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?
- jameslk 10y ago
  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.
  - gbog 10y ago
    Yep, how do we vote against logic inside jsx markup?
deleted 10y ago
[deleted]
arstin 10y ago
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 `<Widget user={user} id={id} timestamp={timestamp} />` 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 `<Widget user id timestamp />` or `<Widget $user $id $timestamp />` 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.
- bastawhiz 10y ago
  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.
  - ludamad 10y ago
    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
    - bastawhiz 10y ago
      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.
- joesb 10y ago
  You can do `<Widget {...{user, id, timestamp}} />`
smrtinsert 10y ago
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.

by jameslk 10y ago

abritinthebay 10y ago

Agree wholeheartedly - this smacks of the repeated mistake that most template tools make which is trying to do language logic inside. The whole point of JSX is that it isnt a template language and is just a wrapper around objects with properties.

matt4077 10y ago
Most template tools made the major mistake of existing. They start out as some attempt to limit the functionality available in templates but pretty soon they always add functions and conditionals and formatters etc... ending up with what is essentially a turing-complete language, except needing an extra step to parse, less well tested and usually much uglier than the host language. Oh, and you have to learn it as well, because someone had a fetish of avoiding python/php/perl/... in templates, inventing <loop start=1 end=15 step=1> to replace (1..15).each. Nowadays we're replacing loops with recursion or map but fundamentally, there's no difference. If you have a collection and you want to render it, you need the logic of repetition in a template, and there's nothing wrong wit h putting it there. 10 years ago, you would often see html with interspersed business logic, even SQL. That just doesn't happen anymore. Now, fruitless attempts to further reduce logic in templates just lead to convoluted overengineering who at best try to hide the logic.
- abritinthebay 10y ago
  > Most template tools made the major mistake of existing. haha, harsh. I don't disagree but there are cases where they make sense (pure, designer focused, flows for example). But anywhere where a dev will be involved generally a template language is solving the wrong problem. JSX is quite an elegant solution to the issue: provide abstraction, but allow underlying logic to be in the same language.

dcd0101 10y ago

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?

jameslk 10y ago
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.
- gbog 10y ago
  Yep, how do we vote against logic inside jsx markup?

deleted 10y ago

[deleted]

arstin 10y ago

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 `<Widget user={user} id={id} timestamp={timestamp} />` 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 `<Widget user id timestamp />` or `<Widget $user $id $timestamp />` 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.

bastawhiz 10y ago
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.
- ludamad 10y ago
  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
  - bastawhiz 10y ago
    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.
joesb 10y ago
You can do `<Widget {...{user, id, timestamp}} />`

smrtinsert 10y ago

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.