Remove inline defined middleware

[codyrancher]

Summary

Remove inline defined middleware. Replace it primarily with router configuration.

Areas or cases that should be tested

We already have adequate automated testing for this.

Checklist

• The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
• The PR has a Milestone
• The PR template has been filled out
• The PR has been self reviewed
• The PR has a reviewer assigned
• The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
• The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

[codyrancher]

I couldn't migrate this file to the router config because it relies on the store already having schemas.

The initialization sequence (even modified slightly) will not have schemas loaded before route resolution when re/loading a page.

[rak-phillip]

I'll preface this comment by saying that I'm fine with the approach represented here, I'm more interested in exploring an alternative to see if it makes sense for this use case.

Have we considered utilizing in-component guards¹ instead of the beforeCreate() hook? I think that the guard would better communicate what we are doing within this component, but it comes with the tradeoff that we might not have access to this when we want it..

Footnotes

1. https://v3.router.vuejs.org/guide/advanced/navigation-guards.html#in-component-guards ↩

[codyrancher]

I haven't considered that. Do you know of a way to access the store from the guard?

It's actually a pretty reasonable idea which may apply better in that it executes before the component is created just like middleware.

[codyrancher]

I did find vuejs/vue-router#1103 (comment)

[rak-phillip]

Yeah, it looks like we would have to do something like this instead

beforeRouteEnter (to, from, next) {
  next(vm => {
    const hasSettings = !!vm.$store.getters[`management/schemaFor`](MANAGEMENT.SETTING);

    ...
  })
}

[codyrancher]

I'll keep looking into this. It's interesting and not as straight forward as I would've thought. If we access the vm it looks like the component will already be created so not a big advantage.

There's another suggestion I found which mentions just importing our store and accessing it directly. With responses that would resemble our current predicament in regards to how we can access our store in the app.

Any thoughts on the idea of making the store global?

[codyrancher]

I gave the global store a shot and it's a no go. The schemas aren't present when re/loaded.

I'm fine with leaving it as is or using the next(vm => {}). Do you think one is better than the other?

[rak-phillip]

I think we can leave this as is. It sounds like we won't get much of a benefit and the syntax will end up being less direct with the in-component guard.

Thanks for entertaining the idea 🙂

[rak-phillip]

LGTM

[cnotv]

Nice cleanup 👍