Joe Savona fa8f47eb41 InferReactivePlaces understands setState type ...

I realized this while working on Forest. When computing the dependencies of a 
reactive scope we can omit setState functions in the general case (exception 
described below). Currently that's implemented in PruneNonReactiveDependencies. 
However, this causes us to miss some optimizations — a value isn't reactive if 
its only dependency is a setState, and that may allow further downstreams values 
to become non-reactive. We lose out on that by only filtering out setStates in 
PruneNonReactiveDependencies — this logic really belongs in InferReactivePlaces. 

So this PR moves the check for setState types to that pass. The updated fixtures 
show that this already uncovers some wins. The _new_ fixtures covers the 
exception. It's possible for a value to be typed as being a setState function, 
but to still be reactive: if its a local that is conditionally assigned 
different setState function values. Currently this test happens to work because 
our phi type inference is incomplete (see #2296). I'm adding the test now though 
to prevent regressions when we fix phi type inference.

2023-12-11 11:34:24 -08:00

compiler

InferReactivePlaces understands setState type

2023-12-11 11:34:24 -08:00

S

Description

No description provided

declarativefrontendjavascriptlibraryreactui

MIT 1.8 GiB

Languages

JavaScript 67.1%

TypeScript 29.4%

HTML 1.5%

CSS 1.1%

C++ 0.6%

Other 0.2%