Twitter | Search | |
Dan Abramov
Working on . I explain with words and code.
62,827
Tweets
890
Following
186,633
Followers
Tweets
Dan Abramov retweeted
Nicolas Apr 22
I joined the React core team recently. Feeling lucky to be part of this inspiring team and the rest of the React group.
Reply Retweet Like
Dan Abramov 7h
Hope this helps. It’s in the FAQ btw.
Reply Retweet Like
Dan Abramov 7h
In the case when you absolutely need to avoid re-rendering due to that prop, and when you’re sure that component below doesn’t need to be notified of changes — you can useRef to emulate the mutable `this` in a class.
Reply Retweet Like
Dan Abramov 7h
With Hooks, the idiomatic solution is useCallback that specifies which props you depend on: . Yes, it will pass a different function down if that prop changes. That’s expected and what you usually need because it lets component react to that change.
Reply Retweet Like
Dan Abramov 7h
Here is another post on this that explains why the behavior you want often creates problems in real apps:
Reply Retweet Like
Dan Abramov 7h
Right, this is because in a class `this` is a mutable indirection that lets you “read the latest value”. However, relying on this means you can’t track its changes in componentDidUpdate (or useEffect with Hooks). The link above explains that exact problem.
Reply Retweet Like
Dan Abramov 8h
Oh I missed the {} argument
Reply Retweet Like
Dan Abramov retweeted
React Native EU 9h
Big applause for - our next speaker! 🎉🥳 In her talk, we'll take a look at what a re-imagined React Native might look like without the legacy, asynchronous communication layer known as “the bridge” 🧐🔯 Get your ticket here:
Reply Retweet Like
Dan Abramov 8h
Replying to @onlylovesnow14
We will adjust heuristics according to research but for now, the default is set to ~150ms — and then we show a loading indicator. Then we’ll offer an opt-in way to wait longer if you provide some other visual indication, like dimming out the “old” version.
Reply Retweet Like
Dan Abramov 9h
Replying to @albertgao
It will start rendering “in memory” — if the data isn’t ready, for the first ~150ms React won’t show any changes. After ~150ms people need visual feedback. At that point React will show a loading indicator where you specify.
Reply Retweet Like
Dan Abramov 9h
Can you be more specific as to why that’s a problem to you? useCallback should be sufficient, and you need to specify which props it depends on. It *is* desirable that it will create a new instance when related props update. Here’s why:
Reply Retweet Like
Dan Abramov retweeted
Ana Cidre Apr 18
Hi community!! Who should I be following?!!! 😊
Reply Retweet Like
Dan Abramov 10h
Replying to @dan_abramov
Thanks everyone!
Reply Retweet Like
Dan Abramov 10h
Replying to @sag1v
Yes!
Reply Retweet Like
Dan Abramov 10h
Replying to @davidwandar
There’s an actual recorded video like this
Reply Retweet Like
Dan Abramov 10h
Replying to @JamesLMilner
Similar in spirit but an actual video
Reply Retweet Like
Dan Abramov 10h
I don’t think this forceUpdate works in stable. Because same state bails out. useReducer(x => c + 1, 0) would work though. Although probably easier to set real state?
Reply Retweet Like
Dan Abramov 10h
Help me find a video where two people drink water in convoluted ways as a metaphor for UX testing
Reply Retweet Like
Dan Abramov 10h
Replying to @VirgoButGemini
requestAnimationFrame
Reply Retweet Like
Dan Abramov 11h
Replying to @onlylovesnow14
We know when data is ready because a Promise resolves. If it is taking too long then React could show a loading indicator that you provide. That’s the part React can manage for you.
Reply Retweet Like