How do we add worker thread in Electron JS?
I have tried below which works fine in dev mode.
const worker = new Worker(path.join(__dirname, 'worker.js'));
But this causes error when the app is packaged, it is looking for worker.js inside app.asar. Even with the worker.js included in build/files.
Related
I have an electron app, that loads some css's from spring boot server.
When I run app from npm from sources, I can run as
ng build && electron . --disable-http-cache
and it works without the cache.
If I build my app with electron-packager to app.exe, how can I disable cache.
Start .exe-file with --disable-http-cache doesn't work
UPDATE
The only approach that works is to clear cache from main process before app loads the page. But is there any another way to disable cache?
Another possibility is to use Electron's commandLine.appendSwitch () in the main process on the app object, right before anything gets executed:
const { app } = require ("electron");
app.commandLine.appendSwitch ("disable-http-cache");
// any other main process code
This will append --disable-http-cache to Chromium's command line, just like appending it to the electron command would. When having this in code, you do no longer have to run your app with appending this switch as it will automatically be added.
You can also add a no-cache header inside loadURL() of the route that is requesting the css (or even the root route)
webContents.loadURL(url, {"extraHeaders" : "pragma: no-cache\n"})
A complete mini example gist
I am using foreverjs within my electron app main like so:
const forever = require("forever-monitor");
let child = forever.start(scriptPath, {fork: true});
I am doing this intentionally over using child_process.fork because I want foreverjs to monitor the forks and restart them when needed.
Well - the above works, but looking at my dock on mac osx, I see that the electron app is duplicated for each fork. In production it is the same -- the app icon get's duplicated N times in the Dock for each process.
Investigating further I found the cause but not the solution. The cause is that when you fork a process normally using child_process from within electron, it launches it using the Electron Helper app.
However when you fork a process using forever.js it uses the Electron app itself, thus explaining the duplicates.
How do I force forever to use the Electron Helper app when forking and not the Electron app itself?
OK, so I figured it out. Quite simply you need to pass one environment variable to foreverjs like so:
const forever = require("forever-monitor");
let child = forever.start(scriptPath, {fork: true, env: {ELECTRON_RUN_AS_NODE: 1}});
Doing this and the fork will correctly use its prepackaged version of node instead of launching another copy of electron "main".
I'm building an application with Electron and packaging with Electron Builder. When running electron, I want to pass this command line argument: --enable-mixed-sandbox.
Is it possible? How?
This:
app.commandLine.appendSwitch('enable-mixed-sandbox')
wouldn't work due to:
Note that it is not enough to call
app.commandLine.appendSwitch('--enable-sandbox'), as electron/node
startup code runs after it is possible to make changes to chromium
sandbox settings. The switch must be passed to electron on the
command-line:
electron --enable-sandbox app.js
It is not possible to have the OS sandbox active only for some renderers, if --enable-sandbox is enabled, normal electron windows
cannot be created.
You can use app.commandLine.appendSwitch in your applications main script (the one that opens the Electron window)
Example for your switch would be
app.commandLine.appendSwitch('enable-mixed-sandbox')
another way of doing it, you can use spectron to start the app in debug mode. which allows you to pass any arguments you want.
const Application = require('spectron').Application
// Returns a promise that resolves to a Spectron Application once the app has loaded.
// Takes a Ava test. Makes some basic assertions to verify that the app loaded correctly.
function createApp (t) {
return new Application({
path: 'path/to/app',
args: ['-r', '--enable-mixed-sandbox'],
env: {NODE_ENV: 'test'},
waitTimeout: 10e3
})
}
https://github.com/electron/spectron#new-applicationoptions
I got a response on that issue I raised and linked to in the comments:
app.enableMixedSandbox() // Experimental macOS Windows
See here for documentation.
This is a silly question, but I could not find a clear answer on the web.
Do I need to listen to a special "dom-ready-event" if my app is running within a BrowserWindow in Electron? For instance in a Cordova/PhoneGap app I read you can start doing things after the deviceready event.
I would like to know how this is done in Electron? Is one of the following enough?
document.addEventListener("DOMContentLoaded", startApp);
window.addEventListener("load", startApp);
Thank you.
Cordova has deviceready because it has both native code and JavaScript code, and potentially JavaScript might run before the native code has finished loading.
You don't have the same problem in Electron. You have a main process (main.js) which creates your BrowserWindow, so by the time any client-side JavaScript is running, your main process has definitely already started because it was the thing that created your browser window in the first place!
Inside the browser window the same events fire as they would on a normal webpage. So if you wanted to, you could use DOMContentLoaded or load (for the difference see this article on MDN), just in the same way as you would for a regular web application. But you certainly don't need to before calling any of the Electron APIs.
I'm trying to see if I understand how Electron's implementation of Node.js is done and how it interacts with the app. From my understanding, the startup web page has a javascript file that runs as a "renderer" process. Code in this script can also access any of the Node.js APIs. To create new browser windows, code in renderer script uses new BrowserWindow to create new windows and each window in turn has its own renderer script.
Code in the renderer scripts run under Node.js and as such any code written in these scripts cannot communicate with script code in the browser's web page.
Is all of this true or am I wrong on something?
The Electron main process can create new windows (with Browser Window) and each of those windows has a renderer process. You can use ipc to send messages between the renderer process and the main process. To send a message from one renderer process to another, there are plugins for that, or you just have to relay the message through the main process.
The format/appearance of each window is controlled via html and css. Part of creating a window is specifying the html file to load.
More info can be found in this other SO question. The other question referenced this repo which has more info.
Lastly, the consensus seems to be to put as much in the renderer as possible.
For more clarification, by
Code in the renderer scripts run under Node.js and as such any code
written in these scripts cannot communicate with script code in the
browser's web page.
are you asking if an Electron app can interact with a separate web browser?