Absolute inelegant shit, use Elm
What should go into JSX 2.0?
91–100 of 102 posts
Re: What should go into JSX 2.0?
#92I 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 actually generally include this in my Babel configuration: https://www.npmjs.com/package/jsx-control-statements.
People might argue that this isn't the React way of doing things, but it's easier than setting a conditional classname to display none. It's also easier than breaking out a small amount of html into a separate component just because you want some conditional display logic.
Re: What should go into JSX 2.0?
#93Nothing. 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…
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.
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 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.
Re: What should go into JSX 2.0?
#94Nothing. 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…
You can do ``
Re: What should go into JSX 2.0?
#95Earlier quoted context omitted.
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
It does seem to be the same issue. That's great, it will certainly avoid some frustration.
Re: What should go into JSX 2.0?
#96Earlier 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…
Regarding 1)... like 5) that's React, so you could write a JSX transpiler that creates actual DOM objects.
Re: What should go into JSX 2.0?
#97Earlier 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…
[deleted]
Re: What should go into JSX 2.0?
#98Earlier 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…
You can do ` `
Oh man you're right aren't you! I just might start doing that!
Re: What should go into JSX 2.0?
#99make it s-exp?
You mean Elm?
Re: What should go into JSX 2.0?
#100Earlier quoted context omitted.
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.
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 wel…
> 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.