321–330 of 574 posts
Earlier quoted context omitted.
You still need to use class components for error boundaries. https://reactjs.org/docs/error-boundaries.html
Yeah, this feels like a weird oversight.
Earlier quoted context omitted.
Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn'…
> The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the Web 2.0 Age by some, an Age yet to come, an Age long past, a wind rose above the great mountainous island of FANNG. The wind was not the beginning. There are neither beginnings nor endings to the Wheel of Time.…
There's very little need for a
onChange(e) => setFormValue(e.target.value)
There is an absurdly simple solution which removes all the 'cruft' the article bemoans: use uncontrolled form elements that then send the form data to the server and have the server do the validation, error messaging etc.
In this approach, the client gets back into the business of pure network calls. When the server sends back a response parse it and update the UI. This is trivial with some conditional rendering of error messages, styles etc.
But rarely is this done. This approach is why I really like using Remix. It encourages this paradigm by coupling the server side code that runs on a form submission in the same file as the client side code.
All this becomes blissfully easy.
Relatively new react developer here (still learning in fact!), I liked this article although it shook me a bit and made me wonder "am I wasting time with some of this stuff? maybe I should be looking ahead to the next 'best framework'". Id be interested in hearing people's thoughts: what would be best to learn for maximum applicability in the ~3 year timeframe?
Learn the theory, not the framework.
I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.
I ditched React soon after they released hooks, mainly because I couldn't relate to the tradeoff React roadmap was taking from there. They went in a different direction from that point onwards, it seem like whatever code you write will become obsolete with the new set of best practices in the next release cycle. More importantly, I realized React is trying to tame Facebook level of problems and hence their design dec…
Did you rewrite your entire app?
Earlier quoted context omitted.
> hooks aren’t JS They literally are. > hooks aren’t JS The code in React executing components relies on hooks running in a consistent order each time the component runs, but the existence of a runtime context that has expectations about side effects (and hooks are side effects) doesn't make it “not javascript”.
Hooks are executed in order as they are defined, isn't that a fundamentally broken design in regards to language spec? I don't have an opinion, just generally curious because it feels very odd that the order of my functions matter.
Hooks are functions, and they are executed in the order called from within the component, which is itself a function, just like any other functions calls from within another function.
(The mechanism tracking calls to them and deciding whether the function passed to the hook needs to be called requires them to be called in the same order each time the component is executed; if they were called in order of definition rather than normal execution order this would be true by definition; the whole reason for the rule about not using flow control around them is that they are functions executed in normal flow order.)
Earlier quoted context omitted.
Maybe, but would you need async rendering if React wasn't so slow?
As opposed to what? Vue is slower and Angular too. Perhaps Svelte might be faster but the programming paradigm is a little weird. Writing pure JS is bullshit - I tried it few months ago and even a very simple app - for public transport schedules - got very unmanageable very quickly. I'm currently working on a project with hundreds of reactive components shown at any given time (very extensive financial analytics/mode…
https://krausest.github.io/js-framework-benchmark/current.ht...
Hmm… let me be frank about my experiences with React. I’ve been using React heavily for far over 6 or 7 years. React is amazing. And what I see is that people find so many ways to shoot themselves in the foot. At the same time, I understand that batteries-not-included approach will lead to that result. First of all, people get out of their skin and try to make it a complicated and entangled mess. In programming, ther…
Where are good examples of clean, well-implemented React code by your definition? Because your comment perfectly encapsulates my experiences and frustrations in learning and using React off-and-on over the past 8 years or so. React is the one tech that really freaks me out because every time I have to dive into it, it's a completely different beast and it feels like so many people actually writing in React are just e…
I would love to point to a good repo, but all the apps I’ve worked with are closed source. And I haven't seen a good open one :/
Pinky promise to finish a response here or write a blog post and post a link here. But have to go now to get some sleep
Earlier quoted context omitted.
Agreed. Vue is the best of all worlds in my opinion. Here's my take on the whole thing from a Svelte post a couple of weeks back: https://news.ycombinator.com/item?id=32763509#32767905 > I still think Vue (especially Vue 2) is the greatest of them all. I've worked professionally with Angular, React, and Vue. Each for several years. Vue is easily the winner for me with the syntax that closely matches native HTML and J…
v-if and v-else are not native html attributes either. Control flow via HTML tags has always felt like a code smell and been a major turn off to me.