在表单字段模型中存储/翻译静态错误字符串是不好的做法吗？

Question

我正在构建一个Flutter应用程序，其中有一个注册表格，如果用户输入无效的电子邮件，将会出现错误。

我有以下电子邮件表单字段的模型（使用 formz package）：

enum EmailFieldValidationError { empty, invalid }

class EmailField extends FormzInput<String, EmailFieldValidationError> {
  const EmailField.pure() : super.pure('');

  const EmailField.dirty([String value = '']) : super.dirty(value);

  static final RegExp _emailRegExp = RegExp(
    r'^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$',
  );

  @override
  EmailFieldValidationError? validator(String? value) {
  }

  String? get errorText {
    if (error != null && !pure && value.isNotEmpty) {
      switch (error) {
        case EmailFieldValidationError.invalid:
          return 'Invalid email.';
        default:
          return null;
      }
    }
    return null;
  }
}

这使事情变得非常简单。现在，当我想在textformfield（）下有条件地显示错误消息时，现在在我的小部件中，但是在我看来，这就像在考虑本地化（我想稍后再添加到应用程序）中的不良练习中幻影将要求我将buildContext用于 build 而不是错误字符串。像这样：

  String? buildErrorText(BuildContext context) {
    if (error != null && !pure && value.isNotEmpty) {
      switch (error) {
        case EmailFieldValidationError.invalid:
          return AppLocalizations.of(context)!.emailFieldInvalidValueError;
        default:
          return null;
      }
    }
    return null;
  }

鉴于我需要实例化buildContext并在我的本地化类中进行配置，以便能够测试此表单字段模型，因此我认为这里关注点的分离很差。

我认为最初为我的表单本身中的表单字段模型生成错误文本是一个好主意。这主要是为了避免重复代码。但是，在本地化成为我的应用程序的不错之后，这成为一个问题，我遇到分析瘫痪阅读/考虑从模型类中静态字符串生成的不同选项，同时避免我的原始重复代码问题。

在这里，任何想法都将不胜感激。

Answer 1

我最终制定了一个简单的解决方案，并且由于我没有得到任何可行的答案，所以这是我的解决方案。如果有人能够验证或提供反馈以进一步改善它，那就太好了。

我基本上创建了一个新的“通用”小部件，以简单地基于给定的emailfield值渲染textformfield。如果当前值有任何错误，它将基于错误类型渲染适当的错误字符串：

class CommonEmailFormField extends StatelessWidget {
  const CommonEmailFormField({
    Key? key,
    required this.email,
    this.onChanged,
  }) : super(key: key);

  final EmailField email;
  final Function(String)? onChanged;

  String? get _errorText {
    if (email.error != null && !email.pure && email.value.isNotEmpty) {
      switch (email.error) {
        case EmailFieldValidationError.invalid:
          return 'Invalid email.';
        default:
          return null;
      }
    }
    return null;
  }

  @override
  Widget build(BuildContext context) {
    return TextFormField(
      initialValue: email.value,
      onChanged: onChanged,
      decoration: InputDecoration(
        labelText: 'Email *',
        errorText: _errorText,
      ),
    );
  }
}

我将摘要简化为简洁，并且要点。您可以查看实际实现在这里。

一旦我开始添加本地化，​​它将需要我更改_errortext getter从buildcontext getter读取静态局部化字符串，但这仍然是代码驱动UI行为并保持分离的代码关注。

无论如何，该解决方案解决了我的主要问题：

1. 不必要的测试复杂性。现在，我不需要设置UI buildContext就可以在添加本地化后能够测试字段模型。
2. 重复代码。我可以在其他地方重复使用这个常见的小部件。
3. 关注点的分离。专门驱动UI/视图行为的代码与驱动模型行为的代码很好地分开。此弯曲简化了测试。