Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default pending state flags #118

Open
riccardo92 opened this issue Apr 20, 2020 · 1 comment
Open

Default pending state flags #118

riccardo92 opened this issue Apr 20, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@riccardo92
Copy link

riccardo92 commented Apr 20, 2020

Is your feature request related to a problem? Please describe...

It is not related to a problem. In pure Vue + Vuex setups, I normally define "pending flags" in each module's state. These pending flags are used to track whether an API call is in progress, for example fetchingUserPending. I set these to false at the beginning of an action and to true in both the .then and .catch callbacks.

Describe the solution you'd like

I would be nice to have default pending flags defined for each model and each api call type in the Vuex ORM database, which are then controlled by the Vuex ORM axios plugin. Examples would be:
fetchingPending, updatingPendingetc.

Describe alternatives you've considered

Manually adding state variables like this

class User extends Model {
  static entity = 'users'

  static state ()  {
    return {
      fetching: false
    }
  }

  static fields () {
    return { ... }
  }
}

and updating them whenever doing an api call:

User.commit((state) => {
  state.fetching = true
})

User.all().then(_  => {
    User.commit((state) => {
      state.fetching = false
    })
}
.catch(_  => {
    User.commit((state) => {
      state.fetching = false
    })
}

This is quite cumbersome, it kind of defeats the whole purpose of using this plugin since I might as well manually define actions.

@cuebit
Copy link
Member

cuebit commented Apr 20, 2020

Thanks @riccardo92 for opening this issue.

I absolutely agree that there is a lot of boilerplate code when it comes to dealing with supplementary states with requests and I understand the frustrations.

This is something we have given a lot of thought, and there is some light at the end of the tunnel in regards to finding a solution that represents all possible use-cases. Generally, though, the state management for this plugin is somewhat hindered by the limitations imposed by the core library but that too will change in an upcoming core release.

We’ll keep this issue open for community driven ideas to find an adequate solution to this particular issue.

@cuebit cuebit added the enhancement New feature or request label May 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants