electron.js_在使用Electron.js之前我希望知道的事情

electron.js

In this article, I'll share how you can avoid some of the mistakes I made when learning about Electron.js 🤦‍♂️. I hope it helps!

在本文中，我将分享如何避免在学习Electron.js 🤦‍🤦️时犯的一些错误。 希望对您有所帮助！

Note: This wont be a coding tutorial, but rather a discussion about my personal takeaways.

注意 ：这不会是编码教程，而是有关我的个人收获的讨论。

A couple of months back, I decided to focus more on building my side product, taggr. I was inspired to build it because of how many photos I have on my computer.

几个月前，我决定更加专注于构建副产品taggr 。 由于计算机上有多少张照片，我受到了启发。

For those of us that keep a backup of their pictures, those collections often get so big and complex that they become a full-time job to manage. A mix of folders and sub-folders may contain instant messaging picture backups, hi-resolution pictures from your trip to Bali, your uncle's wedding, or last-year's bachelor party.

对于我们这些保留照片备份的人来说，这些收藏通常变得如此庞大和复杂，以至于它们成为专职管理工作。 文件夹和子文件夹的混合物可能包含即时消息图片备份，您到巴厘岛旅行，叔叔的婚礼或去年的单身派对的高分辨率图片。

Always keeping such collections tidy is tedious (believe me, I have tried for years). It's also hard to discover the shots that you love the most, hidden deep within the folders.

始终保持此类收藏整齐乏味 (相信我，我已经尝试了多年)。 也很难 发现最喜欢的照片，隐藏在文件夹的深处。

So taggr is a desktop app that solves that problem. It lets users rediscover their memories while keeping their privacy.

所以taggr 是解决该问题的桌面应用程序。 它使用户可以在保留隐私的同时重新发现他们的记忆。

I am building taggr as a cross-platform desktop application. Here I'll share some of the things I've learned about cross-platform app development with Electron.js that I wish I knew from the beginning. Let's get started!

我正在将taggr构建为跨平台的桌面应用程序。 在这里，我将分享一些我希望从一开始就了解的有关Electron.js跨平台应用程序开发的知识。 让我们开始吧！

背景 (Background )

Before presenting my takeaways on this ongoing journey with Electron, I would like to give a little more background about myself and the requirements of taggr.

在向我介绍与Electron进行的这次旅程之前，我想先简要介绍一下自己和taggr的要求。

Every developer comes from a different background, and so do the requirements of the applications they develop.

每个开发人员都来自不同的背景，因此他们开发的应用程序也有不同的要求。

Contextualizing the choices I made for this project may help future developers select the right tools based on their needs and expertise (rather than what is hyped out there – GitHub 🌟, I am looking at you).

将我在此项目中所做的选择与实际情况相结合，可能会帮助未来的开发人员根据他们的需求和专业知识选择合适的工具(而不是在这里大肆宣传–我正在寻找GitHub🌟)。

As mentioned earlier, from the beginning I envisioned taggr as a cross-platform application. The app would perform all the required pre-processing and machine-learning computations client-side due to the focus on privacy.

如前所述，从一开始我就将taggr设想为跨平台应用程序。 由于专注于隐私，该应用程序将在客户端执行所有必需的预处理和机器学习计算。

As a one-person show, I wanted to be able to write my app once and ship it to different systems without losing my sanity.

作为一个人的节目，我希望能够编写一次我的应用程序并将其发送到不同的系统，而又不会失去理智。

From my side, I am a front end engineer in love with the web and JavaScript. I previously worked with Java and C#, but I enjoy the flexibility that the web provides and its vibrant ecosystem.

从我的角度来看，我是一位热衷于Web和JavaScript的前端工程师。 我以前使用过Java和C＃，但是我喜欢Web提供的灵活性及其充满活力的生态系统。

Having experienced first hand the pain of using tools like Eclipse RCP to build client-side apps before, I knew I didn’t want to work with that tech again.

亲身经历过使用Eclipse RCP之类的工具来构建客户端应用程序的痛苦，我知道我不想再使用该技术。

In short, my stack requirements for taggr boiled down to something like the following:

简而言之，我对taggr的堆栈要求可以归结为以下内容：

• It should provide cross-platform support, ideally at the framework level. 📦

  它应该提供跨平台支持，最好是在框架级别。 📦

• It should allow me to write the code once, and tweak for each platform if needed. 🖥️

  它应该允许我编写一次代码 ，并根据需要针对每个平台进行调整。 🖥️

