beforeUpdate() is actually executed AFTER render()

[nobelhuang]

Version

2.5.13

Reproduction link

https://jsfiddle.net/5vze74yy/

Steps to reproduce

1. Add render() and beforeUpdate() hook to the instance.
2. Trigger data value change by any means

What is expected?

Per the API

https://vuejs.org/v2/api/index.html#beforeUpdate

beforeUpdate is supposed to be fired before render(), and state changes in this hook should not trigger additional re-renders.

What is actually happening?

beforeUpdate() is actually invoked after render() in current version 2.5.13.

---

This could result in infinite update loop, as state changes in beforeUpdate() will trigger another re-rendering.

[HerringtonDarkholme]

Called when the data changes, before the virtual DOM is re-rendered and patched.

re-render here means exactly the same as patched: it means the generated(or, rendered) virtual dom node is applied to the real dom tree.

On the other hand, render in API means: a method to generate virtual dom. It does not mean it is drawn(or, render) on real dom.

Admittedly, render is too overloaded here. @chrisvfritz any idea?

[yyx990803]

I think there's indeed a mismatch here, since the description indicates you can mutate state in beforeUpdate which will then be applied - this entails that the hooks is called before the virtual dom render functions is called.

I'll give it some proper thought next week.

[nobelhuang]

Just saw this updated. Do you guys really think it is a good idea that resolving this by just simply revising the wording of the API docs? I don't think so.

First of all, render is never the exactly same meaning as patch when no target following render term, i.e. render to the DOM, especially when Vue is using virtual DOM. People coming from React background will always consider render as running the render() function, by using your terms, as generating virtual DOM nodes. Of course, unless Vue wants to be very unique on this one...

Secondly, if do decide to take the path that updating the docs to match the current beforeUpdate() behavior, not only the API description needs to be revised, but also the lifecycle diagram (link). Since these two places consistently indicate beforeUpdate() should not be like current behavior, I don't believe it was deliberately designed that beforeUpdate() is called after render(), hence it is a functional bug instead of documentary.

Further more, if it is not allowed to change/update the states of the component in beforeUpdate without triggering additional re-render, this lifecycle hook is much less useful from developers point of view, because it is a very common case, for developers not matter coming from React or Angular, that updating states of components per changes to props. You know, the render() is called in various cases, like its own state changed, props changed, or even the parent forcing update. In React, it has a few similar but separate hooks to allow developers to detect those changes and even update states BEFORE calling render() (link). However, unlike React, Vue has only one lifecycle hook beforeUpdate() documented to be able to detect changes and to update states before render, it becomes the only hopeful place where suppose to perform those common practices.

[chrisvfritz]

@nobelhuang Don't worry, this isn't considered "resolved" yet. It was my fault the issue was accidentally closed, as I didn't remove the fixes #7481 from my PR after discussing the problem in more detail with @HerringtonDarkholme.

[HerringtonDarkholme]

Thanks for the passionate discussion. The doc issue accidentally closes this, so I reopen the issue since it is still in review.

not only the API description needs to be revised, but also the lifecycle diagram

I think so.

beforeUpdate() is called after render()

Can you give an example where called before/after render will give significant difference? The old doc said further state change can occur in beforeUpdate. However, I think that might be inappropriate. State changing can lead to infinite loop, whether it is called before render or not.

However, if beforeUpdate disallow state changing or dispatch action to flux store, in other words, not triggering re-render, I wonder if it matters to call before/after render.

it is not allowed to change/update the states of the component in beforeUpdate

So changing state should be your use case. But as discussed above I suspect if it is proper usage. React has recommend against this, and of course Vue don't want to be unique here.

Vue has only one lifecycle hook beforeUpdate(), .... , it becomes the only hopeful place where suppose to perform those common practices

So the real proposal here should be adding a new lifecycle like componentWillReceiveProps, right? The difference here is that prop change is only top-down. So component will execute receiveProp lifecycle once and trigger state change, and then execute beforeUpdate once, and finally one render. State change in beforeUpdate however can lead to infinite loop.

Other than the request, you can use watch to perform state change, for now.

