組み合わせて行います。現実的にはもう少し複雑なものになると思いますが、次に簡易的な例をあげます。},})(Form);上記の例では、次の様な値を返します。反映したいケースがあると思います。このような場合、フォームのインスタンスメソッドを使用して、フォーム外部からエラーを注入することができます。フラグを渡すことで表現できます。先程のログインフォームをハンドリングする例です。実際にはAPIをコールする。送信中の判定を行なう想定になります。統合などのサンプルがありますので、興味があれば確認してみてください。以降、背景や設計について紹介していきます。満足にバリデーションができてコードの見通しがよく、新規・既存問わずプロジェクトに導入がしやすいものって意外と見つかりませんでした。他のライブラリだとコンポーネント設計に制約が強かったり、機能的に不十分だったり。作り始める一番のきっかけとなったのは、以下の様なケースに遭遇したときでした。入れるのは大袈裟な気がするし、かといってここだけ別の方法でフォームのステート管理を行うのは統一感が無いし、学習コスト的にも痛いところです。打開策この状況を受けて、今後同じ思いをしたくないと考え、以下の様な指針でフォーム周りの実装を行い回避しました。必要に応じて流せるようにインターフェースを整えておく様々なプロジェクトに導入したいので、デザイン的な制約は極力排除したい記事冒頭でも書きましたが、ここで実装した内容を整えてライブラリとして使えるようにまとめたものになります。背景を踏まえた上で、設計に関する部分について書いていきます。おいて、最も使われているであろうという点からです。後発のライブラリになるので、学習コストは極力下げておきたいところです。つのコンポーネントが登場しました。等のコントロールコンポーネントに該当します。エラーメッセージのハンドリングに使用します。これらのコンポーネントを組み合わせてフォームを構築することになります。実際に描画されるコンポーネントは提供しません。以下はエラー表示付きのテキストフィールドコンポーネントの実装例です。それぞれの役割は以下のとおりです。プロパティをコントロールコンポーネントに指定する」という点のみです。これさえクリアすれば自動的に値が連動します。フレームワークやプロジェクトのデザインシステムと統合しやすくなります。自由度を高めた一方で、各フィールドのコンポーネントは全て自前で実装する必要があるため、ある程度必要なコードが多くなります。スタイルを持たせたコンポーネントセットを提供しています。用のコンポーネントセットも公開しています。フォーム、というよりはライブラリが提供する機能部分での話になります。アプリケーションのステートには一切関知せず、フォームの中で状態が閉じています。それには以下のメリットがあると考えています。別パッケージとして切り出しています。ロジックの依存性を最小限にしたかったためです。外からも扱えるようになっていれば、サーバサイドで同じバリデーションロジックを使いまわしたり出来るかなと思います。と今後の展望ここまで書いてきましたが、リファクタリングが必要な箇所や、未完了のタスクがまだ結構あったりします。サポートは最優先で取り掛かる予定です。自分自身が使ったことが無いため、今後の予定にとどまっています...。おわりに実は元となる実装は年末からあったのですが、途中ほとんど作業が出来ない時期があったりして、ずるずる半年くらい掛かっちゃいましたがなんとかリリースまでは持ってこれました。消化と安定した動作への調整をしていきたいと思います。教えてくださるとうれしいです。wadackel.me。