electron 开发经验之谈系列-基本项目搭建 环境 Windows 10 NodeJS 12 WebStorm VSCode(编写 markdown 文档) 创建 lerna 项目创建目录 electron_example,然后使用 yarn 初始化 12mkdir electron_example && cd electron_exampleyarn init -y 修改 package.json 123456789{
electron 开发经验之谈系列-开发环境优化 使用 react devtool 插件调试 前言 虽然绝大多数时候,我们都可以也应该在浏览器调试渲染层的功能,但确实也会有需要在 electron 程序中调试的需求,这里就说明一下 electron 如何安装 chrome 插件 react devtool 调试项目。 核心依赖: electron-devtools-installer 步骤 1、安装依赖 cd 到 apps/main 目录
electron 开发经验之谈系列-自定义窗口顶栏 场景在很多生产项目中,我们希望自定义 electron 窗口顶栏,因为它确实非常简陋。 步骤在渲染层实现自定义顶栏实际上,核心的代码就是添加一个为顶栏的元素添加 css 样式。在 electron 环境,有 -webkit-app-region: drag; 属性的元素可以拖动整个窗口。 123456.toolbar { -webkit-app-region: drag;}.toolbar &g
electron 开发经验之谈系列-自动更新 场景由于生产应用希望在有新版本时,自动为用户推送更新,所以此处便写一下如何让 electron 程序自动更新。 安装 npm 包1cd apps/main/ && yarn add electron-updater 配置 electron-builder 参考: https://www.electron.build/auto-update 其实本质上就是配置一个网络可以访问到的
前端与后端的选择(个人理解) 前言 吾辈就是一个从 Java Web 后端转到前端的人。 吾辈今天又在看到人说 前端很简单,而且还比后端工资高,这里吾辈还是想做一些澄清的。 对话 后端 A: 我发现这两年前端的工作特别好找,而且工资很高 后端 A:后端内卷太严重了。 后端 B: #无语 后端 B: 前端要会啥啊到底才能称得上前端 后端 A: 我们这边。H5+小程序 就行了 后端 A: 主要是 CSS 要能处理好。。。 后端
读书 [浪潮之巅] 简介前些时日,吾辈读完了 [浪潮之巅] 这本书。 它是 Google 开发者吴军所写的 IT 行业各个重要公司的兴衰历史,并进一步探讨了其中的原因。那些曾经无比耀眼的新星,压在每个公司头上的庞然大物,是如何一步步变成这样的。 起因最初是在一位朋友的推荐下了解到这本书的,当然,那位推荐了不少有趣的书籍: 黑客与画家、浪潮之巅、人月神话等。 感想 书中最有趣的一个观点是: 公司是由基因决定的,转基因
CSS Grid 与图片共存时的布局问题 场景在生产中遇到的一个 css 问题,css 不正交的问题一直有人吐槽,吾辈今天总算也是遇到了,实在是不吐不快。 CSS 为什么这么难学? 如下一个简单的二维横向图片列表 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455<style&g
有限状态机 xstate.js 官网, 中文(繁体)教程参考 场景 为什么要引入状态机? 吾辈希望使用有限状态机管理程序中的状态及状态的流转,以避免使用各种 flag + if/else 控制程序的运行。 为什么吾辈会突然觉得 flag + if/else 这种方式不好呢? 原因在于吾辈最近在看设计模式相关的书籍:JavaScript 设计模式与开发实践,其中涉及到了[状态模式],里面就提到了[有限状态机
使用 React Context 结合 EventEmitter 场景EventEmitter 很适合在不修改组件状态结构的情况下进行组件通信,然而它的生命周期不受 react 管理,需要手动添加/清理监听事件很麻烦。而且,如果一个 EventEmitter 没有使用就被初始化也会有点麻烦。 目的所以使用 react context 结合 event emitter 的目的便是 添加高阶组件,通过 react context 为所有子组件注入 em 对象 添加
使用 gh-pages 发布前端项目 场景 gh-pages 之前就有在使用 gh-pages 这个库,但由于名字并未想到它如此强大,甚至支持发布代码到任意 git 仓库。换言之,它可以将任意本地文件发布到远端 git 仓库,而不需要自己处理各种乱七八糟的问题。 问题首先说一下我们之前前后端分离项目的发布流程 修改打包的 webpack 脚本以支持引用 cdn 上的资源(本质上是修改路径) 打包静态资源文件 找到前端静态资源发布项
2016 年里做前端是怎样一种体验 本文转载自 SegmentFault,英文原文在 How it feels to learn JavaScript in 2016吾辈觉得颇为有趣,便转载了一下(也算是前端开发的悲哀之处了吧)附:吾辈觉得至今为止,前端工具链仍然没有好太多,工具链过多导致配置复杂,入门难度极大。附:现在都 2018 了,然而吾辈的公司现在还是用 jQuery,虽然吾辈目前在内部强推了 VueJS #笑哭附:吾辈这
博客迁移 注:可能出现博客文章的顺序完全混乱,但随着笔记的修正将逐渐恢复正确的顺序。 这个博客正在从 github + hexo 迁移至 joplin + hexo,将 joplin 笔记作为唯一数据源,结合 hexo 生成一个网站。 下面是关于 joplin-blog 项目 的介绍 场景你是否和吾辈一样烦恼同时维护笔记和博客的同步麻烦,如果你使用 joplin 作为笔记工具,而使用 hexo 作为博