Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes of v3
See #47 for details.
Migrating from v2
Breaking Changes
1. Naming Adjustment
interface
Validatable&ComposibleValidatable-> interfaceIStatestate.validators()->state.withValidator()(for details: [discussion] api naming #20)state.diableValidationWhen()->state.disableWhen()(for details: disable & disable validation #17)state.dirty->state.touchedNote that behaviors of the two fields differ (for details: Details for
dirty&DebouncedState#74 Opt-in debouncing #63):dirtytells if current value (value) equals initial value (initialValue)touchedtells if any change ever happenedWhich means, for code like:
in v2, the result
state.dirtywill befalse; in v3, the resultstate.touchedwill betrueP.S.
state.reset()will resetstate.touchedtofalse2. Changes of
FieldStateIn v3, we now no longer debounce value change of
FieldState. Correspondingly, it is not supported to specifydelay(of debouncing) when constructingFieldStateinstances now (for details: #61).If you need the debouncing of value change, you can use
DebouncedFieldStateinstead. It's almost the same asFieldStatein v2:As a result, field
_valueofFieldStateinstances is removed and UI binding is simplified:bindInputis no longer provided in v3, just usestate.value&state.onChangeto bind states to UI inputs:Note that if
stateis an instance ofDebouncedFieldState, you should usestate.$instead ofstateto do binding (for details: Debounced State).3.
FormState[mode=array]->ArrayFormStateIn v2, there are two modes for
FormState:object/array, corresponding for two cases:[mode=object][mode=array]In v3, the mode
objectremains the same. Modearrayis not supported any more, and we provided classArrayFormStatefor the array cases:Its APIs differs slightly, for details: Input List & #54
4. Others
$ofFormStateinstances is now read-only, which means, behaviors likestate.$.foo = ...is no longer allowed$ofFieldStateinstances is removedisFormStateis removedOther important (while not breaking) changes
1.
TransformedStateFor situations where UI value differs with business value, we provide
TransformedState. It works perfect within composition, for details: Transformed State & #562.
set&onChangeIn v2, only
FieldStateinstances provided methodsset&onChangeto change theirvalue. If you want to change the value of aFormStateinstance, you need to access its child states (state.$.*) first. In v3, you can callsetoronChangedirectly on any state, as long as it implemented interfaceIState. The semantics for these methods remains the same.Compare
with
The way in v3 (
state.set({ foo: 1, bar: 2 })) is much simpler, and it introduces lower coupling between parent states and child states.3.
ownError&hasOwnErrorIn v2, only instances of
FormStateprovided fieldsownError&hasOwnError. In v3, you can accessownError&hasOwnErroron any states which implemented interfaceIState. And they are recommended (instead oferror&hasError) for UI binding purpose. for details: #714. The brand-new docs
We built brand-new documents site for v3. It will be helpful to read them first, especially for key concepts in formstate-x.
v3 变更
详见 #47
升级文档
不兼容变更
1. 命名调整
interface
Validatable&ComposibleValidatable-> interfaceIStatestate.validators()->state.withValidator()(详见 [discussion] api naming #20)state.diableValidationWhen()->state.disableWhen()(详见 disable & disable validation #17)state.dirty->state.touched注意该字段的行为也有所调整(详见 Details for
dirty&DebouncedState#74 Opt-in debouncing #63):dirty代表的是当前值(value)跟初始值(initialValue)是否不相等touched代表的是值是否 发生过 变更(仅reset会将该状态重置)即,以下的行为
对于 v2,结果
state.dirty为false;对于 v3,结果state.touched为trueP.S.
state.reset()会将state.touched重置为false2.
FieldState变更及输入控件的绑定v3 中
FieldState不再对 value 变更添加 debounce,对应地也不再支持在构造FieldState时指定 debounce 的delay(详见 #61)如果业务上确实需要对 value 变更 debounce 后再去响应,可以使用
DebouncedFieldState代替;DebouncedFieldState的构造方式与 v2 中的FieldState一致:对应地,
FieldState上的字段_value也被移除,因此绑定 UI 的方式会有调整:formstate-x v3 不再提供bindInput;要将 state 与输入控件进行绑定,直接使用state.value&state.onChange即可。如:注意,若
state是DebouncedFieldState实例 ,应当使用state.$而不是state进行绑定(详见 Debounced State)。3.
FormState[mode=array]->ArrayFormStatev2 的
FormState支持object/array两种模式(mode),分别对应两种不同的使用姿势:[mode=object][mode=array]在 v3 中,第一种使用姿势与 v2 一致;对于第二种使用姿势(对应于输入是一个长度不定的列表的情况),我们单独提供了
ArrayFormState来满足这样的场景:ArrayFromState的使用与原FormState也会有所区别,详见 Input List & #544. 其他
FormState实例的$调整为readonly,即不再允许类似state.$.foo = ...的操作FieldState实例的$被移除isFormState被移除其他值得了解的变更
1.
TranformedState对于 UI value 与 business value 不一致的情况,我们过去通过由 Input 组件导出
getValue来实现。在 v3 中,我们提供了TranformedState来处理这种诉求,它的好处是不会要求 Input 组件提供额外的导出(getValue),对 Input 组件的使用者也更友好(直接使用state.value即可),对应地,其可组合性也会更好。详见 Transformed State & #562.
set&onChange在 v2 中,仅
FieldState实例提供了set/onChange来直接操作其value;对于FormState实例,往往需要去通过其子 state(state.$.xxx)来实现对值的设置。在 v3 中,所有(实现了IState接口的)state 都会提供onChange/set,其语义与 v2 中FieldState实例提供的set/onChange语义一致。因此你可以方便地在上层(父级 state)直接进行值的设置:相比
state.set({ foo: 1, bar: 2 })的做法更简单,也使得上层与下层逻辑的耦合更低(父级 state 无须知道子 state 的信息)3.
ownError&hasOwnError在 v3 中,仅
FormState实例会提供ownError&hasOwnError。现在所有(实现了IState接口的)state 实例都会提供ownError&hasOwnError。建议使用ownError&hasOwnError代替error&hasError去实现校验结果与界面的绑定(如bindFormItem),详见 #714. 阅读最新的文档
v3 提供了全新的文档( https://qiniu.github.io/formstate-x/ ),内容不长,建议阅读以便了解 formstate-x 中的关键概念