Nuxt3 - accessing Vuex store from middleware? - vuex

How can I access a Vuex store from within a middleware?
I know Nuxt3 suggests using Pinia, but I had problems installing/integrating it due to dependencies conflicts, so I used the ol' good Vuex.
Problem is, in Nuxt3 my middleware has no access to the context object but just to the routes that are being navigated to/from.
So the question probably became: is that even possible or am I enforced to use Pinia?

Related

[Question + Discussion]: what are the tradeoffs of using apollo-client in redux application?

I have a redux application that fetches data from a Graphql server. I am currently using a lightweight Graphql client called graphql-request, and all it does is help you send Graphql queries/mutations, but I would like to get the best out of my APIs. even though I am using Redux as state management, is it ok to use apollo-client without its built-in cache and use it only for network requests/ API calls?
Benefits I know I would get from using apollo-client include:
Better error handling
Better implementation of auto-refreshing tokens
Better integration with my server, since my server is written apollo-server
Thanks
Apollo-client's built-in cache does pretty much the same job that redux state management would do for your application. Obviously, if you are not comfortable with it, you can use redux to implement the functionality that you need, but the best case scenario in my opinion would be to drop redux, since the configuration of it its pretty heavy, and rely purely on the cache provided by Apollo-client.

Which approach best to use between making call api in component or action in Vuex

I am wondering about where i should making call api.
Approach 1:
Call in component and handle sync then commit to Vuex.
Approach 2:
Dispatch from component and call api in action then commit Vuex.
So, Which approach best to use between making call api in component or Vuex ?
Personally, I think both methods are acceptable and it boils down to personal preference.
My personal preference would be Approach 1. where I make use of the created() lifecycle method to call the API and return the data in the Vue component itself.
After which, I would then dispatch the relevant data to the Vuex state using actions and mutations.

Service Layer in Vue.JS?

In Angular, there's a specific "service" layer intended to hold mockup services returning dummy data initially, which are replaced with real calls to the backing RESTful services as development on a project proceeds.
In Vue, is there a recommended location or layer in which to put such remote calls using axios? I can see them being placed inside the methods of a Vuex singleton or scattered through the script portions of single-file components... I imagine also that there might be some way to provide them to components via dependency injection.
What is the best practice?
Ty in advance.
Yes, if you're using Vuex, you can place Service components that wrap your Axios calls, which are then called from the vuex store.
So the hierarchy goes Component -> Store -> Service Component -> Axios

Store data in a VueJS mixin

I want to create a VueJS mixin that adds a couple of methods to the parent. In order to do this I need to store some data too.
Is it possible to store data in a mixin that can be accessed by a component that uses the mixin?
You should use some centralised state mechanism or more popular option vuex to store the data and manipulate it from the methods of mixin.

Create a Java Spring API Router

Im creating an API using Java and Spring. My question is, is there a standard way to organize the API routes into one file?
For example when creating an API using Express.JS there is one file, called the router, where all of the routes are declared and set up.
With Spring's annotation-based MVC framework it seems like the routes are scattered through various controllers. So if someone who didn't write the API needed to make changes to it they would be left searching through files to find the specific route.
Is there a standard practice or pattern that would create a central router? Im thinking about just creating a router class however I would then have to create instances of MANY classes in that router. It doesn't seem very clean.
XML configuration used to be the only way to do it, but if I remember correctly, the usual usage was to have one method per controller.
There's a fairly nice implementation of what you're looking for in the third-party springmvc-router project, which will let you configure your routes something like:
GET /user/? userController.listAll
GET /user/{<[0-9]+>id} userController.showUser
DELETE /user/{<[0-9]+>id} userController.deleteUser
POST /user/add/? userController.createUser