函数式编程中如何在应用内暴露部分应用的验证器？

你遇到的这个问题在函数式编程圈子里真的很常见——既要守住纯函数的底线，又不想被层层传递依赖的“参数地狱”烦死。下面几个函数式思路能帮你平衡这俩需求：

1. 函数式依赖容器（闭包封装） #

你可以搞个专门的模块，用闭包把配置好的验证器藏起来，同时提供获取它们的接口。这种方式既不会污染全局变量，又能让其他模块像导入一样方便地拿到已配置的验证器。

示例代码：

// validators/configured.js
import { Lib } from 'lib';

// 用闭包存配置后的验证器，初始是null
let configuredValidators = null;

// 初始化函数，在应用启动的时候调用一次
export const initValidators = (messages) => {
  configuredValidators = Lib.configure(messages);
};

// 通用的验证器获取函数
export const getValidator = (name) => {
  if (!configuredValidators) {
    throw new Error('先调用initValidators配置验证器啊！');
  }
  return configuredValidators[name];
};

// 也可以给常用验证器单独写个快捷获取函数，用起来更爽
export const getExampleValidator = () => getValidator('exampleValidator');

应用启动时配置：

// app.js
import { initValidators } from './validators/configured';
import appMessages from './messages';

// 先配置，再启动应用
initValidators(appMessages);
// ... 启动你的应用逻辑

其他模块使用：

// form.js
import { getExampleValidator } from './validators/configured';

const validateForm = (data) => {
  const validate = getExampleValidator();
  return validate(data.value);
};

优缺点：

• 优点：用起来和直接导入差不多方便，配置逻辑集中管理。
• 缺点：要是忘了先调用initValidators就会报错，得确保初始化时机正确；函数不再是严格纯函数（因为依赖了闭包里的可变状态），不过这个副作用只在初始化时发生一次，后续使用没毛病。

2. Reader Monad（纯函数式的上下文传递） #

要是你死磕纯函数的纯净性，那Reader Monad绝对是函数式里处理依赖注入的标准操作。它就像给函数配了个“随身口袋”，把配置好的验证器放在这个口袋里，函数要用的时候直接从口袋里拿，不用每次都把口袋当参数传过来传过去。

示例代码（你可以用Ramda这类库的Reader，也可以自己实现个简单版）：

// 简单实现一个Reader Monad
const Reader = (run) => ({
  run,
  map: (f) => Reader((ctx) => f(run(ctx))),
  chain: (f) => Reader((ctx) => f(run(ctx)).run(ctx))
});

Reader.of = (x) => Reader(() => x);
Reader.ask = () => Reader((ctx) => ctx);

// 创建验证器上下文
const createValidatorContext = (messages) => ({
  validators: Lib.configure(messages)
});

// 把需要验证器的函数用Reader包裹起来
const validateForm = (data) => Reader.ask()
  .map((ctx) => ctx.validators.exampleValidator(data.value));

// 应用启动时创建上下文，然后运行Reader
const appContext = createValidatorContext(appMessages);
const formValidationResult = validateForm(formData).run(appContext);

优缺点：

• 优点：完全保持函数的纯净性，依赖是显式的但不用层层传递，用Monad统一处理上下文。
• 缺点：有一定学习门槛，得让团队先搞懂Monad是什么；代码会多一层Reader的包裹，简单场景下可能显得有点啰嗦。

3. 模块级延迟绑定（受控的副作用） #

这种方式最接近你想要的“直接导入”体验——先在模块里导出占位符，等配置完成后再把占位符替换成实际的验证器。不过要注意，这个副作用必须只在应用启动时执行一次。

示例代码：

// validators/index.js
import { Lib } from 'lib';

// 先导出个占位符，没配置就调用会报错
export let exampleValidator = () => {
  throw new Error('先调用configureValidators配置验证器！');
};

// 配置函数，替换占位符
export const configureValidators = (messages) => {
  const configured = Lib.configure(messages);
  exampleValidator = configured.exampleValidator;
};

应用启动时配置：

// app.js
import { configureValidators } from './validators';
import appMessages from './messages';

// 先配置，再启动应用
configureValidators(appMessages);

其他模块直接导入使用：

// form.js
import { exampleValidator } from './validators';

const validateForm = (data) => exampleValidator(data.value);

优缺点：

• 优点：使用体验和直接导入原生验证器完全一样，代码超简洁。
• 缺点：模块级变量是可变的，违反了函数式编程的不变性原则；要是不小心多次调用configureValidators会覆盖之前的配置，得确保配置只执行一次。

总结一下 #

• 要是优先考虑便捷性和低学习成本，模块级延迟绑定或者函数式依赖容器是首选；
• 要是严格遵循纯函数原则，Reader Monad是最符合函数式精神的方案；
• 不管选哪种，都要确保验证器的配置只在应用启动时执行一次，避免运行时的意外坑。

内容的提问来源于stack exchange，提问作者Undistraction