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

feat(iOS): support bridgeless mode. #4681

Merged
merged 78 commits into from
Feb 16, 2025
Merged

feat(iOS): support bridgeless mode. #4681

merged 78 commits into from
Feb 16, 2025

Conversation

asafkorem
Copy link
Contributor

No description provided.

@asafkorem asafkorem force-pushed the feat/bridgeless-mode branch 2 times, most recently from dc250b6 to 0197120 Compare January 13, 2025 16:22
Fabric flattens the view hierarchy if the elements are not accessible.
Callstack's slider view has a property called 'slider' in new arch (RCTViewComponentView),
 which is the actual slider. See -
https://github.com/callstack/react-native-slider/blob/main/package/ios/RNCSliderComponentView.mm#L26
JSI timers are not being synced on new arch (iOS) since we cannot swizzle them.
@asafkorem asafkorem force-pushed the feat/bridgeless-mode branch from fea3349 to 915275c Compare February 1, 2025 16:42
@asafkorem asafkorem marked this pull request as ready for review February 15, 2025 15:52
@asafkorem asafkorem force-pushed the feat/bridgeless-mode branch from 98fb331 to ec530a8 Compare February 15, 2025 17:17
@asafkorem asafkorem merged commit b872570 into master Feb 16, 2025
2 of 3 checks passed
@asafkorem asafkorem deleted the feat/bridgeless-mode branch February 16, 2025 11:05
@d4vidi d4vidi self-assigned this Feb 16, 2025
@@ -2,9 +2,9 @@ describe(":ios: Background-Foreground Transitions", () => {
it("Backgrounding and foregrounding an app should wait for transition to finish", async () => {
await device.launchApp({newInstance: true});
await device.sendToHome();
await expect(element(by.text("Background"))).toBeVisible();
await expect(element(by.text("Background"))).toExist();
Copy link
Collaborator

Choose a reason for hiding this comment

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

@asafkorem why?

Copy link
Contributor Author

@asafkorem asafkorem Feb 18, 2025

Choose a reason for hiding this comment

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

It's a new native component (replaced the previous one), and when the app is on background this element is really not expected to be visible (only to exist).
Note that only the Active message should be visible because the app is visible. i.e.

await expect(element(by.text("Active"))).toBeVisible();

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's a bug that the previous message was considered as "visible" while the app was in the background. It's because that "AnnoyingWindow" we used to have - no longer exists.

@@ -51,8 +53,10 @@ describe('Crash Handling', () => {

if (device.getPlatform() === 'android') {
jestExpect(error.stack).toContain('\tat java.lang.Thread.run');
} else {
} else if (!isRNNewArch) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

@asafkorem I think we need to revisit and decide:

  1. The test is @legacy so I think iSRNNewArch is always false (?)
  2. Should we backlog a tech debt?

Copy link
Contributor Author

@asafkorem asafkorem Feb 18, 2025

Choose a reason for hiding this comment

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

True, we can remove the isRNNewArch. Detox sometimes consider the app as launched before the error is thrown, so we'll have an error on the next action

Copy link
Contributor Author

@asafkorem asafkorem Feb 18, 2025

Choose a reason for hiding this comment

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

It's a technical debt or at least a discussion - whether it's a bug or feature. It's a non-deterministic behaviour because sometimes detox catches the error on-launch and sometimes it will be thrown in the next action (post-launch).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@@ -1,4 +1,4 @@
describe.skipIfNewArchOnIOS(":ios: Picker", () => {
describe(":ios: Picker", () => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

amaze

Copy link
Contributor Author

Choose a reason for hiding this comment

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

❤️

@@ -9,7 +9,7 @@ describe('React-Native Animations', () => {
let loopSwitch = element(by.id('UniqueId_AnimationsScreen_enableLoop'));
await loopSwitch.tap();
if (device.getPlatform() === 'ios') {
await expect(loopSwitch).toHaveValue('1');
await expect(loopSwitch).toHaveToggleValue('1');
Copy link
Collaborator

@d4vidi d4vidi Feb 17, 2025

Choose a reason for hiding this comment

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

I think we should add a warning whenever .toHaveValue() is used over a UISwitch. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe, not sure, we can talk about that. AFAIK we never did it with other components (CMIIW)
It's a specific component behaviour that was changed over RN versions.. 🤷🏼‍♂️
It was really the accessibility value of the original component before

@@ -22,7 +22,8 @@ describe('Network Synchronization', () => {
await driver.shortRequest.expectReplied();
});

it('Sync with long network requests - 3000ms', async () => {
// todo(new-arch): test is failing
it('@legacy Sync with long network requests - 3000ms', async () => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

@asafkorem this looks serious, what's the gap here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants