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

Bring back ability to reveal preview when stuck on waiting #696

Merged
merged 3 commits into from
Nov 6, 2024

Conversation

kmagiera
Copy link
Member

@kmagiera kmagiera commented Nov 5, 2024

In #475 we accidently broke the functionality that'd allow users to tap on "waiting for app to load" text in order to reveal the device preview.

This option was pretty handy specifically to troubleshoot issues when app gets stuck because of expo devclient onboarding dialog.

This PR brings back the callback-based code that got removed in #475 with small adjustments as the underlying implementation from deviceSession got split into two separate methods in the meantime.

How Has This Been Tested:

  1. Run expo dev client 51
  2. Use "reinstall app" option, the app would get stuck on the waiting to load screen
  3. Click on the "waiting to load" text to reveal preview – after this change you should be able to see the preview, without this change the button would do nothing as the frontend code doesn't have access to the preview URL until the app is fully launched.

Copy link

vercel bot commented Nov 5, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
radon-ide ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 5, 2024 11:28pm

Copy link
Contributor

@balins balins 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!

Comment on lines +601 to 604
this.updateProjectStateForDevice(deviceInfo, { previewURL: url });
},
});
this.updateProjectStateForDevice(this.projectState.selectedDevice!, {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is called twice with previewURL, some explanation why is that could be useful here (I assume that ideally, the second call would just set the status to "running", since the previewURL has been already set at this point but I don't know the codebase).

Copy link
Contributor

Choose a reason for hiding this comment

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

+1, couldn't the second one update only "status"? then the previewURL local variable is redundant too

Copy link
Member Author

Choose a reason for hiding this comment

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

The second call doesn't change anything, but relying on the fact this callback gets called every time and it gets called before the method exists is a hidden assumption I'd prefer to avoid for the cost of updating the URL twice

@kmagiera kmagiera merged commit eb727f6 into main Nov 6, 2024
4 checks passed
@kmagiera kmagiera deleted the kmagiera/show-preview-on-wait-press branch November 6, 2024 13:22
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.

3 participants