Press "Enter" to skip to content

刘建文 | Nakeman.cn Posts

如何使用偏函数技术提高代码的可读性

对刚接触JS的人来,「偏函数」是一个让人困惑的概念,其实「偏函数」指代的不是一个特殊功能的函数,而是 一种有目的函数式编程(功能编程),这个目的可概述为,将一个目标函数 Fo“偏化”(什么叫偏化,本文后面会讲),简化对Fo的调用(Fo功能的使用),从而提高代码维护质量。

与偏函数一样高度相关的,同样让新手困惑的是,柯里化函数。它们的相关在于,都是对一个目标函数Fo进行某种改造,只是改造的目的不同。

理解偏函数和柯里化函数的实质 需要很多基础,偏函数是柯里化函数的理解基础(例如参数application),而「高阶函数」是它们的基础,更基础的是「函数式编程」,当然还有一个终极的基础,「编程」是什么。

函数式编程 是一个很大的题目,不容易讲清楚;「编写高阶函数」是 函数式编程 的重要特征,同样高阶函数也需要很多解释。但是,我们可以从以他们为基础的应用技术——偏函数技术——的实例,比较具体的了解函数式编程的实质和意义。

关于偏函数技术的应用例子,我自己不写,略译此文《How to use partial application to improve your JavaScript code》作为引子。

Featured

有效评估JS开发者软实力的十条面试题

为了顺利的再进职场,最近一个月来都在做有目的训练,训练自己的实操能力(因为这是我的一个弱项——前端项目经验薄弱,加上在特长上,编码和分析更倾向后者),而不是任意的自由的学习。然而,在具体的学习主题上,除了参考和对比常规面试题,找出一些基础主题外,对什么是“最有价值”的学习主题,我没有指引。

其实我一真很相信自己的直觉,但是难免有盲区,和价值冲突,我不清楚明天面对面的考官他希望我具备什么能力。我的担心不是没有原因的,因为软件开发技术岗位向来都是既难招亦难找,企业不知道怎么考核应聘者实力,求职者不知道学什么最重要。

这里边有一个推理,在面试和通过面试的情景里,假设把企业,和求职者分两类:

  • 企业 分为懂得评估技术岗位(C1),和缺乏评估技术的企业(C2)
  • 求职者分为有实力但不懂求职技巧的(P1),实力很弱但是刷题是高手(P2)

那么会出现四种面试情况:C1P1 C1P2 C2P1 C2P2

如果假设成立,那么通过面试的只有 C1P1 和C2P2,但是真正算成功面试只有C1P1,因为只有这种结合才是良性的。

JS闭包和构造函数对比研究

闭包(或闭包函数)的概念在JS社区讨论的频率异常的高,有人甚至 把闭包原理看作像是外语里语法的那样重要。闭包的确是JS开发的基石(之一),然而它的基础作用为何,可能还需进一步廓清。

有一定OOP基础的人一定会发现,闭包函数和构造函数(必须使用new操作符的JS函数)的性质和意义,有点相似。本文尝试分析它们的共通和不同的地方,以期达到深刻认识闭包的意义。

源起

最近半个月一直在为重新出山面试作准备,在完成Promise(异步编程)的研习后,我又回到了JS 的基础复习中,其中的研习主题都是围绕着闭包、高阶函数、柯里化,和函数式编程。在这个过程,我开始酝酿着一种新看法,闭包,高阶函数,柯里化这些概念或技术都是以 「函数是一等公民」为前提的,它们都是在 「把函数作值处理的 」技术(请将它和 以数据作值处理相比较)。这种现象应该是 函数式编程范式的表现,目前我还没有对这种 「把函数作值处理的 」现象总结出完整的结论(初步使用「功能编程」概括之),研习还在进行中,不过我已经将它们进行归类,并且辨识出它各自的意义:

功能编程中功能制造的种类
功能编程中功能制造的种类

这里有一类首先引起了我特别的注意,就是创建新的一类。

JS语言是不是面向对象的?(二)

最新的编程技术研究成果:2020-10-25

  • 第一,OO和FP都是 程序构造术,两种都使用了抽象,但不同的思想范型;
  • 第二,构造过程分为,功能编程,和结果编程两步;
  • 第三,(两种)程序构造术 都为解决复杂性,通用协作,和复用达到这个意义目标;

阐述的步骤

1 为什么要面向对象
2 什么是面向对象
3 面向对象的标准特征是什么,
4 JS有没有,以及如何实现这个特征。

为什么要 面向对象

1 针对 事务应用程序 (数据量大,代码重复率高)的程序特点而设计的构造术
2 特点是思维粒度适中,易编写和阅读维护

