场景由于 electron 应用分为主进程、渲染进程，所以它们之间需要通信。而 electron 本身实现了一个简单的 event emitter 通信模型，虽然能用，但并不足够好。 参考: https://www.electronjs.org/docs/api/ipc-renderer 问题 基于字符串和约定进行通信本质上和当下前后端通信差不多，没有利用同构优势 使用起来没有任何限制，意味

场景 吾辈是一只在飞向太阳的萤火虫 JavaScript 中的数组是一个相当泛用性的数据结构，能当数组，元组，队列，栈进行操作，更好的是 JavaScript 提供了很多原生的高阶函数，便于我们对数组整体操作。然而，JavaScript 中的高阶函数仍有缺陷 – 异步！当你把它们放在一起使用时，就会感觉到这种问题的所在。 例如现在，有一组 id，我们要根据 id 获取到远端服务器 id 对应的值

场景有时候需要与其他程序进行交互时，自定义协议是一个不错的选择 – 它能在程序为启动时启动程序然后处理其它程序的动作，而这是其它解决方案，包括 HTTP 请求、共享数据库不能比的。其实日常生活中也有现成的例子，迅雷的自定义协议下载链接、BitTorrent 协议、百度网盘启动本地客户端等等。 使用 参考: 将当前可执行文件设置为协议的默认处理程序（注册表级别） 让程序保持单例启动 设置客户端支

距离提出离职已然过去三周了，但现在仍未找到合适的工作。也不是没有面试过，但确实没有找到合适的 – 对于吾辈而言，合适指的是优秀的 team，最好是平台而非业务 team。 吾辈也找到了一些大佬帮忙内推，包括 快手 基础平台建设 百度 YY 直播 腾讯 微众银行 阿里云 DataV 数据可视化 但最让吾辈感觉难过的不是面试之后因为能力不足而失败，而是即便内推也仍然没有面试的机会。当然吾辈也能理解

当今世界上不同国家社会和国民文化中的犬儒主义可以分为两大类:公开的犬儒主义和戴面具的犬儒主义。它们的基本区别在于,当一个人因为犬儒主义而不相信统治意识形态、制度、权威、信仰体系以及由权力或习俗规定和主导的法律或价值规范时,尤其是怀疑和鄙视政府、政治权力和政治人物的时候,公开的犬儒主义会在公共言论和行为中表示出来,而戴面具的犬儒主义则通常不会,不仅不会表示不相信,而且还会假装成相信的样子。公开的犬

场景有时候我们需要在主进程和渲染层共享某些数据，而 electron ipc 通信 显然更适合传递消息而不适合共享数据。 相关依赖事实上，我们这个需求已经有人考虑过了，例如 electron-store 就已经实现了可以在渲染层、主进程均可使用。 is-electron: 判断是否 electron 环境 electron-store: 在 electron 应用中存储数据 那么，我们直接用

技术栈 electron: 跨平台桌面开发 react: 视图层框架 typescript: 强类型的 js lerna: 前端 monorepo 管理工具 yarn: 包管理器，workspace 与 lerna 搭配非常好 create-react-app: react 官方出品的 react 脚手架生成器，社区和活跃度都不是其它工具可比的 其他依赖库 参考: 前端资源管理 rollup

场景最近在生产环境遇到了下面这样一个场景：后台在字典表中存储了一些之前需要前后端共同维护的枚举值，并提供根据 type/id 获取字典的 API。所以在渲染列表的时候，有很多列表的字段直接就是字典的 id，而没有经过后台的数据拼装。 也是吾辈之前写的文章 react 通用列表组件封装 中的那个通用列表在实际使用时遇到的问题之一。 起初，吾辈解决问题的流程如下 确定字典字段，添加转换后的对象类

场景 之前吾辈也在 SF 上询问过 类似的问题。 目前在实际业务中遇到了两种情况 程序的功能在分发给不同组织使用的时候有所差异，即不同的组织都会存在一些定制化的功能。最常见的差异例如 表单的字段存在差异 列表展示的字段与相关操作有所不同 组件内的代码在某个权限下才会执行，但是又依赖于组件内的一些状态，如何将这些代码分割到不同的地方（例如不同的文件）便于之后的维护。 一些按钮在指定权限下存在

场景 曾经吾辈以为 ES6 早已推广开来，然而事实上远比想象中更加复杂。传统后台的项目就是要兼容性，兼容 2 年前的浏览器，没有 babel，全程 jQuery 一把梭做到底。 之前的项目基本上都是前后端分离的模式，最近新公司的项目却是使用的传统的模板视图的模式。所以，一些东西发生了变化 thymeleaf 模板里面直接有 Java 的代码，在服务端直接编译 html 代码而非是纯粹的 API

场景长期以来，吾辈通过 RSS 阅读各种 blog，想要评论时却发现很麻烦，所以来推荐一下 blog 的评论系统。 评论系统大概有如下几种形式 基于第三方评论服务 输入名字邮箱即可发表评论 注入博客用户才可以发布评论（没怎么用过，不予置评） 优缺点对比基于第三方评论服务这里选择的是吾辈目前正在使用的 disqus，而评论选择是某位博主的评论系统。 两者截图如下 对比项 基于第三方评论服

前言在 基本项目搭建 中，我们已经能够启动一个 electron 应用程序了（开发环境），现在来看如何将之打包为二进制程序便于分发给最终用户。 依赖 electron-builder: 打包的主要工具库，负责这个 electron 的跨平台打包工作 事实上，还有一些其它的打包工具，但目前还没有比它更好的，参考: https://npmcompare.com/compare/electron-bui