Some pits encountered in the development of electron

Time:2019-12-2

Some pitfalls encountered in the development of Downloader

1. The relationship between the confirmation and cancellation of the pop-up window and the cross sign of the system

Scenario: when you exit the app, you need to prompt the user whether to confirm the exit. At this time, the pop-up window appears. If you click OK, you can continue to exit and execute the callback. Otherwise, you will not exit

Problem: when clicking the cross, the returned value in the callback is 0. Because the buttons written in the code are in the order of [‘confirm’, ‘Cancel’], and the corresponding response when clicking “confirm” is also 0, which leads to the consistent behavior between clicking “confirm” and clicking the cross. In this case, it is incorrect. Clicking the cross should be equivalent to canceling exit.

//Problem code, click the confirm button to exit, and click the cross in the upper right corner to exit
Dialog. Showmessagebox (MainWindow, {buttons: ['confirm ','cancel']}, (response) = > {if (response = = = 0){
    //Perform exit operation
  } 
});
//After modifying the code, click OK to exit, and click the cross in the upper right corner to not exit
Dialog. Showmessagebox (MainWindow, {buttons: ['cancel ','confirm']}, (response) = >{
  if (response === 1) { 
    //Perform confirm exit operation
  } 
});

2. The code in the subprocess does not execute after packaging

Scenario: in the local development process, use the subprocess to download resources, which can be downloaded normally. However, after packaging, it is found that the download fails, and the events in the subprocess are not executed. Cause the download process to be blocked

Problem: when subprocesses are used in electronic, they are made as an external dependency. After packaging, the code of subprocesses will not be put into the package, and additional configuration is required.
Solution: additional configuration of subprocess files

Note: the scaffold of this project is based on electronic Vue, and the configuration file and electronic Vue remain the same

  1. Packaging configuration: asarunpack is used to organize some third-party packages used in subprocesses. Otherwise, the subprocesses cannot run if they cannot find these packages. Third party packages used in subprocesses need to be configured in asarunpack.
    The configuration of extraresources is used to package the directory where our code subprocess files are located and put them in a specified place. If there is a need to reference the subprocess files in the code, use this address to find the corresponding JS files. Because the path after development and packaging is different, the specific configuration of package.json is as follows

        "mac": {
          "icon": "build/icons/icon.icns",
          "extendInfo": {
            "CFBundleURLSchemes": [
              "link"
            ]
          },
          "asarUnpack": [
            "**/node_modules/electron-log/**/*",
            "**/node_modules/unzipper/**/*",
            "**/node_modules/axios/**/*",
            "**/node_modules/archiver/**/*"
          ],
          "extraResources": [
            {
              "from": "src/main",
              "to": "app.asar.unpacked/download"
            }
          ]
        },
        "win": {
          "icon": "build/icons/icon.ico",
          "asarUnpack": [
            "**/node_modules/electron-log/**/*",
            "**/node_modules/unzipper/**/*",
            "**/node_modules/axios/**/*",
            "**/node_modules/archiver/**/*"
          ],
          "extraResources": [
            {
              "from": "src/main",
              "to": "app.asar.unpacked/download"
            }
          ],
          "target": [
            {
              "target": "nsis",
              "arch": [
                "x64"
              ]
            }
          ]
        }
  2. Fork path of subprocess: the fork path of development and packaging subprocesses in electron is not the same. During development, the current path can be directly used for reference, but the JS file of packaging subprocesses can not be obtained directly through the relative path. So the path of fork subprocess needs to be configured as follows,process.resoucesPath: the path of the resource directory defined in electron, and the path of the subprocess JS after packaging.

    let isDev = process.env.NODE_ENV !== 'production';
    let scriptPath = isDev ? path.join(__dirname, 'child_download_serial.js') : path.join(process.resourcesPath, 'app.asar.unpacked/download/child_download_serial.js');

After the above two steps are completed, you can see the code directory of your subprocess under the installation package after packaging. This indicates that the configuration is successful and that the subprocess and the main process can communicate normally.Some pits encountered in the development of electron

The above scheme is applicable to both windows and MAC

3. The log output in the subprocess is unable

Scenario: you want to see the log output in the process and see the execution of the subprocess

Problem: the console of the child process cannot be seen in the console, because the child process and the parent process are separate, we can only see the output of the parent process

Solution: after getting the child process, listen for the stdout.on (‘data ‘) event of the child process in the parent process, so that all console.log in the child process will trigger the data event in the parent process, and the parent process can output the console content of the child process. Note that a silent: true configuration is required for fork. If it is true, the stdin, stdout and stderr of the child process will be delivered to the parent process, otherwise they will inherit from the parent process. In the same way, you can also listen to the data events of the stderr of the subprocess, and catch the errors of the subprocess

childDownload = fork(scriptPath, [], { silent: true });
childDownload.stdout.on('data', data => {
  Console. Log ('console of subprocess', data. Tostring());
});

4. The problem of electronic flashback

Scenario: when exiting the software, an error is reported due to code reasons, and then the software is shut down successfully. However, when the software is manually opened again, a flash back occurs

Problem: after the main process fails to catch the error, the error still exists when the software is opened again. The software cannot be opened

Solution: make a global error capture to avoid the problem that the software can’t be opened due to the error not captured in some cases

//Necessary global error capture
process.on('uncaughtException', error => {
  log.error(error.stack || JSON.stringify(error));
  app.exit();
});

5. The web side wakes up the client coverage problem

Scenario: after the download of the error book is installed, install the error Book logger tool. At this time, click wake-up download tool in the web, and wake up the error Book logger tool

Problem: when the two are packaged, the corresponding appid is the same. As a result, the software installed later will replace the software installed earlier. When the software is awakened in the webpage, the replaced software will wake up

Solution: the appid in package.json guarantees uniqueness

6. No third-party package can be found by using subprocesses under electron

Using subprocess under electron, no third-party package was found
Original link: https://github.com/chaijinson… Continuous update