-
Notifications
You must be signed in to change notification settings - Fork 65
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
Electron build of JBrowse desktop #520
Conversation
make run in electron
Brain dump from WIP:
|
Dude thanks so much for this deep dive. So many dragons in there!
…On Sat, Sep 28, 2019 at 6:16 PM Garrett Stevens ***@***.***> wrote:
Brain dump from WIP:
- Webpack "electron-renderer" target assumes nodeIntegration is true,
which used to be the default for electron, but now is not. We want to avoid
nodeIntegration for security reasons.
- Tried to create a custom target. The target worked, but if a target
isn't one of webpack's pre-defined ones, you lose a whole bunch of presets
and some npm modules won't work because they think you're in a node
environment.
- Using "web" target for now, which works, it just doesn't take
advantage of "Externals" in webpack, so it will probably make the bundled
size bigger.
- We want to use ipc calls to communicate between renderer and main
processes. Renderer (which does not have access to node) sends an ipc call
to Main (which has node access), Main then e.g. runs fs.open and returns
the filehandle to the Renderer.
- With nodeIntegration off, you can't import electron, which you need
in order to do renderer<->main thread ipc calls.
- Workaround is to use a "preload" process that imports electron and
assigns it to a global variable.
- Web workers can't see the global electron, though, and they're the
ones that really need it since they do the file access.
- There is a nodeIntegrationInWorker setting where you can enable node
just in webworkers. This would be great, except compiling webpack with a
"web" target clobbers the native node modules. __non_webpack_require__
does not seem to work.
- Would be best to do webpack on the workers separately with the
"webworker" target (or actually maybe "node" target?), but not sure yet if
that works with this setup.
- Using MainThreadRendering, I was able to get an example of the
renderer<->main thread RPC calls mostly working.
- For some reason, getting uncaught errors with an empty error object
(no explanation, name, anything). Might be related to aborting.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#520?email_source=notifications&email_token=AAASAFM24OXOPSST4OY53UDQL76XJA5CNFSM4I2ELE2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73FOVA#issuecomment-536237908>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAASAFJC5222IRDMM2YPB53QL76XJANCNFSM4I2ELE2A>
.
|
Error in the last bullet point above was not due to aborting, it just appeared that way at first. It was actually due to errors in the main process. It turns out errors that originate in the main process don't contain any information when passed to the renderer process. To see main process errors, you have to try/catch them and log the error, and then it will show up in the terminal window that electron is running from (won't show up in dev tools). With GMOD/bam-js#42 incorporated, I now have a working version using a local BAM file and MainThreadRpcDriver. |
Codecov Report
@@ Coverage Diff @@
## master #520 +/- ##
==========================================
- Coverage 66.62% 60.79% -5.84%
==========================================
Files 247 266 +19
Lines 8417 9300 +883
Branches 1930 2109 +179
==========================================
+ Hits 5608 5654 +46
- Misses 2591 3373 +782
- Partials 218 273 +55
Continue to review full report at Codecov.
|
Also get rid of unused pluginManager in worker driver constructor
CORS-busting is working, dependent on GMOD/generic-filehandle#42. This is the gnomAD SV VCF, which doesn't work in jb-web because of CORS: Once that PR is merged I'll mark this ready for review. |
…loping on laptop+desktop setups
Add new empty session card and placeholder new SV Inspector card
Start screen is working now, so I think this is ready for review. |
I added a couple comments. Some other random ones Would be good to get some sort of automated testing of the electron app. JBrowse 1 used spectron to do this and it actually works on travis-CI. Also sometimes the app shuts down without warning and in the console it says "Maximum number of clients reached". Wondering if it's related to the screenshoting logic (maybe the screenshot is a client? not sure)
|
@@ -9,14 +9,15 @@ | |||
"allowJs": true, | |||
"skipLibCheck": true, | |||
"esModuleInterop": true, | |||
"allowSyntheticDefaultImports": true, |
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.
I think it may be better to not use this flag, not sure though
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.
I'm not sure either, but I will say that this is the default tsconfig for a fresh typescript-enable CRA.
@@ -1,6 +1,6 @@ | |||
{ | |||
"compilerOptions": { | |||
"target": "esnext", | |||
"target": "es5", |
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.
Might as well keep it as esnext?
@@ -90,41 +90,41 @@ export function stateModelFactory(pluginManager: any) { | |||
configuration: types.frozen(), | |||
}) | |||
.views(self => ({ | |||
get viewingRegionWidth() { | |||
get viewingRegionWidth(): number { |
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.
In general, I like having automatically determined function return types, if there is a rule requiring them I would prefer to keep it off
session: PropTypes.observableObject.isRequired, | ||
} | ||
|
||
export default withSize()(observer(App)) |
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.
The App.js from jbrowse-web does not use withSize. We may want a way to de-duplicate logic between jbrowse-web and jbrowse-desktop in some cases, not sure what the right approach is though
@@ -0,0 +1,1372 @@ | |||
{ |
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.
I'd like this config.json to be the same as JBrowse desktop so I can compare all tracks
This started out as a bit of a crazy idea, but now I kind of hope it works out. Basically this makes a new create-react-app (CRA) app for jbrowse-sv-inspector-desktop and builds it in electron. The development version works fine, and I'm working on getting it to build a production version.
As I was working on getting a new electron project going, I tried to start from scratch, but there were so many webpack, babel, etc. things to set up. There are some boilerplates out there, but none of them were great. Really, nothing as nice as what CRA put in place for us in jbrowse-web.
Then I found this article on creating an electron app using CRA. It's not exactly what we want, but has some good ideas and gave me a good starting point. Currently you can try out
yarn start
in jbrowse-sv-inspector-desktop and it runs basically a copy of jbrowse-web in an electron window.Things still to see:
This article above also uses something called rescripts, which lets you hack your CRA setup without ejecting. I actually used it to un-eject jbrowse-web, so that both it and jbrowse-sv-inspector-desktop can take advantage of the latest CRA updates and we don't have to maintain the dev and build systems separately.
resolves #195
resolves #484
resolves #512