[nobelhuang]

@HerringtonDarkholme Thanks for comments.

Can you give an example where called before/after render will give significant difference?...

Surely as you said, if state changing is disallowed in beforeUpdate, it doesn't matter it is called before or after render. But just because the doc and diagram indicate it allows, and I tried then found it led to infinite loop, the calling order matters. By the way, I also tried changing some states at the very beginning of render (I know it was wrong operation) to see if it can circumvent the situation, it turned out infinite loop too, so not only does calling order matter, but also ticks. Given I never read Vue source code, correct me here if wrong.

So changing state should be your use case.

I don't think changing state before render running is only my use case. React against doing that in componentWillUpdate, while still provides componentWillReceiveProps to allow such operation, because developers need this. So yes, if you think beforeUpdate should keep current behavior, it would be better to have a new lifecycle hook like componentWillReceiveProps.

Other than the request, you can use watch to perform state change, for now.

Actually, I was curious why I couldn't find any filed bugs regarding beforeUpdate weird behavior before I filed, then I guessed, just as you mentioned here, people could use watch to achieve the goal in most of cases. However, think about when the component will be re-rendered, it is not just when props changed, it could also be when the parent is forcing to update even if props are not changed at all. Then the watch approach is not sufficient. In addition, one uncommon case, what if there are many props, say 30, and I just want to do some state changes no matter which prop has been changed. In the way of watch, I have to specify all 30 props to be watched explicitly...

Anyway, if you think this is not a functional bug, it would be good to have a componentWillReceiveProps-like lifecycle.

Thanks again for you guys awesome works.

[HerringtonDarkholme]

just because the doc and diagram indicate it allows

IMHO it should not, whenever it is called, and the new doc has removed that suggestion. Again, beforeUpdate executed before/after render only differs when you change state. So that is probably why no issue has yet been reported on this.

Please do provide a concrete example where you do need to change state in beforeUpdate.

I don't think changing state before render running is only my use case. React (...) provides componentWillReceiveProps to allow such operation, because developers need this.

I agree that is useful. And indeed it is not uncommon to have a component with large prop set. e.g. a bridging component for google map. What I have seen is developers uses helper function to dynamically watch props change. Say,

function dynamicWatch(props, vm, func) { 
  for (let key in props) 
     vm.$watch(key, func)
}

So to summarize the discussion above, can we list these 3 points?

1. whether beforeUpdate allow state change
2. should beforeUpdate be call before render.
3. should Vue provide a propsUpdate helper

Does this wrap up the thread?

[nobelhuang]

Okay, it seems that I have to provide a couple of examples. I came up with these examples randomly.

Example 1. jsfiddle
Imagine a Timer, initially you can set years, months, days, hours, minutes and seconds respectively to count down, these values can also be changed anytime when you want to start a new timer. However, before a new timer starts counting down, there would be a short pause, and there is a signal above the countdown to indicate if it is currently paused or counting down. As you can see, whenever and no matter which time props of Timer is changed, we need to update some states, like pauseHandle, countDownHandle and startpoint, and this could be done easily and efficiently in beforeUpdate if state changing is allowed. Of course, we can achieve the same result by using dynamicWatch, but the func might be invoked 6 times if all time props change at once.

Example 2. jsfiddle
Imagine a jigsaw puzzle game, we have a board component that can host all puzzle pieces. As pieces are added to the board, the board could show different background color as hint for the player indicating if he/she is approaching the goal. As you can see, there is actually no props changes that can be detected for TheBoard component, its state change is based the $slots.default which is not reactive, and it is the parent that is forcing TheBoard to re-rendered. It is convenient to update this state in beforeUpdate. Of course, I know we can use a method to work out that value replacing the use of boardColor, but if boardColor will be used many times in the template, that method would be called many times in one render process, in that case, I know we can write render function to alleviate, but don't you think it will be easier to do that in beforeUpdate?

I am feeling I lost my point through this thread. To wrap up, I only want to state that, because both the API doc and the lifecycle diagram consistently indicate you can change states in beforeUpdate, I don't think it was initially designed not to allow to do so, hence I think it's a functional bug.