React 开发中的代码复用技术:继承、构成、装饰和混入

(本文略译自《 Reusable Code In React: Inheritance, Composition, Decorators and Mixins》)

React 是我用过的最好用的UI库,如果你能突破传统旧Web开发观念,并熟悉了 React 的观念和开发模式一定会同意我的看法。好用的最主要原因,是 React 支持数种 代码复用 技术。本文将介绍 React 如何支持 四种代码复用技术,我们以一个计数器(counter)UI作为例子讲解。

Inheritance

继承或类继承 是 传统面向对象构造术 的最主要 代码复用技术。对于像 有Java 背景的人来说,继承是非常熟悉的,但是对JS开发者来说,则是相对陌生一点。类继承技术的特征是,对 某既有的类 进行功能扩充,包括数据或方法[em]

React refs使用指南

(本文略译自《A guide to React refs: useRef and createRef》)

本文,我们将探究React的一个设计——全面抽象封装了DOM的操作,又开了一个小门给开发者直接操作DOM。

作为新的第二代UI库,React将DOM的操作进行抽象封装,引入了一种新的开发模式——SPA由一个个带状态的 View组件 组成,开发者将 交互功能 理解成 View的状态的变更 的结果[em],这个观念改变是突变的。

EM:View的状态(state)或形式(props)变更都会触发重渲染,都会产生 某种交互输出的效果(交互功能的实现),但性质完成不同。从名字上就可以看出来,一个是交互计算(state),一个交互辅助(props),例如用props去初化一个新子V,会产生交互输出的效果,但不是交互计算。

当我们习惯了这个新模式后会发现,过往的同样的任务(开发交互功能),使用View组件在 分析设计和实现 上都比较原来 DOM命中模式 更好。

不过,React团队非常的有远见,就像其它代码库作者一样,想到了:为特殊情况开一后门(逃生门),这扇“逃生门”就是 Refs。

尝试总结SPA V理论解释 React 技术

陆续不断学习React有一阵子了,但对于React 作为一支View库工具,它的技术(工具)特性和和针对的任务都还没有达到一种通透的控制感。这里边,我想除了项目实践经验不多,主要还是我对有关V(SPA V)的理论的不成熟。翻了下研究路经,其实在一个多月前已经对V理论有了相当的归纳:

这里的研究还停留在逻辑的抽象分析,并没有结合React API,对React的工具特性进行解释。最近对React的实际开发任务(包括VV功能制作,和VV功能复用)有了更多的经验,可以进一步推进它了。

JS语言是不是面向对象的?(一)

我计划要写两篇文章。第一篇,阐述JS语言是不是面向对象的,和JS是否支持工程模块化;第二篇,讲一种阅读React源码项目的技术

第一篇,阐述的步骤

  • 1 为什么要面向对象,
  • 2 面向对象的标准特征是什么,
  • 3 JS有没有,以及如何实现这个特征。

同样,

  • 1 为啥要模块化,
  • 2 什么是模块化,
  • 3 以及JS如何做的

怎么阅读一个React SPA WGP源码项目(研究片断)

# 为啥研究源码阅读的技术?

1 读懂是模仿,和创作的前提基础,就像一般人都能阅读文章,但写不出文章,阅读比写作更基础。

2 写文章标志扎实的掌握最近学到的知识和技术

3 阅读的技术,其实对WGP理论和开发技术的掌握程度的检测,和考证

4 阅读(学习)源码,模仿源码(维护项目),和创作(开启新项目),是三种能力水平

React Context API是什么以及基本使用

React Context API 是 针对所谓 状态管理(state management)[em] 而设计的API。 Context API 以一种更直接有效的方式解决了早期使用 props 来处理嵌套UI的状态共享的问题。

EM:单一的V只有状态,没有状态管理,状态管理只有在复合的Vx组件中才有。

那什么是 状态管理呢? Context API 优于props的地方在哪里呢?Context API 又如何使用呢?

本文摘译自《React Context API: Using React Context with APIs effectively》。

UI状态管理技术

实际应用中的React 程序,它的交互UI都是复杂的,有着复杂的嵌套层次关系,这些嵌套的UI组件都需 共享中间计算数据(状态),甚至是计算功能(函数)来实现交互功能。

目前有三种 实现共享中间计算数据 的技术:

第一,是组件的模板参数 props。这个方法最大的优点是直观,缺点是当组件层次较复杂时没有针对性,计算不相关的组件可能会看这个props。还有一个问题,就是props形式参数,它不是用来“通信”共享数据的,有可能螺丝刀当锤子用(待证);