91–100 of 168 posts
Can someone tell me why this page needs 13MB of resources to display?
My guess is for the code editors and associated transpiler. The demos allow you to edit the code in JSX, requiring the tooling. Kinda impressive imo.
Earlier quoted context omitted.
FWIW, React has always been designed around some Functional Programming type principles, such as immutable updates. Immutable updates do in fact require that if you want to update `state.some.nested.field`, you have to make copies of _all_ objects in that path: `nested`, `some`, and `state`. This isn't unique to React. Yes, class component `this.setState()` lets you get away with mutations. That's not really a _good_…
When updating deeply-nested immutable objects, the Immer library is great. You call the `produce(immutableValue, draft => { ... })` function with some immutable value and a callback function that manipulates a mutable proxy object mimicking the immutable value, and then the function returns a new immutable value with the same changes made by the callback function. The mutable proxy object never escapes the callback,…
A pain point with React is large data structures. To re-render (assuming class components), you can setState with the changed property. For example if your state has two properties named foo and bar, and bar has changed then you call setState({ bar: newValue }). This works if you have simple properties. What if you have large complex data structures, and you need to modify a property deep down inside? Then you can ma…
> But it is tremendously wasteful to make a complete copy of a large data structure! You don't make a complete copy: you make a shallow copy of the spine, and then only descend along the fields you actually modify. The number of operations scales as O(branching factor * depth), not O(size).
Sounds painful.
Edit: Sorry, because the parent component re-rendered too. Except it didn't. But maybe? Nah, it didn't. Did it?
A lot of people are going to think this is being ridiculous, but there were actually bugs as recently as a few months ago(maybe still?) in the dev tools where they would not know the actual re-render reason and it would spit out a generic "parent component re-rendered" instead.
Josh's content is always very very high quality. I look forward to him releasing his online React course [0] so that I can recommend it to others who are starting out. My personal biggest not-total-comprehension is around Hooks / effects. I've followed tutorials, used them in production, etc. I'm comfortable using them but I also consider them a bit of a black box, which I don't like (e.g. I'm not sure how they're im…
They are yet more evidence that any human engineered system will inevitably 'diverge' to become the most complicated thing that just about works - what we might call the complexity horizon. Driven by the power of our 'ingenuity', even the most elegant constructions will find themselves drifting towards this horizon. It takes super human effort to resist the effect, and super humans to keep systems from escaping us.
Earlier quoted context omitted.
Hooks feel like a good system that stopped right before it became pretty. Like, an componentDidMount event is a now useEffect with no second argument? But a componentWillUnmount event is now a useEffect, with no second argument, that returns a callback? It's powerful, and it's not that hard to use, but it's cryptic and random. Why call it useEffect instead of some other more meaningful phrase? I mean, "componentDidMo…
You're translating the class-based way of working in React against hooks, without stopping to consider understanding hooks as a first-class principle instead of a translation. It's called useEffect because it runs on the (side)effects observed by the dependency array. An empty array happens to happen on mount. useEffect returns a teardown function which happens to correlate with unmount when an empty array is passed.…
I believe this teardown function runs on unmount whether or not the dependency array is empty.
Earlier quoted context omitted.
Hooks feel like a good system that stopped right before it became pretty. Like, an componentDidMount event is a now useEffect with no second argument? But a componentWillUnmount event is now a useEffect, with no second argument, that returns a callback? It's powerful, and it's not that hard to use, but it's cryptic and random. Why call it useEffect instead of some other more meaningful phrase? I mean, "componentDidMo…
> Like, an componentDidMount event is a now useEffect with no second argument? Doesn't useEffect with no second argument run after every render? componentDidMount's equivalent is for an empty dependency array in the second argument?
Mix in actual deps coming from other hooks, changing as the components re-render, and multiple layers of "custom hooks" with more of the same and it's like trying to hold back a tsunami.
If you're confused about the last part where it mentioned where useMemo and useCallback can help when passing props, I completely understand after reading Kent C Dodds block and Dan Abramov.
Further, I learned a lot by taking interactive course from Dan Abramov in https://justjavascript.com
Highly recommended! good read!!
https://kentcdodds.com/blog/usememo-and-usecallback https://overreacted.io/a-complete-guide-to-useeffect/
Because hooks 67,48,47, and 51 changed. Edit: Sorry, because the parent component re-rendered too. Except it didn't. But maybe? Nah, it didn't. Did it? A lot of people are going to think this is being ridiculous, but there were actually bugs as recently as a few months ago(maybe still?) in the dev tools where they would not know the actual re-render reason and it would spit out a generic "parent component re-rendered…
If you don’t mind a slight tangent, where would you start today to learn front end development with React such that you learn this sort of thing as you go?
I can recommend React with Mosh: https://codewithmosh.com/p/mastering-react I completed it and together with the react official documentation (particularly on hooks and newer react 18 features) have learnt enough to build a good interactive application. Building the app immediately after has taught me much more. You can try patching free tutorials together but given the salary paid to good developers, paying for good…