Front-end early chat conference, a new starting point for front-end growth, jointly held with the Nuggets. Add wechat Codingdreamer into the conference exclusive push group, win at the new starting line.
The 14th | front-end growth promotion, 8-29 will be broadcast live, 9 lecturer (ant gold suit/tax friends, etc.), point I get on the bus 👉 (registration address) :
The text is as follows
This is the 64th session of the 10th Session of the Front-end Early Chat, and a brief edited version of the speech shared by Ziyang from the front-end team of Zhengqing-Cloud (please see the video and PPT for the complete version with the demonstration) :
To introduce myself
Welcome to today’s special talk about cross-terminal and cross-stack. Today, MY topic is “How to develop cross-terminal Applications based on Electron”. First, I would like to introduce myself. My name is Lu Ziyang. I joined Zhengcaiyun in 17 years, and now I am mainly responsible for the front-end engineering platform Dunhuang of Zhengcaiyun and the construction of its electronic bidding client. Here is our team’s wechat official account. If you want to know more about our team, you can pay attention to our official account.
The extension
First, the first piece we share is calledThe extension. I don’t know if you are familiar with this picture, some time ago we should have heard the news, Silicon Valley Iron Man Elon Musk released the first commercial manned dragon spacecraft, this picture is the dragon spacecraft console, someone on Zhihu comments on this picture called Js heaven. Why say Js heaven? It was rumored to be based on Electron, but this has not been confirmed. But one thing we can confirm is that the shuttle’s touch interface UI is based on Chromium + JavaScript architecture. This, to some extent, illustrates the usability and stability of this architecture.
Let’s review the development of the front end in the whole field. In the early days, the definition of front-end engineer might be Web development based on the browser runtime environment, but with the emergence of Node.js in 2009, front-end engineer has the ability to develop outside of the browser runtime environment. We have the capability to develop towards the server side, and the front-end capability extends to the server side.
With the development of THE HTML5 standard and the development of mobile device technology, front-end engineers can also embrace more development for mobile scenarios. There are also cross-platform technology solutions like React Native, a mobile domain, which the two lecturers talked about this morning. As mobile APP becomes a mainstream, the front-end is also popularized to Iot devices based on these intelligent devices and the computing power of chips. The front-end can have the development capability for Iot, and JS framework for Iot devices development like Thing.js is born.
CLI -> GUI
Today’s topic isThe desktopWith the advent of cross-terminal Js frameworks like Electron, the capabilities of the entire front-end engineer extend to the desktop. What is the value of having such a desktop development capability? First, let’s take a look at how the desktop experience is different. On the left, you can see an early DOS operating screen shot, and on the right, in 1983, Apple Lisa was the first PERSONAL computer in the world to have a graphical user interface, or GUI, as we call it. Let the late popularization of personal computer to achieve the popularization. The reason why it drives the popularity of personal computers is that graphical interfaces are more visually acceptable to users and the cost of learning has dropped dramatically. I believe that students who have used the MAC system will have a profound feeling of apple’s excellent interface design and overall interactive experience.
So what difference does this desktop GUI technology make to my front-end development work?
I believe you are familiar with the process on the left. What might we need to do when we start new project development? The first step might be to create a Git repository, clone the repository locally, and then install the CLI tool within the team to perform an examplexxx-cli createSuch a command to create a project. After creating the project, if we want to develop it, we need to run itnpm install, install the required dependencies, and eventually commit the entire project to a Git repository. This is the creation of our new project, an operation process based on CLI.
Value given by GUI
What value does the GUI give us? First of all, it can be dispersed task point to a series of integrated, provides a more simplified the operation of the link, at the same time it also can be erased the differences between different students when using some process, as well as the process relies on some of the differences in environment, and based on GUI is an integrated ability, we can also use other ability for a horizontal collusion, And designing plug-in mechanisms through GUIs can also create a co-built ecosystem. At the same time, the low learning cost of gui-based graphical interface operation, as well as its hosting of the whole process, can greatly reduce the research and development complexity of the team students.
Service Scenario Application
The following are landing scenarios of some key applications developed based on Electron. This is the business of the electronic bidding client of zhengcai Cloud, which I am responsible for. Its main function is to help users to change from the traditional offline bidding, paper bidding, to electronic bidding, we provide such a client can help users to series the whole process of bidding. At the same time, based on the capability of Node.js provided by Electron, users can read and write local bidding files, as well as encrypt and decrypt local files, all of which can be completed inside the client.
Infrastructure Application
Here is the practice of Electron on our engineering platform, which is the front engineering platform we mentioned earlier – Dunhuang. What it does is it hosts the whole front-end development process, like the project creation we just mentioned. We will also introduce some of these applications in detail below.
Development mode
Above we have outlined some of the values of Electron. If we wanted to develop a cross-platform desktop application based on Electron, how would we do it? Let’s take a look at part 2: ** Development patterns. How is the development mode of **Electron different from our normal Web development?
Electron architecture
First of all, this is an overall architecture of Electron. It is an open source framework developed by Github that allows us to use HTML + CSS + Javascript to build and develop desktop applications, greatly reducing the complexity of desktop application development. The core of the overall architecture is Chromium + Node.js + Native APIs. Chromium provides UI capabilities, Node.js makes Electron capable of low-level operations, and Navtive APIs solve some cross-platform problems. For example, there are some differences between Windows, MAC OS and Linux, and it also provides a more unified experience of native capabilities.
Ability to point
Let’s talk about some of its core capability points.
- First of all, Chromium, we can understand it as a Chrome browser with the latest browser features. The advantage it brings us is that we don’t need to consider the compatibility of browsers in the development process. We can use some of the latest ES6 and ES7 syntax, and we can safely use Flex layout. As well as the latest browser features, you can try them out, regardless of compatibility.
- Node.js provides the ability to read and write files, call local commands, and extend third parties. Based on the entire node.js ecosystem, nearly hundreds of thousands of Node.js modules can be used in the entire client.
- Native APIs provide the ability to provide a unified Native interface that includes system notifications, keyboard shortcuts, and access to system hardware information. It also provides basic desktop client capabilities, such as update mechanisms and crash reporting.
Comparison of selection of other desktop terminals
Electron offers these capability points that greatly reduce the cost of desktop development and the barriers to getting started. Of course, for desktop development, there will be some other models besides Electron, so let’s take a look at how it compares to other models.
- Native development is the first choice for desktop development. However, when developing different platforms, different languages need to be used. However, its advantages are better Native experience and better running performance, but its threshold is relatively high.
- QT is a cross-platform desktop development framework based on C++. The language it uses is C++. In terms of overall performance and experience, QT is comparable to Native development, but the development threshold is relatively high due to the technology stack.
- The other two are Electron and Nw.js. Both use Javascript as a development language. Compared to Native and QT, they are quite friendly to front-end engineers, and they have a similar architecture, both based on Chromium + Node.js, and both have a cross-platform support capability. However, the difference between the two is that Electron has a better community ecology and community activity. If we encounter some problems at ordinary times, there may be more and more perfect solutions in the community, and its response speed to issues is also relatively fast.
So based on the above comparison, Electron is a very good choice for front end engineers to develop desktop clients.
Structure for simple Electron applications
Now, what do you do if you want to develop a desktop client? Here is the simplest Electron desktop application structure. We only need three files. First, we define a startup entry for the application using the main field in package.json. We defined the entry file as main.js. What did we do in mian. First, app represents the entire application and monitors the state of the app. When the entire application reaches a ready state, a new BrowserWindow is created through the BrowserWindow provided by Electron. After creating the browser window, load the index. HTML file and you have a basic desktop application. How is developing a desktop application based on Electron different from developing a Web application based on Electron? We need to understand two core concepts: the main process and the renderer process, and how the communication between the two processes is implemented. In the example above, main.js is run in the main process and index.html is run in the renderer process. Let’s use a simple Demo to see how two processes can communicate and make some Node.js power calls through the main process.
Communication between processes
What we want to do is have a button on the page, and when the button is clicked, it sends a say-Hello message to the main process, and when the main process receives the message, it creates a file on the system desktop called Hello.txt. And write Hello Mac! . What exactly did we do?
First in the render process, we should have a button action event on the page. When the event is triggered, we send a message called say-Hello to the main process via the ipcRenderer API provided by Electron. When our main process receives such a message, we can call node.js’s FS module, which reads and writes files, directly from the main process. We start by creating a file and writing the transfer to it. After the file is written successfully, the renderer process is replied and the system Notification is displayed to inform the user by calling the Notification module provided by Electron. This is a simple Demo implementation. The core point is to pay attention to the concept of the main process and the renderer process. And how two processes communicate with each other through the IPC mechanism. Here is a simple implementation. There are a few more application scenarios that I won’t go into too much about the API here.
Engineering CLI -> GUI
We will introduce the Electron development practice according to a practical application. Taking dunhuang, our front-end engineering platform, as an example, this paper introduces how we change the engineering capability from CLI to GUI through Electron. Let’s start with a video that demonstrates the entire process of creating a project that we mentioned at the beginning. As you can see, the whole process has completed the creation of the Git repository, the creation of the project template, the push of the project template to the repository, and the local cloning of the Git project. After the cloning is completed, the dependent installation will be carried out, and the process will be reloaded and managed on the client side. A series of previously scattered single point command operations through the GUI. This process is just one part of the engineering platform, in which we have realized a lot of single point command to workflow series.
I2P Install To Publish
Here is the system architecture of our whole front-end application management platform. The core process is an I2P concept written above, which is install to publish. It completes the component, template, and project levels, hosting the entire process from creation to release.
- The creation stage mainly provides local creation, Git creation, unified creation template management, creation process approval and creation completion feedback.
- In the development phase, it provides a Dev Server operation capability, project-level page management, dependency management, branch management, and one-click upgrade capability. At the same time, the CI/CD continuous integration capability is also opened.
- In the release stage, it provides a pre-release permission verification and compliance testing, resource push and release approval mechanism.
- Data analysis is a core part of our whole process. It is to precipitate some data of our whole process and output these data in the form of visual statements. Based on these data, the whole I2P process is connected with other capabilities.
Throughout the I2P process above, we precipitated some project data, including process data, and possibly some component management-like data. With data as the connection point, the whole R&D process can be connected in series with some other technical construction capabilities, including user behavior analysis, page-level, project-level performance analysis reports, and error monitoring mechanisms, which can be connected to the entire engineering platform. What underpins our entire engineering platform are some of the basic capabilities and the desktop capabilities that Electron provides. Basic capabilities, including some general GIt operations, NPM operations, some command execution, and some local Logger services. Electron provides desktop features including updates, window management, communications, and some native capabilities.
From point to line
Single point command -> Task flow
Let’s look specifically at how to implement a cascade from a single point of command to a task flow. To transform the operation of a single point of command into a concatenation pattern of task flow, we will do so from the following four entry points. • First we will change some of the normal command calls into functional calls. • Orchestrate and assemble a task flow based on these functional calls, customizing a task flow based on actual development scenarios. • The third thing we need is the task progress feedback mechanism of the whole task flow, how to execute the task, through the ability of GUI, so that users can intuitively feel the execution link and progress of the whole task. • Finally, an important piece of the overall task flow is data collection for the entire process.
Process design
Here is the architectural design of the project creation process we just demonstrated. When we call the project creation module, we will first create Git projects through the Server interface. After the verification is passed, a warehouse is created by calling Gitlab API. After that, a unified project template is pulled according to the selected template information, and a real project file is generated according to the project name, project description and other information entered by the user. Call the Gitlab API to push the entire project file to the repository you created. About the use of Gitlab API this piece, in the nuggets have been shared articles, if you are interested in it, you can go to know, here will not be detailed. After completing a series of Git creation operations on the server, the url of the successful repository will be sent to the desktop. After receiving the result of the successful creation, the desktop will start to execute some local operations. Clone the Git repository to your local workspace while completing the dependency installation for the entire project. After dependency installation, we will use desktop notification capabilities, including the pin interface to complete notification and feedback. Cloning, dependent installation, and notification feedback are done in the main process on our desktop. It has real-time message feedback with the renderer process throughout our task flow. We will communicate the progress of the whole task, including the log output of command execution and the result of command execution, with the rendering in real time through IPC, and finally give feedback to the user on the interface. Project and process data are also stored throughout the process.
NPM install changes to npm.install()
First of all, when making a command call, it is necessary to putnpm installSuch a command line call becomes a functional call, which becomesnpm.install()Such a call.
Git init becomes git.init()
Git commands are also called functionally
Promise the imperative execution
Let’s take a look at how to turn an imperative call into a functional call for a specific scenario. The first is to Promise the command. For example,git initIn such operations, when executing the whole command, we are more concerned about the result of the whole command execution, and may not care about some output content during the command execution. In this case, we can use node.jsspawnTo start the child process to execute the command. By listening to the child output to determine the execution status of our entire command, and then encapsulating the entire command with a Promise, we’re donegit initSuch a command line call becomesgit.init()Such an asynchronous function call.
Command execution logs are displayed in real time
In another scenario, let’s saynpm installDepending on the installation, or start the local development service, the entire command execution process may be quite long, we are more concerned with the real-time log output during the process. How do we do that? So the first thing we’re going to do is we’re going to create oneEventEmitterInstance, as our log distribution management, we also passspwanTo start a child process to execute commands, and in real time to listen to the child process output, output logs throughemitterThe instance distributes it. After we get the real-time log output in the main process, we can send the log output to the renderer process in real time through the IPC communication between the main process and the renderer process.
With the ability to turn imperative calls into functional calls, you can orchestrate the flow of tasks by calling these functions. For example, we mentioned project creation, which is probably a more general process, as well as component management, template management and project publishing. You can arrange your own task flow according to your actual business needs.
Analog terminal: feedback task progress
Above we mentioned some changes to the overall command execution in the main process. So how do we implement end-log feedback in our rendering process like the one in the previous video? There are many ways to give feedback. We can give feedback on the progress of the whole task by designing some step bars or progress bars. But a better way is to provide timely feedback on the progress of the task, including the entire task output log. Here we use xterm.js. It is a front-end terminal component written based on TS, can achieve terminal applications in the browser, VsCode is based on xterm.js to achieve the terminal. How do the main process of log to output to the rendering process, is mentioned above, we get the broadcast by a EventEmitter output, to pass the main process and the communication between the rendering process, will push data to the rendering process, the rendering process need to do a deal with, to accept to the command output, Render in real time to terminal components implemented by Xterm.
This completes the feedback mechanism for the entire task flow.
The above is the realization of a task flow in our engineering platform. With the help of Electron capability, we can easily realize the arrangement of tasks in the whole process and the interface interaction of the corresponding process, thus simplifying the whole process. In addition to the realization of the task flow, we need to be more concerned about is the process of data collection, including the process data and precipitation process created in the project, the component data, also include some abnormal data of process, because these data are the basis of the process and other construction ability, the basis of get through at the same time also can let us to the whole process of continuous optimization,
update
After completing the development of the client, we need to consider the subsequent update. Let’s take a look at how we can implement the automatic update function of the client.
After building our application through election-Builder, we will output a latest-Mac. yml file and the application ZIP package, and put these two files on the update server. There are many implementation schemes of the update server, and we choose CDN as the update server. How do we design the entire update process? In the rendering process, there is usually a trigger entry to manually check the update, or through polling task, to periodically check the version update. After the renderer initiates a version check, it is called within the rendererautoUpdaterModule, it isElectronBuilt-in update management module. The first step is to set the feedUrl, which is the latest update package to update the server address. Called when a versioning request is received for a renderer processcheckForUpdatesMethod, which then triggers the following series of events. We can control the entire update process by listening for the entire lifecycle of the update event.
The problem with Electron’s built-in update mechanism is that the update packet is large. Because the desktop application that we built with Electron, which integrates all Chromium, even if we wrote a tiny Hello World app, it would be about 40MB compressed, A typical application might take up about 100MB. The problem is that some small changes need to be fully updated, which is not very good for the user experience. What solutions do we have for these? First of all, we can make an optimization on the interaction design of the whole update. What we need to provide is a feedback on the progress of the whole update process, and the other thing is that we can download in the background through autoUpdater. After downloading the entire update package, we will notify users to restart the entire application and then update the entire application. In this way, from the interactive level, some impacts of incremental updates on users’ experience will be avoided to a certain extent. Of course, there is a problem with full update. If the number of users is large, network resources will be wasted.
delta
Here are some of our practices for incremental releases. First, the static resources of the entire Renderer layer are managed by CDN. For our entire application, static resources in the Renderer layer will not be packaged into the final desktop application, and resources will be remotely hosted. Meanwhile, according to some specific business scenarios, we can make use of the service worker ability to do an offline cache for the whole resource, and do version control for static resources.
Update process
An update process in the Renderer layer looks like this: when a page makes a request, it first matches the local cache for a resource, and if it matches a resource, it returns the result. If there is no local match, the latest resource is requested again and the requested resource is cached. If an error occurs throughout the request, a default version of the resource needs to be available and the error reported. One of the things we’ve implemented here is an incremental update based on the UI layer. In actual business scenarios, depending on the update frequency of different resources, it is necessary to decide whether to optimize the experience of the update, or to use the incremental update of the UI layer or the incremental update of the installation package.
Technical framework drawing of Dunhuang Engineering Platform
Over here is the architecture of the entire application management platform, in our practice, the whole project in addition to the implementation of the whole project, components and templates I2P whole process managed, we also provide other skills, such as team entry of convergence, including document entry, output entrance, will also be some of the tools for an integrated within the team, We integrate some tools scattered in various places, such as document site generation tool, graph bed tool and IconFONT management tool. Meanwhile, we also collect the user behavior data of the whole client and continue to iterate through data analysis.
More scenes
Above our practice based on Electron front-end engineering platform. Of course, Electron will have some other applications, so let’s take a look.
Of course, there are many more possibilities, such as the aforementioned spaceX bigger scenario ~
Recommend a book
Here is a book I personally recommend, The Road Less Traveled, to learn how to look at problems with a more mature mind. As we grow, we are more likely to be constrained by cognitive and mental limitations. What kind of cognition and mentality to treat problems will determine what kind of response and what kind of ability to respond to these problems. This book will allow us to explore more how we can look at our problems with a more mature mind. I hope that through this book, we can learn how to better face the problems beyond technology and solve the problems better.
recruitment
Above is all my share today. Here is the QR code of our team’s official account, you can go to know some of our team’s output. At the same time, we are recruiting front-end interns, senior and senior front-end engineers recently. If you are interested, please send your resume to the email below. Thank you
QA
Ask ziyang: how to carry out hot update? As FAR as I know, the page packed by Electron is placed inside the package. How to update it online?
I understand that the problem should be UI level interface updates. In fact, I have mentioned just now, we have some static page resources is made a CDN managed, at the time of the update, there will be a testing update mechanism, it can be done by polling or server push, when I received the notice of static resources version updates, through the main process for rendering process a mandatory ignore the cache refresh, Alternatively, users can trigger page reloads to update static resources at the UI level through interaction in the main process, including upgrade reminders and update logs.
Ziyang: Can you compare the difference between Electron and Nw.js?
The biggest difference between the two is that the integration of node.js and Chromium event loops is handled differently. First of all, nw. js makes the Chromium and Node.js event loop mechanism open by modifying the source code. Electron implements the mechanism by enabling a new secure thread to forward events between Node.js and Chromium. One advantage of this is that the Chromium and Node.js event loops are not so strongly coupled. Another difference is that Nw.js supports XP, while Electron does not. Has more active community in comparison Electron, and more large applications such as VS code, Atom practice case, more can refer to the difference between Electron official introduction: www.electronjs.org/docs/develo…
Is the update package file stored on a private file server or Gitlab or Github?
There are many ways, our implementation is through the hosting of CDN, can also be through Github or private file server to build to achieve. Choose according to your actual business scenario and technology stack.
This article is formatted using MDNICE