With the `react-dom/server-rendering-stub` you can import `react-dom` in
RSC so that you can call `preload` and `preinit` but if you don't alias
it, then requiring it breaks because we React.Component which doesn't
exist in the react subset.
Adds a category of Resources of type `head` which will be used to track
the tags that go into the <head>
Currently only implements for `<title>`.
titles are keyed off their textContent so each time the title changes a
new resource will be created. Currently insertion is done by prepending
in the <head>. The argument here is that the newest title should "win"
if there are multiple rendered. This also helps when a navigation or
update causes a server rendered title to hang around but it is not the
most recent one.
`use` can avoid suspending on already resolved data by yielding to
microtasks. In a real, browser environment, we do this by scheduling a
platform task (i.e. postTask).
In a test environment, tasks are scheduled on a special internal queue
so that they can be flushed by the `act` testing API. So we need to add
support for this in `act`.
This behavior only works if you `await` the thenable returned by the
`act` call. We currently do not require that users do this. So I added a
warning, but it only fires if `use` was called. The old Suspense pattern
will not trigger a warning. This is to avoid breaking existing tests
that use Suspense.
The implementation of `act` has gotten extremely complicated because of
the subtle changes in behavior over the years, and our commitment to
maintaining backwards compatibility. We really should consider being
more restrictive in a future major release.
The changes are a bit confusing so I did my best to add inline comments
explaining how it works.
## Test plan
I ran this against Facebook's internal Jest test suite to confirm
nothing broke
* Add fetch instrumentation in cached contexts
* Avoid unhandled rejection errors for Promises that we intentionally ignore
In the final passes, we ignore the newly generated Promises and use
the previous ones. This ensures that if those generate errors, that we
intentionally ignore those.
* Add extra fetch properties if there were any
* [useEvent] Lint for presence of useEvent functions in dependency lists
With #25473, the identity of useEvent's return value is no longer stable
across renders. Previously, the ExhaustiveDeps lint rule would only
allow the omission of the useEvent function, but you could still add it
as a dependency.
This PR updates the ExhaustiveDeps rule to explicitly check for the
presence of useEvent functions in dependency lists, and emits a warning
and suggestion/autofixer for removing the dependency.
* [useEvent] Non-stable function identity
Since useEvent shouldn't go in the dependency list of whatever is
consuming it (which is enforced by the fact that useEvent functions are
always locally created and never passed by reference), its identity
doesn't matter. Effectively, this PR is a runtime assertion
that you can't rely on the return value of useEvent to be stable.
* Test: Events should see latest bindings
The key feature of useEvent that makes it different from useCallback
is that events always see the latest committed values. There's no such
thing as a "stale" event handler.
* Don't queue a commit effect on mount
* Inline event function wrapping
- Inlines wrapping of the callback
- Use a mutable ref-style object instead of a callable object
- Fix types
Co-authored-by: Andrew Clark <git@andrewclark.io>
* Facebook -> Meta in copyright
rg --files | xargs sed -i 's#Copyright (c) Facebook, Inc. and its affiliates.#Copyright (c) Meta Platforms, Inc. and affiliates.#g'
* Manual tweaks
* Add feature flag for external Fizz runtime
Only enabled for www for now
* Add option to load Fizz runtime from external file
When unstable_externalRuntimeSrc is provided, React will inject a script
tag that points to the provided URL.
Then, instead of emitting inline scripts, the Fizz stream will emit
HTML nodes with data attributes that encode the instructions. The
external runtime will detect these with a mutation observer and
translate them into runtime commands. This part isn't implemented in
this PR, though — all this does is set up the option to use
an external runtime, and inject the script tag.
The external runtime is injected at the same time as bootstrap scripts.
* float enhance!!!
Support preinit as script
Support resources from async scripts
Support saving the precedence place when rendering the shell
There was a significant change to the flushing order of resources which follows the general principal of...
1. stuff that blocks display
2. stuff that we know will be used
3. stuff that was explicitly preloaded
As a consequence if you preinit a style now it won't automatically flush in the shell unless you actually depend on it in your tree. To avoid races with precedence order we now emit a tag that saves the place amongst the precedence hierarchy so late insertions still end up where they were intended
There is also a novel hydration pathway for certain tags. If you render an async script with an onLoad or onError it will always treat it like an insertion rather than a hydration.
* restore preinit style flushing behavior and nits
Fixes a bug that happens when you suspend in the shell (the part of the
tree that is not wrapped in a Suspense boundary) during a
discrete update.
There were two underyling issues. One was just a mistake:
RootDidNotComplete needs to be handled in both renderRootConcurrent and
renderRootSync, but it was only handled in renderRootConcurrent. I did
it this way because I thought this path was unreachable during a sync
update, but I neglected to consider that renderRootSync is sometimes
called for non-concurrent lanes, like when recovering from an error, or
patching up a mutation to an external store.
After I fixed that oversight, the other issue is that we intentionally
error if the shell suspends during a sync update. The idea was that you
should either wrap the tree in a Suspense boundary, or you should mark
the update as a transition to allow React to suspend.
However, this did not take into account selective hydration, which can
force a sync render before anything has even committed. There's no way
in that case to wrap the update in startTransition.
Our solution for now is to remove the error that happens when you
suspend in the shell during a sync update — even for discrete updates.
We will likely revisit this in the future. One appealing possibility is
to commit the whole root in an inert state, as if it were a hidden
Offscreen tree.
Co-authored-by: Sebastian Markbåge <sebastian@calyptus.eu>
Co-authored-by: Sebastian Markbåge <sebastian@calyptus.eu>
* Print built-in specific error message for toJSON
This is a better message for Date.
Also, format the message to highlight the affected prop.
* Describe error messages using JSX elements in DEV
We don't have access to the grand parent objects on the stack so we stash
them on weakmaps so we can access them while printing error messages.
Might be a bit slow.
* Capitalize Server/Client Component
* Special case errror messages for children of host components
These are likely meant to be text content if they're not a supported object.
* Update error messages
The download-build script works by scraping the CircleCI job number from
the GitHub status API. Yes, I know this is super hacky but last I
checked this was the least bad of not a lot of options. Because the
response is paginated, sometimes the status for the build job exceeds
the page size.
This increases the page size to 100 so this is less likely to happen.
It'd be great to find a better way to download the artifacts. I don't
love how brittle this solution is. I think switching to the GitHub
Checks API might be worth trying, but last I looked into it, it has
other flaws.
* Scaffolding for react-dom/unstable_external-server-runtime
Implements a new bundle type for in our build config called
BROWSER_SCRIPT. This is intended for scripts that get delivered straight
to the browser without needing to be processed by a bundler. (And also
doesn't include any extra UMD crap.)
Right now there's only a single use case so I didn't stress about making
it general purpose.
The use case is: a script that loads the Fizz browser runtime, and sets
up a MutationObserver to receive instructions as HTML streams in. This
will be an alternative option to the default Fizz behavior of sending
the runtime down as inline script tags, to accommodate environments
where inline script tags are not allowed.
There's no development version of this bundle because it doesn't contain
any warnings or run any user code.
None of the actual implementation is in this PR; it just sets up the
build infra.
Co-authored-by: Mofei Zhang <feifei0@fb.com>
* Set BUNDLE_SCRIPT's GCC output format to ES5
This removes the automatic 'use strict' directive, which we don't need.
Co-authored-by: Mofei Zhang <feifei0@fb.com>
* Move Fizz inline instructions to unified module
Instead of a separate module per instruction, this exports all of them
from a unified module.
In the next step, I'll add a script to generate this new module.
* Add script to generate inline Fizz runtime
This adds a script to generate the inline Fizz runtime. Previously, the
runtime source was in an inline comment, and a compiled version of the
instructions were hardcoded as strings into the Fizz implementation,
where they are injected into the HTML stream.
I've moved the source for the instructions to a regular JavaScript
module. A script compiles the instructions with Closure, then generates
another module that exports the compiled instructions as strings.
Then the Fizz runtime imports the instructions from the
generated module.
To build the instructions, run:
yarn generate-inline-fizz-runtime
In the next step, I'll add a CI check to verify that the generated files
are up to date.
* Check in CI if generated Fizz runtime is in sync
The generated Fizz runtime is checked into source. In CI, we'll ensure
it stays in sync by running the script and confirming nothing changed.
This is a temporary step until we allow Promises everywhere.
Currently this serializes to a Lazy which can then be consumed in this same
slot by the client.
We're adding an option to Fizz to support an alternate output format
that doesn't rely on inline script tags (see #25437). The two outputs
will share the same "instruction set" of functions. These functions are
currently inlined into the source file; to make this a bit more maintainable,
and eventually have a single source of truth, in preparation for the new option,
this commit moves the instruction set to a separate files that are imported.
In the future, we could improve this further by running Closure on the
instruction set and generating it at build time. This isn't an urgent
improvement, though, because we rarely modify the instruction set.
Co-authored-by: Mofei Zhang <feifei0@fb.com>
Co-authored-by: Mofei Zhang <feifei0@fb.com>
* Missing Hooks
* Remove www forks. These can use __SECRET... instead.
* Move cache to separate dispatcher
These will be available in more contexts than just render.
Publish an aliasable entry for `react-dom` top level package exports for use in server environments. This is a stub containing only the exports that we expect to retain in the top level once 19 is released
In #24967, I changed the behavior of Offscreen so that passive effects
are not fired when the tree is hidden. I accidentally applied this
behavior to the old LegacyHidden API, too, which is a deprecated
internal-only type that www has been using while they wait for Offscreen
to be ready.
This fixes LegacyHidden so that the effects do not get deferred, like
before. The new behavior still remains in the Offscreen API, which is
experimental and not currently in use in www.
* track resources in different roots separately
* flow types
* add test demonstrating portals deep into shadowRoots
* revert hostcontext changes
* lints
* funge style cache key a la ReactDOMComponentTree
* hide hacks in componentTree
* Update safe-string-coercion to handle additions of string literals
Adding strings shouldn't trigger a lint violation of this rule, since
adding strings are always safe.
Sebastian MarkbågeandRick Hanlon
Josh StoryandRick Hanlon
Andrew ClarkandRick Hanlon
laurenandRick Hanlon
Samuel SuslaandRick Hanlon
c0dedanceandRick Hanlon
bubucuoandRick Hanlon
Jan KassensandRick Hanlon
Joseph SavonaandRick Hanlon
Tianyu YaoandRick Hanlon
dependabot[bot]andGitHub
Sebastian SilbermannandGitHub