• It should enable access to machine-learning capabilities, regardless of the host environment, without specific runtimes to be installed. It should be painless to set up. 🤖

  无论主机环境如何，都应启用对机器学习功能的访问 ，而无需安装特定的运行时。 建立起来应该很轻松。 🤖

• If feasible, it should use web technologies. It would be great to leverage my existing knowledge. 🧠

  如果可行，则应使用网络技术 。 充分利用我现有的知识。 🧠

As you can see, the requirements do not read as: I should use React with Redux, observables, and WebSockets. Those are lower-level implementation details, and they should be decided upon when and if the need arises.

如您所见，这些要求不能理解为： 我应该将React与Redux，observables和WebSockets一起使用 。 这些是较低级别的实施细节，应在何时以及是否需要时决定。

Pick the right tool for the job rather than picking a stack from the beginning, disregarding the problems at hand.

选择合适的工具来完成工作，而不是从一开始就选择堆栈，而不管眼前的问题。

So, after furious googling, I decided to give Electron a try. I hadn’t used that framework before, but I knew that many companies were using it successfully in products such as Atom, VS Code, Discord, Signal, Slack and more.

因此，在疯狂搜索之后，我决定尝试一下Electron。 我以前没有使用过该框架，但我知道许多公司已在Atom ， VS Code ， Discord ， Signal ， Slack等产品中成功使用了该框架。

Open-source and with out-of-the-box compatibility with both the the JS and Node ecosystems (Electron is build using Chromium and Node), Electron.js was an attractive tool for the work at hand.

Electron.js是开源的，并且与JS和Node生态系统具有开箱即用的兼容性(Electron是使用Chromium和Node构建的)，Electron.js是进行当前工作的有吸引力的工具。

I won't go too much into detail regarding the rest of the stack, as I repeatedly changed core parts (persistence and view layers) when needed, and it falls out of the scope of this article.

由于在需要时我反复更改了核心部分(持久层和视图层)，因此我不会对堆栈的其余部分进行过多的详细介绍，但这不在本文的讨论范围之内。

However, I would like to mention Tensorflow.js, which enables running training and deploying ML models directly in the browser (with WebGL) and Node (with C bindings), without installing specific runtimes for ML in the host.

但是，我想提到Tensorflow.js ，它可以直接在浏览器(带有WebGL)和Node(带有C绑定)中运行培训并部署ML模型，而无需在主机中安装ML的特定运行时。

So back to Electron – thinking it was perfect, the fun began. 💻🔥

回到Electron –认为那是完美的，乐趣就开始了。 💻🔥

Enough talk about the background. Let’s dive into the takeaways.

足够谈论背景。 让我们深入了解外卖。

1.从小(慢)开始slow (1. Start small (and slow) 🐌)

This is not a new concept, but it's worth bringing up periodically. Just because there are a ton of awesome starter projects with Electron available, it doesn’t mean that you should pick one right away.

这不是一个新概念，但是值得定期提出。 仅仅因为有大量可使用Electron的出色入门项目 ，并不意味着您应该立即选择一个。

Wait. What?

等待。 什么？

Slow is smooth, and smooth is fast. — Navy saying

慢是平滑的，而平滑是快速的。 海军说

便利带来复杂性 (With convenience comes complexity)

While those starters include many useful integrations (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), they also have their issues.

虽然这些入门者包括许多有用的集成(Webpack，Babel，Vue，React，Angular，Express，Jest，Redux)，但它们也存在问题。

As an Electron newbie, I decided to go for a lean template that included the basics for ‘creating, publishing, and installing Electron apps’ without the extra bells and whistles. Not even Webpack in the beginning.

作为Electron的新手，我决定选择一个精简的模板，其中包含“创建，发布和安装Electron应用程序”的基础知识，而没有多余的花招。 一开始甚至没有Webpack。

I recommend starting with something similar to electron-forge to get up and running quickly, You can set up your dependency graph and structure on top to learn the ropes of Electron.

我建议从类似于电子伪造的东西开始，使其快速启动并运行，您可以 在顶部设置依赖图和结构，以了解Electron的精髓。

When the issues come (and they will), you will be better off if you build your custom starter project rather than picking one with +30 npm scripts and +180 dependencies to begin with.

当问题来了(他们会)，你会如果你建立你的自定义启动的项目，而不是挑选好起来的一个具有+30 NPM脚本和+180依赖开始。

That said, once you feel comfortable with Electron’s basis, feel free to step up the game with Webpack/React/Redux/TheNextHotFramework. I did it incrementally and when needed. Don’t add a realtime database to your todo app just because you read a cool article about it somewhere.

