Remove fetch() usage as leftover from Nuxt

[cnotv]

Description

As the Nuxt world is departed, we should replace data fetching in the Vue3 way: https://vuejs.org/guide/built-ins/suspense.html#async-setup

The feature is not supported in Vue 2.7 https://v2.vuejs.org/v2/guide/migration-vue-2-7

The pattern is so specifically intended to have it as essential rule in the linter: https://eslint.vuejs.org/rules/no-lifecycle-after-await.html

[cnotv]

@eva-vashkevich suggested moving the logic of fetch() within the beforeMount() lifecycle hook by wrapping the evaluation within a promise as a proven solution in some cases.

[cnotv]

The whole fetch() deprecation would include these considerations:

• We would need to define async requests in another location
• The use of async setup() is not possible due these restrictions:
  • access global vars
  • define custom lifecycle hooks
  • access to other properties from async setup(), e.g. from data()
• The global variable $fetch() is adopted in more circumstances and will need to be replaced as well
• fetch() is added from a mixin altogether with other elements, which should also be removed:
  • Data state which includes errors, pending, and timestamp
  • Computed $fetchState which returns the state
  • beforeCreate() is used to assign $fetch()
  • Some delay is added for fetching
• We may consider using the vue-router data fetching hook, although it does not cover components and the current logic may not fit

[cnotv]

After analyzing the hackish implementation of Nuxt to create the fetch() "hook", I have been trying to create a PoC on Vue3 and it seems feasible the possibility to have an async fetch() also there.

https://codesandbox.io/s/vue3-vuex-custom-hook-yjghfv?file=/src/views/Home.vue

NOTE: This is available exclusively using Options API and not inside setup @rak-phillip .

[cnotv]

I am postponing then this refactoring after migration to Vue3 and keeping it open to define guidelines for the alternatives of fetch().

[rak-phillip]

@cnotv do we understand the purpose of the code related to invoking fetch on HMR¹ and matching routes²?

edit: we also have fetch logic related to refreshing³

Footnotes

1. https://github.com/rancher/dashboard/blob/557d0280fb8d5819517e4de3a3976aa640ac9f1e/shell/initialize/client.js#L274-L280 ↩

2. https://github.com/rancher/dashboard/blob/557d0280fb8d5819517e4de3a3976aa640ac9f1e/shell/initialize/client.js#L335-L414 ↩

3. https://github.com/rancher/dashboard/blob/557d0280fb8d5819517e4de3a3976aa640ac9f1e/shell/initialize/App.js#L96-L121 ↩

[cnotv]

Did we not say we were going to remove this? Because of the way it's written, I am not so sure is going to work with Vue3.
What's the purpose of this code? I have seen it outside of the fetch.js file, so I considered was a secondary purpose.

Also thanks for pointing it out.

[cnotv]

@cnotv do we understand the purpose of the code related to invoking fetch on HMR1 and matching routes2?

Just for the record, could we write down an update of what is the current issue after isolating the fetch() logic?
It would be nice to keep consistent clear information about the current state.
Even a link to something else where it has been already written is fine.

[cnotv]

Ok so to summarize, we have this code coming from Nuxt which we are not able to identify the whole purpose. Therefore we'll rather try to recreate some further PoC based on our code. This should ensure the right execution of the lifecycle hooks and related loading components.
The outcome will be to get rid of everything else.

[cnotv]

We can close this as migration is completed. Postponing this in a future architecture talk.