-
Notifications
You must be signed in to change notification settings - Fork 49.8k
[compiler] Don't validate when effect cleanup function depends on effect localized setState state derived values #35020
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…d instead update typeOfValue and fix infinite loops
Summary:
With this we are now comparing a snapshot of the derivationCache with the new changes every time we are done recording the derivations happening in the HIR.
We have to do this after recording everything since we still do some mutations on the cache when recording mutations.
Test Plan:
Test the following in playground:
```
// @validateNoDerivedComputationsInEffects_exp
function Component({ value }) {
const [checked, setChecked] = useState('');
useEffect(() => {
setChecked(value === '' ? [] : value.split(','));
}, [value]);
return (
<div>{checked}</div>
)
}
```
This no longer causes an infinite loop.
Added a test case in the next PR in the stack
6119390 to
6791143
Compare
b421099 to
e900a9d
Compare
…or for `no-deriving-state-in-effects` Summary: Revamped the derivationCache graph. This fixes a bunch of bugs where sometimes we fail to track from which props/state we derived values from. Also, it is more intuitive and allows us to easily implement a Data Flow Tree. We can print this tree which gives insight on how the data is derived and should facilitate error resolution in complicated components Test Plan: Added a test case where we were failing to track derivations. Also updated the test cases with the new error containing the data flow tree
…he error instead of throwing Summary: TSIA Simple change to log errors in Pipeline.ts instead of throwing in the validation Test Plan: updated snap tests
…entifier names Summary: This makes the setState usage logic much more robust. We no longer rely on identifierName. Now we track when a setState is loaded into a new promoted identifier variable and track this in a map `setStateLoaded` map. For other types of instructions we consider the setState to be being used. In this case we record its usage into the `setStateUsages` map. Test Plan: We expect no changes in behavior for the current tests
db9b410 to
b2f2b26
Compare
…ect localized setState state derived values Summary: If we are using a clean up function in an effect and that clean up function depends on a value that is used to set the state we are validating for we shouldn't throw an error since it is a valid use case for an effect. Test Plan: added test
| return result; | ||
| } | ||
|
|
||
| function getFnGlobalDeps( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small nit -- this should be LocalDeps right?
| deps: Set<IdentifierId>, | ||
| ): void { | ||
| if (!fn) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small nit: could return Array<IdentifierId> and merge at caller, or make it more obvious you're writing to deps
Summary:
If we are using a clean up function in an effect and that clean up function depends on a value that is used to set the state we are validating for we shouldn't throw an error since it is a valid use case for an effect.
Test Plan:
added test
Stack created with Sapling. Best reviewed with ReviewStack.
no-deriving-state-in-effects#34995