就是说，一旦您对Electron的基础感到满意，请随时使用Webpack / React / Redux / TheNextHotFramework加快游戏的进度。 我在需要时逐步进行了处理。 不要仅仅因为您在某处阅读了有关它的精彩文章而将实时数据库添加到您的待办事项应用程序。

2.精心构建应用程序🧘‍♂️ (2. Mindfully structure your app 🧘‍♂️)

This one took a little longer to get right than I am happy to admit. 🙊

比起我乐于承认的事实，这件事花了更长的时间才变得正确。 🙊

In the beginning, it may be tempting to mix up the UI and Backend code (file access, extended CPU operations), but things get complex quite fast. As my application grew in features, size, and complexity, maintaining one tangled UI+Backend codebase became more complicated and error-prone. Also, the coupling made it hard to test each part in isolation.

在开始时， 可能很想将UI和后端代码 (文件访问，扩展的CPU操作) 混合在一起 ，但是事情变得非常复杂。 随着我的应用程序功能，大小和复杂性的增长，维护一个复杂的UI + Backend代码库变得更加复杂且容易出错。 而且，耦合使得很难单独测试每个零件。

When building a desktop app that does more than an embedded webpage (DB access, file access, intensive CPU tasks…), I recommend slicing the app into modules and reducing the coupling. Unit testing becomes a breeze, and there is a clear path towards integration testing between the modules. For taggr, I loosely followed the structure proposed here.

当构建的桌面应用程序的功能不只是嵌入式网页(数据库访问，文件访问，密集的CPU任务...)时，建议将应用程序切成模块并减少耦合。 单元测试变得轻而易举，并且在模块之间进行集成测试是一条清晰的道路。 对于taggr ，我大致遵循此处提出的结构。

On top of that, there is performance. The requirements and user expectations on this matter may vary wildly depending on the application that you are building. But blocking the main or render threads with expensive calls is never a good idea.

最重要的是性能 。 在此问题上的要求和用户期望可能会因所构建的应用程序而有很大差异。 但是用昂贵的调用阻塞主线程或渲染线程绝不是一个好主意。

3.设计时要考虑线程模型🧵 (3. Design with the threading model in mind 🧵)

I won’t go too much into detail here – I'm just mainly doubling down on what is awesomely explained in the official docs.

在这里，我将不做过多详细介绍-我只是将官方文档中令人敬畏的解释加倍。

In the specific case of taggr, there are many long-running CPU, GPU, and IO intensive operations. When executing those operations in Electron’s main or renderer thread, the FPS count dips from 60, making the UI feel sluggish.

在taggr的特定情况下，有许多长时间运行的CPU，GPU和IO密集型操作。 当在Electron的主线程或渲染器线程中执行这些操作时，FPS计数从60下降，使UI显得呆滞。

Electron offers several alternatives to offload those operations from the main and renderer threads, such as WebWorkers, Node Worker Threads, or BrowserWindow instances. Each has its advantages and caveats, and the use case you face will determine which one is the best fit.

Electron提供了几种替代方法来从主线程和渲染器线程中卸载这些操作 ，例如WebWorkers ， Node Worker Threads或BrowserWindow实例。 每一种都有其优势和警告，您所面对的用例将确定哪一种最合适。

Regardless of which alternative you choose for offloading the operations out of the main and renderer threads (when needed), consider how the communication interface will be. It took me a while to come up with a interface I was satisfied with, as it heavily impacts how your application is structured and functions. I found helpfull to experiment with different approaches before picking one.

无论选择哪种方法从主线程和渲染器线程中卸载操作(需要时)，请考虑通信接口的方式 。 我花了一段时间才想出一个令我满意的界面，因为它严重影响了应用程序的结构和功能。 我发现在选择一种之前尝试不同的方法很有帮助。

For example, if you think WebWorkers message passing interface may not be the easiest to debug around, give comlink a try.

例如，如果您认为WebWorkers消息传递接口可能不是最容易调试的， 请尝试使用comlink 。

4.测试❌，测试❌，然后测试✔️ (4. Test ❌, test ❌, and test ✔️)

Old news, right? I wanted to add this as the last point, due to a couple of anecdotal ‘issues’ I recently faced. Strongly linked to the first and second points, building your custom starter project and making mistakes early on will save you precious debugging time further in the development.

旧消息吧？ 由于最近我遇到了一些轶事“问题”，因此我想将此作为最后一点。 与第一点和第二点紧密联系，构建您的自定义启动程序项目并尽早犯错将为您节省开发中的宝贵调试时间。

