Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass mutation list to RCTMountingTransactionObserving callbacks #33510

Closed
wants to merge 10 commits into from

Conversation

kmagiera
Copy link
Contributor

Summary

This PR updates RCTMountingTransactionObserving protocol to accept full MountingTransaction object as an argument to its methods as opposed to just MountingTransactionMetdata which contained only some subset of information.

This change makes it possible for components implementing the protocol to analyze the list of mutations and hence only take action when certain mutations are about to happen.

One of the use cases for RCTMountingTransactionObserving protocol is to allow for Modal to take view snapshot before it is closed, such that an animated close transition can be performed over the snapshotted content. Note that when modal is removed from the view hierarchy its children are gone too and therefore the snapshot mechanism makes it possible for children to still be visible while the animated closing transition is ongoing. A similar use-case to that can be seen in react-native-screens library, where we use the same snapshot mechanism for views that are removed from navigation stack.

Before this change, we'd use mountingTransactionDidMountWithMetadata to take a snapshot. However, making a snapshot of relatively complex view hierarchy can be expensive, and we'd like to make sure that we only perform a snapshot when the given modal is about to be removed. Because the mentioned method does not provide an information about what changes are going to be performed in a given transaction, we'd make the snapshot for every single view transaction that happens while the modal is mounted.

In this PR we're updating RCTMountingTransactionObserving protocol's methods, in particular, we rename methods to no longer contain "Metadata" in them and to accept MountingTransaction as the only argument instead of MountingTransactionMetadata object. With this change we are also deleting MountingTransactionMetadata altogether as it has no uses outside the protocol. Finally, we update the two uses of the protocol in RCTScrollViewComponentView and RCTModalHostViewComponentView.

Changelog

[iOS][Fabric] - Update RCTMountingTransactionObserving protocol to consume MountingTransaction objects

Test Plan

As there are not that many uses of RCTMountingTransactionObserving protocol during testing I focused on checking if the updated method is called and if the provided objects contains the proper data. Unfortunately, despite code for the modal protocol being present in OSS version it does seem like some parts of modal implementation are still missing and the component only renders an unimplemented view (checked this with rn-tester). I only managed to verify the use in RCTScrollViewComponentView with the following steps:

  1. Build for iOS
  2. Put a breakpoint in mountingTransactionDidMount method in RCTScrollViewComponentView.mm
  3. Verify that the program stops on the breakpoint when a scrollview is rendered (use any screen on rn-tester app)
  4. Inspect the provided object in the debugger (ensure the list of transactions is not empty)

Outside of that we verified the transactions can be processed in mountingTransactionDidMount after the changes from this PR are applied in FabricExample app in react-native-screens repo.

@facebook-github-bot facebook-github-bot added CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. p: Software Mansion Partner: Software Mansion Partner Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. labels Mar 28, 2022
@pull-bot
Copy link

pull-bot commented Mar 28, 2022

Messages
📖

📋 Verify Changelog Format - A changelog entry has the following format: [CATEGORY] [TYPE] - Message.

CATEGORY may be:
  • General
  • iOS
  • Android
  • JavaScript
  • Internal (for changes that do not need to be called out in the release notes)

TYPE may be:

  • Added, for new features.
  • Changed, for changes in existing functionality.
  • Deprecated, for soon-to-be removed features.
  • Removed, for now removed features.
  • Fixed, for any bug fixes.
  • Security, in case of vulnerabilities.

MESSAGE may answer "what and why" on a feature level. Use this to briefly tell React Native users about notable changes.

Generated by 🚫 dangerJS against f03b034

@analysis-bot
Copy link

analysis-bot commented Mar 28, 2022

Platform Engine Arch Size (bytes) Diff
ios - universal n/a --

Base commit: 6e5cefe
Branch: main

@analysis-bot
Copy link

analysis-bot commented Mar 29, 2022

Platform Engine Arch Size (bytes) Diff
android hermes arm64-v8a 7,765,986 -499
android hermes armeabi-v7a 7,175,065 -341
android hermes x86 8,073,549 -607
android hermes x86_64 8,052,686 -643
android jsc arm64-v8a 9,643,229 -496
android jsc armeabi-v7a 8,417,616 -348
android jsc x86 9,592,307 -599
android jsc x86_64 10,189,448 -651

Base commit: 6e5cefe
Branch: main

Copy link
Contributor

@ShikaSD ShikaSD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good! a few questions to understand the changes better :)

@facebook-github-bot
Copy link
Contributor

@ShikaSD has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

@facebook-github-bot
Copy link
Contributor

@ShikaSD has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

@@ -890,8 +890,8 @@ SPEC CHECKSUMS:
boost: a7c83b31436843459a1961bfd74b96033dc77234
CocoaAsyncSocket: 065fd1e645c7abab64f7a6a2007a48038fdc6a99
DoubleConversion: 5189b271737e1565bdce30deb4a08d647e3f5f54
FBLazyVector: 19e408e76fa9258dd32191a50d60c41444f52d29
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can revert that, CI passes now with the internal cache update :)

telemetry.didMount();

compoundTelemetry.incorporate(telemetry, numberOfMutations);

