Improve spec-compliance of Performance interfaces #45525
Closed
+214
−140
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D59911145 |
|
This pull request was exported from Phabricator. Differential Revision: D59911145 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Jul 18, 2024
Summary: Pull Request resolved: facebook#45525 Changelog: [internal] This makes several changes to the Performance API to align it closer with the spec: * Makes fields of `PerformanceEntry` and subclasses read-only. * Returns instances of the correct subclass of `PerformanceEntry` to observers. * Renames `HighResTimeStamp` as `DOMHighResTimeStamp` for alignment with the spec and native Additionally, I realized that the way we handle `performance.measure` is a bit problematic at the moment. When we call the function, we create a `PerformanceMeasure` instance with the data we receive, and return that value. In parallel, we notify the entry to native, which will in turn notify the observers. But the observers will not get those instances we just created, but new instances of `PerformanceEntry` (not even `PerformanceMeasure`) with the resolved values. At the same time, the `PerformanceMeasure` instance we return doesn't resolve its `startTime` and `duration` based on the indicated marks (when specified as strings). We need to fix this in the future by resolving the timing data synchronously when calling `performance.measure`. Differential Revision: D59911145
rubennorte
force-pushed
the
export-D59911145
branch
from
4ca94fd
to
ec15f03
Compare
|
This pull request was exported from Phabricator. Differential Revision: D59911145 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Jul 19, 2024
Summary: Pull Request resolved: facebook#45525 Changelog: [internal] This makes several changes to the Performance API to align it closer with the spec: * Makes fields of `PerformanceEntry` and subclasses read-only. * Returns instances of the correct subclass of `PerformanceEntry` to observers. * Renames `HighResTimeStamp` as `DOMHighResTimeStamp` for alignment with the spec and native Additionally, I realized that the way we handle `performance.measure` is a bit problematic at the moment. When we call the function, we create a `PerformanceMeasure` instance with the data we receive, and return that value. In parallel, we notify the entry to native, which will in turn notify the observers. But the observers will not get those instances we just created, but new instances of `PerformanceEntry` (not even `PerformanceMeasure`) with the resolved values. At the same time, the `PerformanceMeasure` instance we return doesn't resolve its `startTime` and `duration` based on the indicated marks (when specified as strings). We need to fix this in the future by resolving the timing data synchronously when calling `performance.measure`. Reviewed By: rshest Differential Revision: D59911145
rubennorte
force-pushed
the
export-D59911145
branch
from
ec15f03
to
aeef9aa
Compare
Differential Revision: D59918519
Summary: Pull Request resolved: facebook#45525 Changelog: [internal] This makes several changes to the Performance API to align it closer with the spec: * Makes fields of `PerformanceEntry` and subclasses read-only. * Returns instances of the correct subclass of `PerformanceEntry` to observers. * Renames `HighResTimeStamp` as `DOMHighResTimeStamp` for alignment with the spec and native Additionally, I realized that the way we handle `performance.measure` is a bit problematic at the moment. When we call the function, we create a `PerformanceMeasure` instance with the data we receive, and return that value. In parallel, we notify the entry to native, which will in turn notify the observers. But the observers will not get those instances we just created, but new instances of `PerformanceEntry` (not even `PerformanceMeasure`) with the resolved values. At the same time, the `PerformanceMeasure` instance we return doesn't resolve its `startTime` and `duration` based on the indicated marks (when specified as strings). We need to fix this in the future by resolving the timing data synchronously when calling `performance.measure`. Reviewed By: rshest Differential Revision: D59911145
|
This pull request was exported from Phabricator. Differential Revision: D59911145 |
rubennorte
force-pushed
the
export-D59911145
branch
from
aeef9aa
to
c754e21
Compare
|
This pull request has been merged in 2a91a70. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Changelog: [internal]
This makes several changes to the Performance API to align it closer with the spec:
PerformanceEntryand subclasses read-only.PerformanceEntryto observers.HighResTimeStampasDOMHighResTimeStampfor alignment with the spec and nativeAdditionally, I realized that the way we handle
performance.measureis a bit problematic at the moment. When we call the function, we create aPerformanceMeasureinstance with the data we receive, and return that value. In parallel, we notify the entry to native, which will in turn notify the observers. But the observers will not get those instances we just created, but new instances ofPerformanceEntry(not evenPerformanceMeasure) with the resolved values. At the same time, thePerformanceMeasureinstance we return doesn't resolve itsstartTimeanddurationbased on the indicated marks (when specified as strings). We need to fix this in the future by resolving the timing data synchronously when callingperformance.measure.Differential Revision: D59911145