umi + antd-pro 精简化流程

深度使用 antd pro 和 umi 的组合之后,我想自己对这个框架进行控制,脚手架搭建出来的那些乱七八糟的就不要了。在精简过程中,有一些小技巧,故记录在此。

安装 umi

npx @umijs/create-umi-app

安装插件

想在菜单中用字符串指定 icon 需要安装 umi-plugin-antd-icon-config 这个插件进行转换。

修改配置

config/config.ts

import routes from './routes';

import { defineConfig } from 'umi';
export default defineConfig({
  // https://github.com/umijs/umi-plugin-antd-icon-config
  plugins: ['umi-plugin-antd-icon-config'],
  nodeModulesTransform: {
    type: 'none',
  },
  routes,

  fastRefresh: {},
  dva: {
    hmr: true,
    immer: true,
  },
});
继续阅读umi + antd-pro 精简化流程

浅谈技术八股对开发者的危害

Photo by Evgeny Ozerov on Unsplash

虽然不在 IT 行业,但是大大小小加了不少微信群,关注了不少技术公众号,目前普遍的趋势是,技术面越来越卷。面试 Java 的,面试官恨不得 JVM 是你写的,面试前端的,恨不得框架是你写的、标准是你定的。这种风气不断蔓延开来,小厂也纷纷效仿,更有趣的是不少开发者也竟将技术八股奉若圭臬,开源了不少面经之类仓库。暂且不说,对于管理者来讲这种做法能不能招到真的有能力的开发者。对于开发者来说,我认为,技术八股对不仅对思维提升没啥好处,还会带来不少危害——自我否定和限制发展。

自我否定

先来看看考察的内容吧。面试大多是解释器原理、框架原理等,但是有多少人真的做到这个层次的开发,大多数都是针对业务来做的应用层开发。熟读八股花了大把精力,能上岸还好,否则只是白白损失了精力,丧失自信力罢了。

继续阅读浅谈技术八股对开发者的危害

独立开发的一些体会

快速上线

独立开发完成一个功能就要上线,这是非常重要的。这是因为线上环境涉及到虚机性能、网络带宽这些硬件因素,快速上线可以即使针对这些客观因素即使调整代码。

如在本地加不加分页都不影响使用,但是线上可能就会明显感到时延;本地落库数据库可能没有影响,但是线上可能落库时间较长需要做异步处理等。

渐进式开发

个人能力有限,在每个阶段都要专注于主要的业务或者功能。如一开始项目没上线,可能就不需要日志文件或者配置文件,先完成关注的业务就行。

技术文章分类

Photo by rashid on Unsplash

找准定位,深度挖掘需求,以做产品的方法打造出来的技术文章必定是好文章。这篇文章算是我对常见的技术文章分类以及如何写好对应的技术文章的一点总结。

源码级别的探究文章

假如这篇是源码级别的探究文章,那么你的读者往往是具有相当功力或者有探究好奇心的技术达人,他们可能是想搞懂这个实现的原理,那么最直观的流程图是少不了的,可以一下子抓住眼球,理清思路,然后针对流程中的关键环节进行击破。这个源码探究我很少形成详实文字,毕竟曲高和寡,而且市面上类似八股已经形成大量可以记忆的知识点,并不能起到多大的贡献。

继续阅读技术文章分类

为什么我推荐 Antd Pro + Umi

Photo by Vincent van Zalinge on Unsplash

React 生态很神,套娃框架很丰富,比如 antd pro 组件库和 umi 开发框架。这段时间,经过深度的使用,我对这个框架的也越来越喜爱。因为它解决了独立开发者最关心的效率和代码质量的问题。

效率很好理解,代码质量可能有人有些疑问,一般的理解是代码质量可能是多人协作需要考虑的事情,实则不然,根据我独立开发多年的经验,作为独立开发者,很多时候无法知道自己代码是被合理的组织的。如果任凭代码随意组织,在后面迭代中也会影响业务上线效率。

为了解决这个问题,我往往需要看别人的代码学习一些经验,这个会耗费比较多的时间。而 umijs 从阿里的业务中提取除了很好的实践,使用插件和配置形式很好的组织了前端代码,让开发更加关注业务本身。

React 状态机使用感受

Photo by erik cid on Unsplash

上手 react antd 之后,按照官方推荐的套娃框架 umi 和 antd pro 配合搭建了目前的项目。其中 umi 又可以使用 dva 状态管理框架进行数据流管理。

一开始我的认为是这个东西比较麻烦使用起来不太顺手,并且解决不了什么问题。但是现实是在我的项目里有很多组件共用的数据,不用状态管理会让代码显得非常冗余。学习了 dva 之后发现套娃框架非常适合上手,也精简了不少代码。

