Files
react/compiler
Joe Savona d5c3fb87e6 HIR-based reactive identifier analysis
See context from #2187 for background about control dependencies. 

Our current `PruneNonReactiveIdentifiers` pass runs on ReactiveFunction, after 
scope construction, and removes scope dependencies that aren't reactive. It 
works by first building up a set of reactive identifiers in 
`InferReactiveIdentifiers`, then walking the ReactiveFunction and pruning any 
scope dependencies that aren't in that set. 

The challenge is control variables, as demonstrated by the test cases in #2184. 
`InferReactiveIdentifiers` runs against ReactiveFunction, and when we initially 
wrote it we didn't consider control variables. To handle control variables we 
really need to use precise control- & data-flow analysis, which is much easier 
with HIR. 

This PR adds the start of `InferReactivePlaces`, which annotates each `Place` 
with whether it is reactive or not. This allows the annotation to survive 
LeaveSSA, which swaps out the identifiers of places but leaves other properties 
as-is. This version does _not_ yet handle control variables, but it's already 
more precise than our existing inference. In our current inference, if `x` is 
ever assigned a reactive value, then all `x`s are marked reactive. In our new 
inference, each instance of `x` (each Place) gets a separate flag based on 
whether x can actually be reactive at that point in the program. 

There are two main next steps (in follow-up PRs): 

* Update the mechanism by which we prune non-reactive dependencies from scopes. 

* Handle control variables. I think we may be able to use dominator trees to 
figure out the set of basic blocks whose reachability is gated by the control 
variables. This should clearly work for if/else and switch, as for loops i'm not 
sure but intuitively it seems right.
2023-11-01 17:13:02 -07:00
..
2024-03-25 10:39:47 +00:00
2023-08-22 15:07:46 -04:00
2024-03-25 10:39:47 +00:00
2024-03-25 10:39:47 +00:00
2024-03-25 10:39:47 +00:00

React Forget

React Forget is an experimental Babel plugin to automatically memoize React Hooks and Components.

Development

# tsc --watch
$ yarn dev

# in another terminal window
$ yarn test --watch

Notes

An overview of the implementation can be found in the Architecture Overview.

This transform

Scaffolding

Reference

Rust Development

First-Time Setup

  1. Install Rust using rustup. See the guide at https://www.rust-lang.org/tools/install.
  2. Install Visual Studio Code from https://code.visualstudio.com/. Note to Meta employees: install the stock version from that website, not the pre-installed version.
  3. Install the Rust Analyzer VSCode extension through the VSCode marketplace. See instructions at https://rust-analyzer.github.io/manual.html#vs-code.
  4. Install cargo edit which extends cargo with commands to manage dependencies. See https://github.com/killercup/cargo-edit#installation
  5. Install cargo insta which extens cargo with a command to manage snapshots. See https://insta.rs/docs/cli/

Workspace Hygiene

Adding Dependencies

To add a dependency, add it to the top-level Cargo.toml

// Cargo.toml
[workspace.dependencies]
...
new_dep = { version = "x.y.z" }
...

Then reference it from your crate as follows:

// crates/forget_foo/Cargo.toml
[dependencies]
...
new_dep = { workspace = true }
...

Adding new crates

Rust's compilation strategy is largely based on parallelizing at the granularity of crates, so builds can be faster when projects have more but smaller crates. Where possible it helps to structure crates to minimize dependencies. For example, our various compiler passes depend on each other in the sense that they often must run in a certain order. However, they often don't need to call each other, so they can generally be split into crates of similar types of passes, so that those crates can compile in parallel.

As a rule of thumb, add crates at roughly the granularity of our existing top-level folds. If you have some one-off utility code that doesn't fit neatly in a crate, add it to forget_utils rather than add a one-off crate for it.

Running Tests

Run all tests with the following from the root directory:

cargo test

The majority of our tests will (should) live in the forget_fixtures crate, which is a test-only crate that runs compilation end-to-end with snapshot tests. To run just these tests use:

# quiet version
cargo test -p forget_fixtures

# without suppressing stdout/stderr output
cargo test -p forget_fixtures -- --nocapture

Another hint is that VSCode will show a "Run test" option if you hover over a test in the source code, this lets you run a single test easily. The command line will also give you the CLI command to run just that one test.

Updating Snapshots

The above tests make frequent use of snapshot tests. If snapshots do not match the tests will fail with a diff, if the new output is correct you can accept the changes with:

cargo insta accept

If this command fails, see the note in "first-time setup" about installing cargo insta.

CI Configuration

GitHub CI is configured in .github/workflows/rust.yml.