26

After reading one of Alligator.io posts about Vue that was saying that mounted lifecycle is a bad place to use http get. I was wondering if there are any guidelines to how properly get data from API in Vue.js?

kkot
  • 477
  • 2
  • 6
  • 13
  • 4
    Possible duplicate of [Which VueJS lifecycle hook must Asynchronous HTTP requests be called in?](https://stackoverflow.com/questions/49577394/which-vuejs-lifecycle-hook-must-asynchronous-http-requests-be-called-in) – Vucko Jul 27 '18 at 08:42
  • Well I asked for deeper explanation, yes I know that these 3 hooks are considered as good but why mounted is considered as bad in this case. – kkot Jul 27 '18 at 09:03
  • @kkot is your questions answered or do you wish any further explanation? – Simon Thiel Oct 04 '19 at 16:37

5 Answers5

17

I`m prefer call API in created hook. Quote from alligator.io:

In the created hook, you will be able to access reactive data and events are active. Templates and Virtual DOM have not yet been mounted or rendered.

So you easy can access to data to parse and save response from a server if you need.

Paolo
  • 20,112
  • 21
  • 72
  • 113
wkornilow
  • 777
  • 5
  • 10
12

The created() lifecycle hooks fullfills all requirements for fetching and processing API data.

However the official Vue documentation uses the mounted() lifecycle hook in example code for integration API calls with axios: https://v2.vuejs.org/v2/cookbook/using-axios-to-consume-apis.html

Both lifecycle hooks mounted() and created() are widely used for fetching API data and considered as good practice.

tony19
  • 125,647
  • 18
  • 229
  • 307
Simon Thiel
  • 2,888
  • 6
  • 24
  • 46
3

The answers make sense but if we use the mounted() hook to call the API's, assuming that the DOM is rendered. If we update a state here in mounted() will it trigger another render?

I am sure that in created() hook the DOM is not yet mounted. So, I might go with created().

Paolo
  • 20,112
  • 21
  • 72
  • 113
BHARGAV KUCHIPUDI
  • 31
  • 1
1

Answer

The best hook for this are mounted and beforeMounted expect some edge cases

Why?

  1. Vue can cache the components and created hook doesn't give any guarantee that Vue will apply it on the next mount. Sometimes you can find that your component has been saved the state. So if you don't see a component, it doesn't mean that it haven't been created.
  2. SSR: If you want to get a universal component its won't be valid to place any fetch methods to created hook. You will just receive an error while ssr rendering. And mounted hooks work only on the client side

If you care about performance and time, please don't. Fetch will be done after created and mounted hooks anyway, because hooks are synchronous and fetch is not. Also time between created and beforeMounted is very very short.

You can place it to created if you don't plan the ssr and if you know how Vue works and you really need to place it to created hook.

bad_coder
  • 11,289
  • 20
  • 44
  • 72
Dromo
  • 11
  • 2
  • 1
    The documentation states that mounted and beforeMounted are not called while server side rendering -> "This hook is not called during server-side rendering.". Can you state how this works then? – Max Mar 10 '22 at 06:12
  • I suppose your last sentence means "you really need to place it to created hook", correct? – Lysander Dec 19 '22 at 08:17
1

Due to the official documentation of Vue, it seems that fetch data in created hook is a good choice: https://router.vuejs.org/guide/advanced/data-fetching.html

But,

It can depend on the data you fetch, its importance of when user need that data, and the user device limitations sometimes (because of rendering issues due to hard browser calculations).

I think if its an important data and user wants to see that immediately, I prefer to fetch that data in created hook, but if it's not necessary, fetching that data or any other calculations in created can cause some render blocking or jank (because it may take time until rendering DOM). Specially if your user in on mobile devices or has limitations such as lack of memory or weak processors

Javad NR
  • 11
  • 3