フィールド検証の説明ですべてのTKを思い出すと、それらは常に次のようになりました。
- 6文字より短くすることはできません
- 12文字を超えてはいけません
- ラテン文字、数字、アンダースコアのみを含める必要があります
要件は、多くの場合、一連の単純で明確なフレーズで提供されます。 そして、プログラマーは、これらの要件をコードに変換します。
次のように、1つの究極の正規表現に変換できます。
const validateLogin = login => /^[a-zA-z_\d]{6,12}$/.test(login);
しかし、読みやすく、即時TKに関連付けるのが簡単な単純な関数を作成する方が適切です 。
const charMatch = new RegExp('^[a-zA-Z_0-9]*$'); const validateLogin = login => { if (login.length < 6) return false; if (login.length > 12) return false; if (!charMatch.test(login)) return false; return true; };
そして、このコードを次のようにさらに単純化するとどうなりますか？
const validateLogin = login => validate(login) .notLessThan(6) .notLongerThan(12) .hasOnly(['a-z','A-Z','0-9','_']);
基本的な考え方は、検証要件は多くの場合、独立した典型的なステートメントのリストに分解できるということです。 そして、これらのアサートはアセンブルして再利用できます。
これはまさにvalidate.it.jsライブラリが行うことです。 カーネルは100行を超えず、それほど多くはしません。
- assert'yチェーンを呼び出すことができます
- 結果を収集して処理します
上記のことは、次のようなコードを実行することにより、
validate('Pa$$w0rd') .hasLettersLatin() .hasNumbers() .has("!", "@", "#", "$", "%", "^", "&", "*", "(", ")", "_", "+");
そのような結果が得られます。
{ ok: true, base: 'Pa$$w0rd', asserts: ['hasLettersLatin', 'hasNumbers', 'has'], errors: [] }
これはとても明白だと思いますが、少し署名します
ok bool-検証ステータス
true検証は成功しましたfalse検証に失敗しました
base 文字列 -検証済み文字列- asserts 配列 -呼び出されたアサーの名前のリストを呼び出し順に並べる
errors 配列 -すべての失敗したアサートの検証レポート形式のレポートの配列
失敗した検証の例を次に示します
validate('bob') .hasLettersLatin() .hasNumbers(); // --> { ok: false, base: 'bob', asserts: ['hasLettersLatin', 'hasNumbers'], errors: [ { path: [], rule: 'hasNumbers', details: { string: 'bob', subStrings: ["1","2","3","4","5","6","7","8","9","0"], found: false, message: '"bob" has no numbers' } } ] }
このシンプルなアイデアにより、要件に可能な限り近い検証コードを書くことができます。 同時に、アサート自体は非常にシンプルで純粋な関数です。 保守、テスト、および新しいものの追加が簡単です。
ところで、はい、ある種のアサートが欠落している場合、 @static .extend使用してオンザフライで簡単に追加するか、 assert .eval使用assert .evalます。
ただし、assert'ovコミュニティを欲しないでください。 貢献者になろう！
寄稿者
そして今、驚き。 ライブラリには実際にはまだアサートがありません。 .has 、 .match 、 .evalなどの基本的なものだけがいくつかあります。 この投稿のリストで使用したものすらありません。 問題は、実装ではなくアイデアに注目したかったということです。
さらに、必要な主張に対する私のビジョンは、コミュニティのビジョンとは大きく異なる可能性があると考えています。 そして、このツールを「自分用」にすると、他のJS開発者にとっては不便になります。 そして、私はアイデアを持っていました-このツールの作成にJSコミュニティを関与させること。 何だろう 自分で何もしない 彼は私自身ではなく、コミュニティのニーズをカバーしました。
validate.it.jsコントリビューターになるようにJS開発者を招待します。
オープンソースに貢献したいが、どのプロジェクトから始めればよいかわからない人。
自分自身とコミュニティ全体のための便利な検証ツールを作成したいすべての人。
一緒に、私たち全員にとって本当に必要な主張でコレクションを埋めることができます。
この場合、開発者はどのレベルの開発者でもかまいません。 結局、誰かが文字列の長さによる検証を行いたいのですが、たとえば、誰かがISO 8601標準のすべてのバージョンの日付チェックの実装に関心を持っています。
プルリクエストは非常にソフトです。
- テストの可用性
- 説明の存在-アサートのリストとともにセクションに挿入します。
検証レポート
前述の.errorsいえば、 .errorsに失敗した場合に.errors配列を埋めます。 検証エラーを表すための何らかの標準を探していました。 そして、私自身の経験から、私は平凡なtrue / false 、さらにはnull / 'error message'でも十分で'error message'ないことを知っていました。 そして明らかに、今日そのような標準はありません。
しかし、 ラムキンの素晴らしいアイデアがあり ます
「ユニバーサル検証レポートインターフェイス」- @rumkin / 検証レポート git
これは単純なDTOであり、検証の失敗の理由に関する最も詳細な情報を転送できます。 構成：
path 配列 -スキャンオブジェクトの場所。 文字列検証のコンテキストでは、それは常に空の配列[]です。rule 文字列 -検証が実行されたアサートまたはルールの名前。details オブジェクト -検証の失敗の理由の「機械が理解できる形式」の詳細または説明。 このパラメーターには、1つのフィールドを除いて、明確に標準化された構造はありません。
details.message 文字列 -「人間が読める形式」の説明 これはVRの標準フィールドではありませんが、このプロジェクトでは必須です。
例：
{ path: [], rule: 'notLongerThen', details: { string: 'markopolo', length: 9, max: 6, message: '"markopolo" longer then 6 characters' } }
ちなみに 、 rumkinは検証レポートを生成するための小さなツールを作成しました。 しかし、 0Dependecyのために、この実装は特に使用しません。 VR生成の利点は、かなり単純なタスクです。
VRがいつかは標準になり、少なくともローカルになれば素晴らしいことです。
PS
気軽に質問してください- 寄稿者のガイドまたはプロジェクトのreadmeを拡張したいだけです。