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
Related
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?
I have created a mixin method to perform a complex string manipulation operation. It is used by different components in my application. Now I need to use the same method inside my service worker file. How can I access the mixin method in src -> mixins -> my-mixin.js inside my service worker file which is located in src -> sw.js
If mixin is not the right way to solve this problem, how can I solve this requirement? A global function which can be used by both service worker file and vue components.
I’m using webpack 3.12
Actually, I work in web app with vuejs as frontend framework.
in a particular situation, I want to communicate two separate components.
I know there are many ways to do that, especially with vuex that can help us to create a maintainable application.
in my case, i found we can manipulate data between components by bus events and with mixins (by $emit and $on event) also.
for that, i want to know :
how bus events and mixin work exactly ?
what is the difference between them ?
A mixin is a partial component spec. You include mixins in a component to compose functionality.
An event bus is a communication channel on which events can be emitted and listened for. Every Vue instance is an event bus.
I've looked into consuming APIs in Redux using the redux-thunk middleware. I understand the flow of calling an API from Redux, and I understand how to structure a slice of my state to reflect the status of an API call, i.e. fetching, success, or fail. What I'd like to know now is: how do I structure a very large application to avoid boilerplate code? From what I gathered reading the docs, a single API call requires:
Action creators to dispatch an API_CALL_FETCHING action and an API_CALL_SUCCESS action or an API_CALL_FAIL action
Reducer code to handle each of the actions
A slice of your state dedicated towards reflecting the status of your API calls
Assuming I have a resource that allows basic CRUD operations on it, naively that means I should write 12 different actions (4 crud operations * 3 API status actions per call). Now imagine I have many resources that allow CRUD operations, and this starts to get huge.
Is there any eloquent way to condense the code necessary to make many API calls? Or does having a large application simply demand lots of repetition in this area?
Thanks!
Yes. There's numerous ways to abstract the process of making API calls, and dozens of existing libraries to help with that.
Generically speaking, you can write "factory functions" that take some set of parameters (API endpoints, data descriptions, etc), and return a set of actions, reducers, and other logic for actually making the API calls and handling the data.
For existing examples, see the Action/Reducer Generators#Network Requests and Entity/Collection Management sections of my Redux addons catalog. There's also some more intentional abstraction layers on top of Redux, like redux-tiles and Kea.
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