状态管理的核心是拆分状态。一开始我综合了知乎的一些回答,认为若组件之间有大量的共享数据,那么就可以使用状态机管理数据可以精简非常多的代码。但是实际来说需要针对具体的问题具体解决,不限于组件共享思路。

比如我这边有个分页功能,假如我的数据获取已经放在副作用 effect 去完成,那么数据的分页数据和分页信息都要放到状态去管理,否则就又会涉及到 state 的编码和 dispatch 的回调,会四不像。

产品随想

最近痴迷曾国藩传,试想读一些近代史相关的书籍,但是发现手头没有相关产品的。作为用户,我希望有一款可以输入一本书然后关联出所有相关知识点的工具,类似知识图谱。

这个工具比较适合 Web 大屏幕来展现。

暂时那么多。

哦又是this——浅谈 React 事件绑定

Photo by Jeremy Zero on Unsplash

在使用 React JSX 事件绑定中有个最大的问题是它不会帮你处理 this 的指向问题。我刚刚上手的时候有些疑惑,看了教程之后豁然开朗。

React 事件绑定的需要和显示的修改对应事件处理函数的 this 的值。这主要是因为 Babel 开启了严格模式。若这个函数 this 指向没有改变,直接赋值给 onClick,那么函数体内的 this 仍是 undefined 。为此需要使用 bind 函数来修改函数体内的 this 指向。比如下面这段代码 :

import React, { Component } from "react";

class test extends Component {
  test() {}
  render() {
    return <div onClick="this.test.bind(this)"></div>;
  }
}

export default test;

对于一个类组件,this 指向的是类的实例,this.test 方法会沿着原型链找到类中定义的 test 方法,然后将这个类方法中的 this 替换为当前实例对象。这样一来, test 方法中的 this 就可以当前实例对象的值。

另一种方法是将 test 写出箭头函数的形式。这里有两个含义。首先 test = func 的形式,test 就是一个实例属性,但是这样仍然没有改变这个直接调用时函数内部的 this 的指向。但是假如写成箭头函数的形式,箭头函数中的 this 会使用实例对象的 this,如下所示。

import React, { Component } from "react";

class test extends Component {
  test = () => {};
  render() {
    return <div onClick="this.test.bind(this)"></div>;
  }
}

export default test;

对应视频教程

bind https://www.bilibili.com/video/BV1wy4y1D7JT?p=16

箭头函数 https://www.bilibili.com/video/BV1wy4y1D7JT?p=18

模块化工程杂感

Photo by Michael Scherback on Unsplash

为了更好的分解大规模的代码,包(package)的概念就产生了。包可以隔离命名空间,消除函数变量的命名冲突。一般的做法是,相同包下的文件都会放在在一个文件夹下。针对这个习惯,Python 在文件夹下定义__init__的方法来组织下面的小文件,JavaScript 的模块系统基本也是这个思路。

和这两者不同, Golang 不在单独在文件夹下指定一个导出文件,而是直接使用关键字 package 来指定,同时摒弃了文件导入这个概念,包为导入的最小单位。这样一来,同一个包内的各个文件可以直接使用而无需再次引入。而包外部的代码想要使用包内代码必须是显示的调用。这和它们家 Angular 的模块是一个思路。而导出文件的作用被大小写导出的内容所取代。

自我介绍

2016年6月计算机硕士毕业之后进入移动地级市公司工作。原本以为国企铁饭碗很香,也没想到那么快会对这份工作失去兴趣。每日的工作主要是取数和资产管理类工作,中间穿插大大小小的培训,这样的形式很快让我产生了倦怠和厌恶,

17年5月离职去了另一家相对轻松的国企做数据库管理工作。和上一份工作相比,这份工作显然轻松了很多,每天基本就是看数据库相关的技术书籍,在这个阶段中也迷茫过,但是没有放弃知识的摄取。

18年8月,运气使然上岸体制内某一事业单位,开始接触全栈开发的相关内容至今。这个时期开始基本是最艰难的开始。所有知识全部通过自学完成,但也感谢这段经历,让我在这个阶段基本沉淀了一些自学编程自学的方法和思路。

你现在所看到的个人博客也是从18年12月底开始搭建的,起初是想做知识搬运,翻译文章来获取流量,但是发现对自我提升实在太少,于是静下心来学些一个个项目。经过不断的折腾,用 Python、Nodejs、Go、C# 都做过工程,目前沉淀下来的基本思路是,前端框架 React,后端框架 Gin,机器学习 Python。

看自己走过的这段路,的确是有点曲折,但是不曾后悔。因为我既尊重了自己的兴趣,又在工作和生活上做到了一个平衡。在一个三线的城市,可能这条路也是无奈之举,一个可行的生存状态可能都是回归体制,然后在此之上利用自己所学,创造更多的机会。