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

Add experimental electron support #152

Merged
merged 17 commits into from Jan 31, 2024
Merged

Conversation

gabrieldonadel
Copy link
Member

@gabrieldonadel gabrieldonadel commented Jan 26, 2024

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:

  • Add electron folder under menu-bar
    • Used npm init electron-app@latest my-app -- --template=vite-typescript to set up the basic template
  • Add new react-native-electron-modules package
    • This works as an abstraction layer between react-native and electron. Modules just need to be registered and exposed through registerMainModules and exposeElectronModules
  • Implement electron alternatives for the following react-native modules
    • DeviceEventEmitter
    • Linking
  • Add electron support for MenuBar module

Test Plan

  • Start a development server by running npx expo start
  • Navigate to apps/menu-bar/electron and run yarn start

On Windows:

image

And we can also use macOS for debugging:

image

@@ -60,4 +60,4 @@ program
if (process.argv.length < 3) {
program.help();
}
program.parse();
program.parse(process.argv);
Copy link
Member Author

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 gabrieldonadel force-pushed the @gabrieldonadel/electron branch 2 times, most recently from 480ca9c to 8ce0ed0 Compare January 29, 2024 12:13
@gabrieldonadel gabrieldonadel force-pushed the @gabrieldonadel/electron branch 2 times, most recently from 3e6a631 to 9ab932d Compare January 31, 2024 00:20
@gabrieldonadel gabrieldonadel changed the title [WIP] Add experimental electron support [menu-bar] Add experimental electron support Jan 31, 2024
@gabrieldonadel gabrieldonadel changed the title [menu-bar] Add experimental electron support Add experimental electron support Jan 31, 2024
@gabrieldonadel gabrieldonadel marked this pull request as ready for review January 31, 2024 18:56
@gabrieldonadel gabrieldonadel merged commit 8ecd9af into main Jan 31, 2024
1 check passed
@gabrieldonadel gabrieldonadel deleted the @gabrieldonadel/electron branch January 31, 2024 23:16
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