API: Options/Lifecycle Hooks

Question 1

All lifecycle hooks automatically have their this context bound to the instance, thus…

Answer 1

you should never use arrow functions to define lifecycle hooks. They will not be bound to the instance if you do.

Question 2

beforeCreate

Answer 2

Type: function

• Synchronously called immediately…
  
  • after the instance has been initialized
  • before data observation and event/watcher setup

Question 3

created

Answer 3

Type: function

• Synchronously called…
  
  • after the instance is created, and all options are processed, which means the following have been setup:
    
    • data observation
    • computed properties
    • methods
    • watch/event callbacks
• Mounting phase has not begun, thus the $el property will not be available yet

Question 4

beforeMount

Answer 4

Type: function

• Synchronously called right before mounting begins
• The render function is about to be called for the first time

This hooks is not called during server-side rendering

Question 5

mounted

Answer 5

Type: function

• Called right after instance has been mounted
• el is replaced by newly created vm.$el
• mounted does not guarantee that all child components have been mounted
  
  • If need the entire view to be rendered use vm.$nextTick inside of the mounted

This hook is not called during server-side rendering

Question 6

beforeUpdate

Answer 6

Type: function

• Called when data changes, before the DOM is patched
• Good place to access the DOM before an update
  
  • Such as removing manually added event listeners

This hook is not called during server-side rendering, because only the initial render is performed server-side

Question 7

updated

Answer 7

Type: function

• Called after a data change causes the virtual DOM to be re-rendered and patched
• Perform DOM-dependent operations here
• Avoid changing state in this hook, better to use a computed property or a watcher
• updated does not guarantee that all child components have also been re-rendered
  
  • use vm.$nextTick inside of updated to ensure entire view has been re-rendered

This hook is not called during server-side rendering

Question 8

activated

Answer 8

Type: function

• Called when a kept-alive component is activated

This hook is not called during server-side rendering

Question 9

deactivated

Answer 9

Type: function

• Called when a kept-alive component is deactivated

This hook is not called during server-side rendering

Question 10

beforeDestroy

Answer 10

Type: function

• Called right before a Vue instance is destroyed
• At this point, the instance is still fully functional

This hook is not called during server-side rendering.

Question 11

destroyed

Answer 11

Type: function

• Called after a Vue instance has been destroyed
• When this hook is called…
  
  • all directives of the Vue instance have been unbound
  • all event listeners have been removed
  • and all child Vue instances have also been destroyed

This hook is not called during server-side rendering

Question 12

errorCaptured

Answer 12

Type: (err: Error, vm: Component, info: String) =\> ?boolean

• Called when an error from any descendent component is captured
• Arguments:
  
  • err: the error
  • vm: the component instance that triggered the error
  • info: string containing information on where the error was captured
• The hook can return false to stop the error from propogating further
• Component state can be modified in here, but be sure to put proper checks into place to prevent causing an infinite render loop

Error Propogation Rules

• By default, all errors are still sent to the global config.errorHandler if it’s defined
  
  • Used to report errors to an analytics service in a single place
• If multiple errorCaptured hooks exist along the inheritance component chain, they will all be invoked on the same error
• If errorCaptured itself throws an error, both this error, and the original are sent to the global config.errorHandler
• An errorCaptured hook returning false will prevent any other errorCaptured hooks and the global config.errorHandler from being invoked for this error
  
  • Good idea to let an error propogate to the global config.errorHandler so it can properly be reported