# 用可重用函数替换通用验证
javascript 和 typescript 开发人员经常发现自己重复编写相同的条件。如果您是一名 web 开发人员,您可能遇到过如下代码:
const handlesavetextkeydown = (event: keyboardevent) => { if (event.key === 'enter') { //... save text }}
在这种情况下,event.key 是字符串类型,例如,如果不小心在“enter”中包含空格,很容易引入错误。
为什么不将这个条件封装在一个函数中?
const handlesavetextkeydown = (event: keyboardevent) => { if (checkisenterkey(event.key)) { //... save text }}
这确保了对 enter 键的所有检查都是一致且可靠的。
现在,考虑这个验证:
type value = null | object;const value = {} as value;if (typeof value === 'object') { value; // value type is null | object}
尽管 typescript 很智能,但条件内的值仍然是 value 类型。这是因为 typeof null 返回“object”。
所以,你需要写:
if (value !== null && typeof value === 'object') { value; // value type is object}
很多开发者遇到这种情况可能不会将其封装成函数,而是重复编写。
你一生中写过多少次同样的情况?
你犯过多少次同样的错误?
同样的条件你以后还会写多少次?
如果是我,我会这样做:
if (checkisobject(value)) { value; // value type is object}
将通用条件封装在函数中有很多好处。
考虑以下示例:
const array = [0, 1, 2, 3, 4, 5, null, undefined];
让我们创建一个仅排除空值的数组。
您可以优先考虑简洁性并这样写:
const numbers = array.filter(boolean);
不幸的是,这并不理想。 0 也被评估为 false 并被排除。所以你需要写:
const numbers = array.filter(item => item !== null && item !== undefined);
这不是感觉很丑陋、不可重用的代码吗?
我可以写出更优雅的代码:
const numbers = array.filter(checkisnullish);
停止重复编写通用条件。它只会导致错误,并且代码的可读性会降低。
让我介绍一下我创建的一个名为 checker 的库。
这个实用函数库将一般 web 开发和低级开发中常用的条件表示为函数。所有函数都接受输入并返回布尔值。
在撰写本文时,它提供了丰富的函数来处理字符串、数字、布尔值和空值等数据类型。所有功能都经过测试、记录,并且易于开始使用。
让我们看一些现实世界的例子。
该库提供的包全部发布在jsr上。它们可以轻松安装在 npm、pnpm、yarn、bun 和 deno 项目中。
这里,我们以 npm 的 @checker/string 包为例。
- 安装软件包
在项目目录中运行以下命令:
npx jsr add @checker/string
- 使用功能
import { checkIsNotEmptyString, checkIsIndexFound } from "@checker/string"; const value = "Hello"; const formatted = value.trim(); if (checkIsNotEmptyString(formatted)) { // formatted !== '' // When formatted is not an empty string } const index = value.indexOf("el"); if (checkIsIndexFound(index)) { // index !== -1 // When "el" is found in value }
我不喜欢使用像 !some_condition 这样的逻辑否定运算符来反转布尔值。这是因为它是隐式的,简单地通过添加或省略它来反转布尔值可能会导致许多危险的情况。
因此,所有函数都定义了相应的 checkisnot~ 函数。
将通用条件封装在函数中。这样,代码变得更具可读性,错误也更容易发现。
感谢您的阅读。