-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add experimental electron support #152
Merged
Merged
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
gabrieldonadel
commented
Jan 26, 2024
@@ -60,4 +60,4 @@ program | |||
if (process.argv.length < 3) { | |||
program.help(); | |||
} | |||
program.parse(); | |||
program.parse(process.argv); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We must explicitly provide process.argv
to ensure CommandsJS process arguments correctly when running the CLI from electron
gabrieldonadel
force-pushed
the
@gabrieldonadel/electron
branch
2 times, most recently
from
January 29, 2024 12:13
480ca9c
to
8ce0ed0
Compare
gabrieldonadel
force-pushed
the
@gabrieldonadel/electron
branch
2 times, most recently
from
January 31, 2024 00:20
3e6a631
to
9ab932d
Compare
gabrieldonadel
force-pushed
the
@gabrieldonadel/electron
branch
from
January 31, 2024 03:31
9ab932d
to
c4e60de
Compare
gabrieldonadel
changed the title
[WIP] Add experimental electron support
[menu-bar] Add experimental electron support
Jan 31, 2024
gabrieldonadel
changed the title
[menu-bar] Add experimental electron support
Add experimental electron support
Jan 31, 2024
alanjhughes
approved these changes
Jan 31, 2024
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.
Why
We want to expand Orbit's support for more platforms, focusing primarily on Windows given that it is the platform that most users use to access the Expo website.
Options:
1. react-native-windows
The first choice that comes to mind is react-native-windows, considering that we have already implemented everything using react-native-macos and we know the strength of react native when it comes to shipping an app that feels native.
We did some proof of concepts using react-native-windows, but in its current form, a standard react-native-windows app has too many limitations for our use case.
By default, react-native-windows generates Universal Windows Platform (UWP) apps which have quite a few limitations regarding accessing specific Windows APIs as they run as sandbox apps, which would be a problem for Orbit.
Orbit needs to perform tasks that are only supported by the Win32 ecosystem such as: working with any file on the disk without user intervention, reading keys from the registry, and using the system tray API. The
react-native-windows init
command used to support a flag to target WinUI 3 (through the Windows App SDK instead of UWP XAML) but this flag was deprecated in favor of ongoing Fabric implementation for react-native-windows and no longer works.Although win32 applications will be the default for Fabric, unfortunately it is still a ways off from being complete enough for most apps. Considering this, plus the fact that at this point in time, there isn't an official template for creating a win32 application, react-native-windows wouldn't really fit our needs.
2. electron
The second obvious option would be using electron, as it has gained widespread adoption in the software industry as "the" framework for building cross-platform desktop applications, and a lot of big desktop apps like Slack, Visual Studio Code, Linear and Discord use it.
Taking into account the fact that Expo already has great support for web, with electron we can just export Orbit using react-native-web and load it using electron, this would not only add support for Windows but also for Linux ("for free")
Electron comes with full support for things such as the tray API and as it essentially runs a nodejs process we can directly invoke the CLI without having to rely on pkg to create a single executable application.
Given all these facts it was opted to use electron.
How
This PR is the first of a series of PRs adding support for electron and it implements the most basic functionalities to get orbit running, which includes:
electron
folder under menu-barnpm init electron-app@latest my-app -- --template=vite-typescript
to set up the basic templatereact-native-electron-modules
packageregisterMainModules
andexposeElectronModules
Test Plan
npx expo start
apps/menu-bar/electron
and runyarn start
On Windows:
And we can also use macOS for debugging: