これについて多くの例がないことを考えれば、私は可能な限りdocsに従っていますが、検証は反応的ではありません。node-simple-schemaを反応的に使用する方法は?
私はスキーマを宣言します。そして、私は私のコンポーネントで、このスキーマを使用
import { Tracker } from 'meteor/tracker';
import SimpleSchema from 'simpl-schema';
export const modelSchema = new SimpleSchema({
foo: {
type: String,
custom() {
setTimeout(() => {
this.addValidationErrors([{ name: 'foo', type: 'notUnique' }]);
}, 100); // simulate async
return false;
}
}
}, {
tracker: Tracker
});
:だから
export default class InventoryItemForm extends TrackerReact(Component) {
constructor(props) {
super(props);
this.validation = modelSchema.newContext();
this.state = {
isValid: this.validation.isValid()
};
}
...
render() {
...
const errors = this.validation._validationErrors;
return (
...
)
}
}
、私はfoo
を検証しようとするたびに、非同期のカスタム関数が呼び出されると、適切なaddValidationErrors
関数が呼び出されますが、this.validation.isValid()
をfalseとすると、コンポーネントは決して再レンダリングされません。
私には何が欠けていますか?
スキーマ自体の内部で名前付きコンテキストを使用するには奇妙な(そしてパターンがない)ことがわかります。この検証を行うには、この同じスキーマを常に使用する必要がありますか?ユーザーが複数のモデルをバッチで追加できるテンプレートがあればどうでしょうか?私はそれらのすべてのために同じコンテキストを使用するだろうか?いずれかが失敗すると、他の人もエラーを表示しますか?私は 'this.addValidationErrors'を使用しました。なぜなら、検証関数がコール時にコンテキストを受け取ると思われるからです!あなたはそれが事実でないと言っていますか? –
@ YanickRochon TBHパターンも分かりません。あなたがパッケージの問題を開いたのを見て、私はそれを提案しようとしていました。 – Waiski
。これがPRを提案した理由です。 'extendedCustomContext'にコンテキストを指定すると、私はそれを得ることができますが、' getContext() 'プロポーザルがはるかに優れた正規化された方法であると信じています。とにかく、あなたの説明をありがとう、私は 'TrackerReact'ソースコードを再読し、それがうまくいくかを理解しています:)乾杯! –