Element: [Bug Report] validation rules seem broken with v-if controlling el-form-item

Created on 19 Feb 2018  ·  2Comments  ·  Source: ElemeFE/element

Element UI version

2.2.0

OS/Browsers version

Mac OS X / Chrome 64

Vue version

2.5.13

Reproduction Link

https://jsfiddle.net/mensu/fgr83432/36/

Update: jsfiddle example to v36

Steps to reproduce

I found two cases, which I assume are somehow related to the issue

Note: [Selector] means the form item whose label is "Selector"

Case 1

  1. select "Not Restricted" for [Selector]
  2. select "Uppercase Input" for [Selector]
  3. type an "a" in [Uppercase Input]

Case 2

  1. select "Uppercase Input" for [Selector]
  2. type an "A" in [Uppercase Input]
  3. select "Lowercase Input" for [Selector]

What is Expected?

Case 1

  1. the color of the borders of [Uppercase Input] should not change
  2. [Uppercase Input] should be in an error state, prompting the error message "Please input ONLY uppercase letters"

Case 2

  1. [Baz] should not be in an error state nor prompt the error message "Please input ONLY lowercase letters"

What is actually happening?

Case 1

  1. the color of the borders of [Uppercase Input] turns green
  2. [Uppercase Input] isn't in an error state, and doesn't prompt the error message "Please input ONLY uppercase letters"

Case 2

  1. [Baz] is in an error state, prompting the error message "Please input ONLY lowercase letters"

Most helpful comment

For case 1, the color of the borders of [Uppercase Input] turns green because /^[A-Z]*$/.test('') === true.

Using key on custom components controlled by v-if is something a Vue user should get used to. So IMHO it doesn't seem to be annoying and not intuitive.

If Element were to handle this situation natively, we'd have to bring in nextTick, which can be evil sometimes. So it's better to keep it as is.

All 2 comments

Digging into the source code, I found that it is somehow related to the mounted lifecycle hook here: events that trigger validations are listened only when the underlying vnode is mounted, but when the condition of v-if changes, the vnode may be reused, in which case mounted would not called and events that trigger validations would not be listened even if there come new rules for the el-form-item after the condition of v-if changes.

With this knowledge, we could add a unique "key" prop for each el-form-item to solve this problem. However, I think that can be too annoying and not intuitive to users who have no idea about the implementation of the component.

If users are expected to add a "key" prop by themselves, or v-if + el-form-item + validation rule is an anti-pattern, or there is some method to call to have events that trigger validations re-registered when the condition of v-if changes, I hope these could be documented. If there are anything I am missing, please let me know.

Thanks for all the help in advance.

For case 1, the color of the borders of [Uppercase Input] turns green because /^[A-Z]*$/.test('') === true.

Using key on custom components controlled by v-if is something a Vue user should get used to. So IMHO it doesn't seem to be annoying and not intuitive.

If Element were to handle this situation natively, we'd have to bring in nextTick, which can be evil sometimes. So it's better to keep it as is.

Was this page helpful?
0 / 5 - 0 ratings