Sathya
@gsathya.bsky.social
react at meta
formerly: v8/chrome at google
🌐 recompiled.dev
formerly: v8/chrome at google
🌐 recompiled.dev
ugh so sorry to hear that :(
December 9, 2024 at 3:43 AM
ugh so sorry to hear that :(
yeah _pure_ isn't correct, it's more about the captured context -- the compiler moves functions that don't capture any values created in render
December 7, 2024 at 4:03 PM
yeah _pure_ isn't correct, it's more about the captured context -- the compiler moves functions that don't capture any values created in render
so bummed that they've stopped archiving now :(
November 22, 2024 at 2:22 PM
so bummed that they've stopped archiving now :(
it's too early to share anything concrete as everything could change, but we're thinking deeply about effects!
November 22, 2024 at 2:07 PM
it's too early to share anything concrete as everything could change, but we're thinking deeply about effects!
no you should write it! I always learn something new from your posts
November 22, 2024 at 2:07 PM
no you should write it! I always learn something new from your posts
i agree! we're already working on something to make this easier ;)
November 22, 2024 at 1:04 PM
i agree! we're already working on something to make this easier ;)
yes that'd be awesome! :)
November 22, 2024 at 12:58 PM
yes that'd be awesome! :)
in the long term, we want to move away from manual memoization in react and would like to remove these APIs
November 22, 2024 at 12:46 PM
in the long term, we want to move away from manual memoization in react and would like to remove these APIs
this is why the compiler currently bails out on compiling a component if it's newly compiled memoization is different from the existing manual memoization
so we want folks to just use memo for optimization and then just remove all manual memo after adding the compiler
so we want folks to just use memo for optimization and then just remove all manual memo after adding the compiler
November 22, 2024 at 12:46 PM
this is why the compiler currently bails out on compiling a component if it's newly compiled memoization is different from the existing manual memoization
so we want folks to just use memo for optimization and then just remove all manual memo after adding the compiler
so we want folks to just use memo for optimization and then just remove all manual memo after adding the compiler
best case you delete all manual memo and it just works with the compiler because the compiler memoizes everything in the same way
but the compiler could've memoized this callback differently because of heuristics, so it may not be safe to remove this particular useCallback
but the compiler could've memoized this callback differently because of heuristics, so it may not be safe to remove this particular useCallback
November 22, 2024 at 12:46 PM
best case you delete all manual memo and it just works with the compiler because the compiler memoizes everything in the same way
but the compiler could've memoized this callback differently because of heuristics, so it may not be safe to remove this particular useCallback
but the compiler could've memoized this callback differently because of heuristics, so it may not be safe to remove this particular useCallback
Imagine you're adopting the compiler and the compiler works great on your app and you ship it. Now you want to delete the useMemo/useCallback from your code to improve dx. How do you know which ones are safe to remove?
November 22, 2024 at 12:46 PM
Imagine you're adopting the compiler and the compiler works great on your app and you ship it. Now you want to delete the useMemo/useCallback from your code to improve dx. How do you know which ones are safe to remove?
you're right that the callback won't be thrown away but using memoization for correctness can cause downstream issues
November 22, 2024 at 12:46 PM
you're right that the callback won't be thrown away but using memoization for correctness can cause downstream issues
I'd store the id in a ref and check that manually and not depend on useCallback:
```
const idRef = useRef(null);
const scroller = (node) => {
if (idRef.current === null || idRef.current !== id) {
node?.scrollIntoView({ behavior: "smooth" });
idRef.current = id;
}
};
```
```
const idRef = useRef(null);
const scroller = (node) => {
if (idRef.current === null || idRef.current !== id) {
node?.scrollIntoView({ behavior: "smooth" });
idRef.current = id;
}
};
```
November 22, 2024 at 12:46 PM
I'd store the id in a ref and check that manually and not depend on useCallback:
```
const idRef = useRef(null);
const scroller = (node) => {
if (idRef.current === null || idRef.current !== id) {
node?.scrollIntoView({ behavior: "smooth" });
idRef.current = id;
}
};
```
```
const idRef = useRef(null);
const scroller = (node) => {
if (idRef.current === null || idRef.current !== id) {
node?.scrollIntoView({ behavior: "smooth" });
idRef.current = id;
}
};
```