Comments (6)
I'd love to see this myself. There's actually a couple very relevant PRs here:
But the comment on that by Joe was somewhat discouraging:
We discussed this as a team a while back, and we are very concerned about the cost of supporting this long-term. Although the intent would be just for non-critical (to application correctness) things like performance monitoring, itโs inevitable that applications or libraries would end up relying on these hooks for their core behavior. That would slow us down since it would make many more internal refactors into breaking changes, delaying those refactors and the improvements they would unlock.
We think the right first step is the transition tracing api that weโve discussed before in labs posts. In our backlog.
from react.
Yeah, this is definitely not something that should hold React back. If things change, they change. This would just surface it.
The idea is more to ensure that if a new React version is released and one of our apis unexpectedly starts seeing additional renders, we can catch and fix that sooner rather than later.
It's definitely only targeted for a "testing" use case - which is also why I suggest something like a react-dom/test
entrypoint.
from react.
Have you explored wrapping your tests in React.Profiler
and asserting on the render callbacks? I explored that originaly in MUI. The idea was that we wrap every test in React.Profiler
and track changes. It seemed promising but I didn't finish it with tracking numbers in a useful way (p90, diffs between commits, measurements over time etc).
You may want to check out if you get more accurate real world results by not using act
in these tests.
Transition tracing would help for more detailed insights. Though maybe we can just expose the updater tracking React Devtools has already access to ("Why did this render?" in the Profiler panel).
from react.
Have you explored wrapping your tests in React.Profiler and asserting on the render callbacks?
We kinda do - we wrap the tests in React.Profiler
, and on every onRender
callback, we create snapshots of the DOM and additional test-specific additional values (hook return values etc.).
We just don't immediately make assertions, but we save these values to the side, to make assertions on them at another time.
You may want to check out if you get more accurate real world results by not using act in these tests.
Now I'm intrigued - isn't the advice to use act to get more real world results?
Though maybe we can just expose the updater tracking React Devtools has already access to
Yes, please, let's start small - perfect is the enemy of "at all", and there is a ton of data currently available to the DevTools that we cannot access from tests right now. Getting access to these would already be incredible, we don't need anything beyond that right now!
from react.
We kinda do - we wrap the tests in React.Profiler, and on every onRender callback, we create snapshots of the DOM and additional test-specific additional values (hook return values etc.).
We just don't immediately make assertions, but we save these values to the side, to make assertions on them at another time.
So you're not actually interested in profiling but making more granular assertions. I think you just want to test without act
to assert on the intermediated steps not profiling tools.
Now I'm intrigued - isn't the advice to use act to get more real world results?
act()
flushes everything scheduled before it exits. That's not necessarily what you'll see in real world applications e.g. React receives mousemove
events it may batch the state updates into a single commit. If you wrap both in act
, you'll always get two commits.
Yes, please, let's start small - perfect is the enemy of "at all", and there is a ton of data currently available to the DevTools that we cannot access from tests right now. Getting access to these would already be incredible, we don't need anything beyond that right now!
Except these have holes and bugs at the moment. Transition tracing is still in progress so we shouldn't just expose updater tracking just that we have something. There is a cost to shipping unfinished things at React's scale. If it doesn't work out, there's a lot of work required to remove it holding back the ecosystem. This works in internal repos like at Meta since you have direct access but doesn't scale to the ecosystem with unknown priorities and motivations.
from react.
act() flushes everything scheduled before it exits. That's not necessarily what you'll see in real world applications e.g. React receives mousemove events it may batch the state updates into a single commit. If you wrap both in act, you'll always get two commits.
This is definitely useful information on act
that I had not seen communicated anywhere else - thank you for that.
So you're not actually interested in profiling but making more granular assertions. I think you just want to test without act to assert on the intermediated steps not profiling tools.
There are some "profiler-ish" things that we are definitely interested in, like which components actually committed between two successful renders, and the exact moment a render is done committing (testing-library's waitFor
always has the risk of "skipping" over a render).
Maybe we don't need a full new api, though - after giving this more thought, getting some additional information in the onRender callback would probably be a more fitting place for this.
Except these have holes and bugs at the moment. Transition tracing is still in progress so we shouldn't just expose updater tracking just that we have something. There is a cost to shipping unfinished things at React's scale. If it doesn't work out, there's a lot of work required to remove it holding back the ecosystem. This works in internal repos like at Meta since you have direct access but doesn't scale to the ecosystem with unknown priorities and motivations.
Looking at the TypeScript types, it seems like there was a lot of additional information (interactions
) available at some point in the past that has been removed again - maybe for something like Profiler
it's actually not as bad?
But of course, I understand if you need more time to stabilize things here - but I would be very happy if the team could consider this feature request on a long-term basis.
from react.
Related Issues (20)
- React[19] Module '"react"' has no exported member 'useActionState'. HOT 2
- Bug: effect runs with stale state values outside of Concurrent React HOT 1
- Feature Request: ESLint hooks rule for accessing previous state when deriving new state
- Bug: Weird Behavior of useCallback() hook When Variables or States Are defined before and after the Callback (ES5) HOT 5
- Bug: div: `ref` is not a prop HOT 2
- Bug: useFormStatus pending state is reset when component state is updated HOT 5
- [React 19] TEST HOT 1
- `FALLBACK_THROTTLE_MS` slows tests down significantly - could it be configurable? HOT 4
- Unexpected state behavior when updating nested state objects HOT 5
- Make pre-release version naming align with semver 2 HOT 5
- [React 19] Omit the false value for custom element is an incorrect behaviour HOT 7
- Remove references to legacy class-based component architecture in error messages HOT 3
- Bug: deleting structure via DOM API breaks state updates
- Module '"react"' has no exported member 'use' HOT 2
- Bug: Unexpected characters appear in the Chinese encoding during streaming HOT 4
- Bug: useState, state does not update inside websocket.onmessage rather the state value is preserved untill the next render HOT 2
- Bug: When input type=number, input 1-1 cannot trigger an onchange and cannot be set to an empty string HOT 2
- TestUtils.Simulate alternatives
- use hook issue HOT 8
- [Compiler Bug]: eslint-plugin-react-compiler reports "Hooks may not be referenced as normal values" if property begins "use" HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from react.