401–410 of 486 posts
Earlier quoted context omitted.
Everything is a 3rd party library when it comes to the building complex React based app. Redux is a part of the hype train, so you are going to use it if you are on the train.
There's two mainstream options for state management right now: Redux and MobX. But even the creator of Redux says "You might not need redux" https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Earlier quoted context omitted.
I agree. Those examples have nothing to do with learning a new template syntax, it's simply the API of React.Component. Granted, there is still some syntax you need to learn for JSX, but it's very little. If you already know HTML's syntax, the only new things I can think of are the curly braces for using JS expressions as prop values (you also need to know what a JS expression is, lest you try to use an if statement)…
I think you misunderstand. The names are unrelated to React as well, they are native. Defined by the same standards bodies that define JavaScript itself, implemented by the browsers themselves. On a blank HTML page that includes neither React nor anything else, the line `document.body.className = "foo";` sets the body's class to "foo". (And `document.body.class = "foo";` does not.) All JSX is doing is transforming `…
React defines `React.createElement`, `` transforms to `React.createElement("div", { "class": "foo" })`, so React could convert that under the hood to set className correctly.
Preact does something similar to allow this. However it now seems it is now too late for React for too little benefit. And there's a downside [1]:
> The JSX transform used to do that, but we don't recommend it because it's confusing if you ever try to pass class= or for= as a prop to your own components – you wouldn't expect to access them with a different name.
[1] https://github.com/facebook/react/issues/4433#issuecomment-1...
Earlier quoted context omitted.
In my experience, the folks that feel the strongest against JSX lean anti-JavaScript in general. JSX is Turing-complete. There are no gotchas, you can't paint yourself into a corner, you can set breakpoints in your map statements, it's more testable...Lots of benefits and a big step up over string-based templating languages stuffed into HTML.
And how in the world is that a good thing? I'm really starting to wonder if people that exalt JSX with his mix of logic and presentation have ever worked on complex systems where the lack of separation between the two layers brings you quickly to an unmaintainable mess.
And HTML string template languages have been shown to have numerous shortcomings at scale.
Earlier quoted context omitted.
*hear hear! ;)
In fairness, it is entirely possible that the parent was correctly indicating the location of a salient / appreciated point in this discussion thread ;)
Just use ockham's razor, would you suppose he misspelt a general language construct or created a whole new one? :)
I can end this post here, but I want to mention one more thing I'm reminded of: In Sherlock Holmes TV Series (don't remember the episode), a woman dies while writing "Rache" in her own blood. Other characters tell him that Rache is revenge in German. Sherlock posits that she was trying to write "Rachel", a much simpler (I mean with less assumptions) assumption to make in the context.
"HN Pedantry" is rubbing off on me :D
In this thread people are fighting about their _opinions_ why they use Vue.js or React. And why X is really better than Y. In reality these programmers don't want to have the feeling they might have made the wrong choice when they used X instead of Y. The idea that they might have taken the poorer choice hurts so much that they need to defend their decision so heavily while in reality taking ReactJS or Vue.js is like…
Earlier quoted context omitted.
I'm not sure I follow. To use the basic example from the link, as opposed to this: const listItems = numbers.map((number) => {number} ); return ( {listItems} ); What's wrong with looping this way?: return ( {numbers.map((num, i) => {num} )} )
> What's wrong with looping this way? The problem IMO is that it's harder to read and write than: {{num}} That's Vue's syntax, but any other templating language is more readable to me than JSX.
return (
{numbers.map((num, i) => (
{num}
))}
)
The advantage is that it is statically checkable with a linter, so you would get a compile-time error if you misspell the HTML tag, a variable or anything else.
If you use something Typescript, the compiler will even check the props given to components (and if you use VS Code, you'll get auto-completion for variables, methods, props and anything statically checkable). You can even apply inheritance to components for dynamic component switching.
I briefly used Vue before switching completely to React (with Typescript, Webpack and Mobx) and it finally became enjoyable to write Javascript applications.
Earlier quoted context omitted.
It's slightly less easy to read than ... But it means you don't have to learn a library's HTML API. Or when you want to loop through myList, but exclude a few particular items... you know how to write that in JS, but have no idea what to do in the mark up language. You could create a filteredList, but it's often not ideal
I cannot really understand how today mixing logic and presentation in JSX is considered a good thing. The first principle when writing complex systems should be to completely separate the logic from the presentation layer. Nowadays people seem happy with intermingled monstrosities like the one shown in the JSX code upstream.
We moved away from React to Vue about 8 months ago and everyone on the team is a lot happier. First reason is we hate JSX. It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading. It's like writing shitty PHP code without templates. It also forces you to use a lot of boilerplate like bind(), Object.keys(), etc. Another problem with React is that it only really solves o…
> It's like writing shitty PHP code without templates. For me, it's the other way around. I feel like you can still separate the logic and markup, but instead of the template engine syntax you can just JavaScript. From the top of my head, I can at least remember six template engines' syntax I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another custom template engine. When I tried React I was so…
JSX is another templating language. One built on top of JavaScript rather than HTML.
Earlier quoted context omitted.
> It's like writing shitty PHP code without templates. For me, it's the other way around. I feel like you can still separate the logic and markup, but instead of the template engine syntax you can just JavaScript. From the top of my head, I can at least remember six template engines' syntax I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another custom template engine. When I tried React I was so…
> I can at least remember six template engines' syntax I've learned... TBH, in 2017, I'm not sure why we're still hand-generating HTML with any template language. Instead, I'd really like to see a framework that gets away from the idea of HTML templating altogether and presents a true component/properties model on top of a canvas with flexible, property-driven layout options. I think the intense UI-demands of progres…