Как насчет валидации данных?

[konstantin24121]

Собственно вопрос, какую библиотеку для валидации использовать на сервере и клиенте

[DenisIzmaylov]

Хороший вопрос.

@gaperton будут какие-нибудь рекомендации на этот счёт?

[nkt]

joi

[maullerz]

если попроще, то yup

[gaperton]

Мы не используем отдельных библиотек для валидации. Это имхо перебор иметь по отдельной библиотеке для каждого аспекта работы с данными. Валидация - это один из сервисов, которые должны давать "модели" - базовые классы слоя данных.

Простую же валидацию форм можно собрать вообще нейтральным к слою данных образом. Вот так, например.

https://medium.com/@gaperton/react-forms-with-value-links-part-2-validation-9d1ba78f8e49#.irjd8n98t

[gaperton]

А вообще, я плохой советчик для разных бойлерплейтов. Мы в Verizon эти проблемы решаем не подбором коктейлей из разных штук, а разработкой своих. Для нас выходит дешевле иметь контроль над своими технологиями, чем следуя за модой перебирать чужие перетрясая список раз в год. Последнего мы просто не можем себе позволить.

Проблемы валидации, сериализации, наблюдаемого состояния, и вообще всего что в слое данных обычно встречается, у нас решены одним интегрированным фреймворком - NestedTypes. Как его разработчик - могу посоветовать его.

[alexpts]

Простая штука - https://github.com/skaterdav85/validatorjs (другая реализация этой же штуки - https://github.com/ratiw/Validator) Удобно тем, что сразу описывается набор правил компактно на весь объект.

[gaperton]

Простая штука - https://github.com/skaterdav85/validatorjs

Уже выглядит как определение схемы. Вот это, например:

var nested = {
  name: 'required',
  bio: {
    age: 'min:18',
    education: {
      primary: 'string',
      secondary: 'string'
    }
  }
};

Штука в том, что из "схемы" можно извлечь очень много полезного, не только валидацию. Этот пример будет записан у нас в NestedTypes вот это:

@define
class MyNestedData extends Model {
  static attributes = {
    name: String.isRequred,
    bio: Model.define({
      age: Number.integer.has.check( x => x >= 18 ),
      education: Model.define({
        primary: String,
        secondary: String
      })
  }
};

Не менее простая штука. Только помимо валидации умеет делать кучу других полезных вещей. Например, определять изменения в глубине и уведомлять о них ("deeply observable" объекты), делать "реактивные изменения" ("если изменилось вот это поменяй рядом вот это") и изменяться при этом транзакционно (для наблюдателя это будет как одно изменение), правильно сериализоваться, глубоко копироваться, синхронизировать состояние этих ветвистых объектов в одну строку, и делать двухсторонний data binding в React. Ну и заодно REST endpoint-ом моет прикинуться, если ему root url сказать.

Все это бесплатно. Вся необходимая для этих фокусов информация извлекается из схемы.

Это я к тому, почему идея "стандартного бойлерплейта" состоящего из десятков фиговинок представляется мне ошибочной. Если уж речь идет о чем-то "стандартном", то нет никаких причин собирать этот "стандарт" как монстра Франкенштейна из плохо подходящих друг к другу ошметков. Это можно и нужно проектировать как единое целое.

[alexpts]

Думаю, что компонентность и возможность заменить что-то это одна из главных идей. Монолитная штука без возможности заменить что-то на своем уровне, лично мне видится менее интересной. Каждая компонента имеет одну зону ответсвенности и между ними строятся барьеры абстракции, что позволяет жанглировать компонентами, но цена гибкости - интеграция всего этого между собой.