feat(runtime): support delay initializing props (fix #2325)

[unbyte]

54ed759 ignored that :value also can cause #2325 , which is due to the order when initializing an element's attributes.
I believe similar problems may exist on other platforms, so I think it might be better to add delayInitProp to runtime-core.

runtime-core

provide a render option called delayInitProp, which receives el and key, returns whether delay or the priority.

benchmark: https://jsben.ch/wP8Q4 loop vs bench

delayInitProp?(el: HostElement, key: string): number | boolean

return value

• true or number greater than 0 means put this prop at the end of the delayed queue
• false or 0 means no need to delay
• number less than 0 means put this prop at the beginning of the delayed queue (the need for delay is weaker)

runtime-dom

delay initializing value

---

fix #2325

[unbyte]

54ed759 ignored that :value also can cause #2325 , which is due to the order when initializing an element's attributes.

I believe similar problems may exist on other platforms, so I think it might be better to add delayInitProp to runtime-core.

[posva]

Isn't this a bit overkill though? Maybe looking through the vnode attrs to check if the value needs to be set one tick after instead of using mounted like in 54ed759 works

[unbyte]

I'm not sure if this change is appropriate in fact.

Maybe looking through the vnode attrs to check if the value needs to be set one tick after instead of using mounted like in 54ed759 works

I've considered a similar approach, but when it comes to async prop initializing, it's hard to guarantee that there's no sequential conflict under special conditions.

Also I'm confused about where to set attr on vnode for such special delay requirements. And after all we need to judge such special conditions in the runtime-core.

I've also considered a less general solution with no runtime cost, that is, moving :value to the end when parsing the template 😂

[posva]

I meant reading from vnode.props the possible attributes like type, min, max and range, and set them on the element before setting the value. For example, doing a rough Object.assign(el, vnode.props) before el.value = value solves the issue

I've also considered a less general solution with no runtime cost, that is, moving :value to the end when parsing the template 😂

Maybe that's the best solution but I imagine it would still be a problem in JSX and manual render functions

[unbyte]

gotcha.
but I wonder how it works for :value. The logic of set props is in runtime-core, but set props such as min, max before value is a unique logic of DOM.

[unbyte]

@posva https://jsben.ch/wP8Q4
it wouldn't make a significant impact on performance according to this benchmark ( see loop, it's very close to the original performance). after all, this change only affects how to initialize props.

[posva]

I was only talking about setting min, max and similar attributes on the vModel directive code (which is dom specific) before setting the value. All directly in created and removing the code of mounted

I don't really understand what you want to say with the jsbench 😅

[unbyte]

well there may be some misunderstanding. plz allow me to explain
this pr is mainly to solve the problem of :value, not vModel.

54ed759 ignored that :value also can cause #2325 , which is due to the order when initializing an element's attributes.

so this pr provides a way to delay initializing certain props (such as value in DOM). then I found that it would be much easier to solve vModel problem if directly set value as a prop instead of like what you suggest, so I did so.

sorry to puzzle you.

[HcySunYang]

@unbyte Can you fix the conflict? this needs to be rebased now.

[unbyte]

@HcySunYang
I just rebase on master branch and all tests are passed 😂
Since I haven't paid attention to vue-next for a long time, I just temporarily checked the files involved in this PR, which should not damage the current operation mechanism. If there is any, please let me know and I will fix it as soon as possible

[HcySunYang]

@unbyte Thanks

[HcySunYang]

@unbyte There is a conflict again, can you please resolve the conflict again 🤣

[yyx990803]

See ff0c810 - while the changes proposed in this PR are technically correct, they introduce a bit too much overhead / complexity for a very finite special case. I decided to just special case value directly in runtime-core.