didMount({surfaceId, number, telemetry, compoundTelemetry});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I started updating internal usages of this method, seems like compoundTelemetry is not available in the transaction .
I am not sure what's the best course of action here, maybe we could pass both transaction and telemetry as separate parameters or rollback deletion of metadata and just have it as a { transaction, compoundTelemetry } type of object?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about passing SurfaceTelemetry as a second argument to all the observer callbacks? For me it'd seem more natural than adding additional struct to carry them both. If you'd prefer to have such struct then I'd consider either naming it differently than "*Metadata" as it'd seem unintuitive that "TransactionMetadata" actually carries "Transaction". Alternatively I can revert "Metadata" to its previous form and add only a reference to "mutations" to it as that's the only thing we need from transaction to fulfil out usecase.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, SurfaceTelemetry as a separate parameter sounds good to me :)

@kmagiera
Copy link
Contributor Author

kmagiera commented Apr 5, 2022

Hi @ShikaSD – I updated observer to pass presenter ref as discussed and also reverted changes to Podfile. The CI failure seem unrelated to this PR.

@facebook-github-bot
Copy link
Contributor

@ShikaSD has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

@react-native-bot
Copy link
Collaborator

This pull request was successfully merged by @kmagiera in 91fc2c0.

When will my fix make it into a release? | Upcoming Releases

@react-native-bot react-native-bot added the Merged This PR has been merged. label Apr 21, 2022
@facebook-github-bot
Copy link
Contributor

This pull request has been reverted by 2f5a1e6.

kmagiera referenced this pull request Apr 22, 2022
…acks"

Summary:
https://fb.workplace.com/groups/fbapp.commerce.engsupport/permalink/2074812256012212/

Back out "[react-native][PR] Pass mutation list to RCTMountingTransactionObserving callbacks"

Original commit changeset: f40afc512f2c

Original Phabricator Diff: D35214478 (91fc2c0)

Changelog: [Internal]

Reviewed By: cipolleschi

Differential Revision: D35825832

fbshipit-source-id: b53b616dca39c84b3a8e8e4cbaa4a45834e53fe3
Saadnajmi pushed a commit to Saadnajmi/react-native-macos that referenced this pull request Jan 15, 2023
…book#33510)

Summary:
This PR updates `RCTMountingTransactionObserving` protocol to accept full `MountingTransaction` object as an argument to its methods as opposed to just `MountingTransactionMetdata` which contained only some subset of information.

This change makes it possible for components implementing the protocol to analyze the list of mutations and hence only take action when certain mutations are about to happen.

One of the use cases for `RCTMountingTransactionObserving` protocol is to allow for Modal to take view snapshot before it is closed, such that an animated close transition can be performed over the snapshotted content. Note that when modal is removed from the view hierarchy its children are gone too and therefore the snapshot mechanism makes it possible for children to still be visible while the animated closing transition is ongoing. A similar use-case to that can be seen in react-native-screens library, where we use the same snapshot mechanism for views that are removed from navigation stack.

Before this change, we'd use `mountingTransactionDidMountWithMetadata` to take a snapshot. However, making a snapshot of relatively complex view hierarchy can be expensive, and we'd like to make sure that we only perform a snapshot when the given modal is about to be removed. Because the mentioned method does not provide an information about what changes are going to be performed in a given transaction, we'd make the snapshot for every single view transaction that happens while the modal is mounted.

In this PR we're updating `RCTMountingTransactionObserving` protocol's methods, in particular, we rename methods to no longer contain "Metadata" in them and to accept `MountingTransaction` as the only argument instead of `MountingTransactionMetadata` object. With this change we are also deleting `MountingTransactionMetadata` altogether as it has no uses outside the protocol. Finally, we update the two uses of the protocol in `RCTScrollViewComponentView` and `RCTModalHostViewComponentView`.

[iOS][Fabric] - Update RCTMountingTransactionObserving protocol to consume MountingTransaction objects

Pull Request resolved: facebook#33510

Test Plan:
As there are not that many uses of `RCTMountingTransactionObserving` protocol during testing I focused on checking if the updated method is called and if the provided objects contains the proper data. Unfortunately, despite code for the modal protocol being present in OSS version it does seem like some parts of modal implementation are still missing and the component only renders an unimplemented view (checked this with rn-tester). I only managed to verify the use in `RCTScrollViewComponentView` with the following steps:
1. Build for iOS
2. Put a breakpoint in mountingTransactionDidMount method in `RCTScrollViewComponentView.mm`
3. Verify that the program stops on the breakpoint when a scrollview is rendered (use any screen on rn-tester app)
4. Inspect the provided object in the debugger (ensure the list of transactions is not empty)

Outside of that we verified the transactions can be processed in `mountingTransactionDidMount` after the changes from this PR are applied in FabricExample app in [react-native-screens](https://github.com/software-mansion/react-native-screens/tree/main/FabricExample) repo.

Reviewed By: cipolleschi

Differential Revision: D35214478

Pulled By: ShikaSD

fbshipit-source-id: f40afc512f2c8cfa6262d2fb82fb1ccb05aa734c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged This PR has been merged. p: Software Mansion Partner: Software Mansion Partner Reverted Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants