Commit Graph

4 Commits

Author SHA1 Message Date
Sebastian Markbåge
c7ba8c0988
Enforce that the "react-server" build of "react" is used (#27436)
I do this by simply renaming the secret export name in the "subset"
bundle and this renamed version is what the FlightServer uses.

This requires us to be more diligent about always using the correct
instance of "react" in our tests so there's a bunch of clean up for
that.
2023-09-29 18:24:05 -04:00
Sebastian Silbermann
3c2341416a
Update jest to v26 (#21574)
* Install jest 26

* jsdom env now uses 16 by default

* require.requireActual -> jest.requireActual

* deduplicate added deps
2021-05-27 16:33:57 +01:00
Ricky
454c2211c0
Refactor SchedulerHostConfigs (#20025)
* Remove SchedulerHostConfigs

* Fix builds

* Fix forks

* Move SchedulerNoDom check to npm/index.js

* Fix tests

* Add @gate source

* Gate build-only test to build test runs
2020-11-02 12:46:58 -05:00
Andrew Clark
00748c53e1
Add new mock build of Scheduler with flush, yield API (#14964)
* Add new mock build of Scheduler with flush, yield API

Test environments need a way to take control of the Scheduler queue and
incrementally flush work. Our current tests accomplish this either using
dynamic injection, or by using Jest's fake timers feature. Both of these
options are fragile and rely too much on implementation details.

In this new approach, we have a separate build of Scheduler that is
specifically designed for test environments. We mock the default
implementation like we would any other module; in our case, via Jest.
This special build has methods like `flushAll` and `yieldValue` that
control when work is flushed. These methods are based on equivalent
methods we've been using to write incremental React tests. Eventually
we may want to migrate the React tests to interact with the mock
Scheduler directly, instead of going through the host config like we
currently do.

For now, I'm using our custom static injection infrastructure to create
the two builds of Scheduler — a default build for DOM (which falls back
to a naive timer based implementation), and the new mock build. I did it
this way because it allows me to share most of the implementation, which
isn't specific to a host environment — e.g. everything related to the
priority queue. It may be better to duplicate the shared code instead,
especially considering that future environments (like React Native) may
have entirely forked implementations. I'd prefer to wait until the
implementation stabilizes before worrying about that, but I'm open to
changing this now if we decide it's important enough.

* Mock Scheduler in bundle tests, too

* Remove special case by making regex more restrictive
2019-02-26 20:51:17 -08:00