If you followed my recommendations for splitting the app’s UI and Backend into modules with a clean interface between the two, setting up automated Unit and Integration tests should be easy. As the application matures, you may want to add support for e2e testing too.

如果您按照我的建议将应用程序的UI和后端划分为模块，并且两者之间具有清晰的界面，则设置自动化的单元和集成测试应该很容易。 随着应用程序的成熟，您可能还希望添加对e2e测试的支持。

GPS位置提取🛰️ (GPS location extraction 🛰️)

Two days ago, while implementing the GPS location extraction feature for taggr, once the unit tests were green and the feature worked in development (with Webpack), I decided to try it in the production environment.

两天前，在为taggr实现GPS位置提取功能时，一旦单元测试变为绿色并且该功能在开发中(使用Webpack)正常工作，我决定在生产环境中尝试该功能。

While the feature worked well in development, it failed miserably in production. The EXIF information from the pictures was read as binary and processed by a third-party library. While the binary information was correctly loaded in both environments (checked with diff), the third party library failed when parsing such data in the production build. Excuse me, 😕?

虽然该功能在开发中运行良好，但在生产中却惨遭失败。 图片中的EXIF信息被读取为二进制，并由第三方库处理。 虽然在两种环境中都正确加载了二进制信息(已使用diff进行了检查)，但在生产环境中解析此类数据时，第三方库失败。 对不起，😕？

Solution: I found out that the encoding settings in the development and production environments set by Webpack were not the same. This caused the binary data to be parsed as UTF-8 in development but not in production. The issue was fixed by setting up the proper encoding headers in the HTML files loaded by Electron.

解决方案 ：我发现Webpack在开发和生产环境中设置的编码设置不相同。 这导致二进制数据在开发中被解析为UTF-8，而在生产中则不被解析为UTF-8。 通过在Electron加载HTML文件中设置正确的编码标头可以解决此问题。

时髦的图片🕺 (Funky pictures 🕺)

When manipulating and working with images, you may think that if a JPEG ‘just-works’ on your computer, it is a valid JPEG. Wrong.

在处理和处理图像时，您可能会认为，如果JPEG在计算机上“正常工作”，则它是有效的JPEG。 错了 。

While working with the Node image processing library sharp, resizing some JPEG images crashed the app. After looking closely, the cause was incorrect JPEG images generated by Samsung firmware. 🤦‍♂️

在使用Node图像处理库sharp时 ，调整某些JPEG图像的大小会使应用程序崩溃。 仔细查看后，发现原因是三星固件生成的JPEG图像不正确。 ♂‍♂️

Solution: setting up improved error boundaries in the app (ex. try-catch blocks), tweak the JPEG parsing module, and suspect of everything. 🕵️

解决方案 ：在应用程序中设置改进的错误边界(例如try-catch块)，调整JPEG解析模块，并怀疑所有内容。 🕵️

摘要 (Summary)

The Node and JavaScripts ecosystems are blooming, with many powerful tools being created and shared every day.

Node和JavaScript生态系统蓬勃发展，每天都会创建和共享许多强大的工具。

The amount of options makes it hard to choose a clear path to start building your new awesome Electron app. Regardless of your frameworks of choice, I would recommend focusing on the following:

大量的选项使您难以选择清晰的路径来开始构建新的出色的Electron应用程序。 无论选择哪种框架，我都建议重点关注以下内容：

1. Start small and add complexity incrementally.

   从小处着手，逐步增加复杂性。

2. Mindfully structure your app, keeping backend, and UI concerns modularized.

   精心构建应用程序 ，保持后端和UI模块化。

3. Design with the threading model in mind, even when building small apps.

   即使在构建小型应用程序时，也要牢记线程模型进行设计 。

4. Test and test again, to catch most of the errors early on and save headaches.

   再次进行测试 ，以尽早发现大多数错误并避免头痛。

Thanks for sticking around until the end! 💪

感谢您一直坚持到最后！ 💪

taggr is a cross-platform desktop application that enables users to rediscover their digital memories while keeping their privacy. Open-alpha is coming soon to Linux, Windows, and Mac OS. So keep an eye on Twitter and Instagram, where I post development updates, upcoming features, and news.

taggr是一个跨平台的桌面应用程序，它使用户可以重新发现其数字记忆，同时又保持其隐私 。 Open-alpha即将在Linux，Windows和Mac OS中使用。 因此，请留意Twitter和Instagram ，我会在其中发布开发更新，即将发布的功能和新闻。

翻译自: https://www.freecodecamp.org/news/lessons-learned-from-electronjs/

electron.js