Vue - API Layer - XBase-UI

In this article, API layer best practices will be explained.

Use a single instance of the API client

No matter if your application is consuming RESTful or GraphQL API, have a single instance of the API client that's been pre-configured and reused throughout the application. E.g have a single API client (axios / graphql-request / apollo-client) instance with pre-defined configuration.

API Client Example Code

API Instance (Axios Base) Example: Provided by XBase UI team in order to standardize the implementation accross the projects.

Axios Base
To fulfill this need, the XBase UI team currently developing a separate package called xbase-js, which contains an extension of the Axios.
Later on, this extension of Axios can be utilized as the RESTful API client instance in your project.
You can read the documentation here Axios Base.

Define and export request declarations

Instead of declaring API requests on the go, have them defined and exported separately. If it's a RESTful API a declaration would be a fetcher function or a library such as axios, that calls an endpoint. On the other hand, requests for GraphQL APIs are declared via queries and mutations that could be consumed by data fetching libraries such as vue-apollo, apollo-client, etc. This makes it easier to track which endpoints are defined and available in the application. If your project is using Typescript, you can also type the responses and infer them further for a good type of safety of the data. You can also define and export corresponding API hooks from there.

Endpoint List of RESTful API Example Code

API Request Declaration Example Code

Presentational and Container Components pattern

Often time, when building a large scale applications, we are faced with the problem that it becomes so complicated to test some of the components. A common reason for this is that you have to mock a lot of global dependencies like the Vue Router or the Vuex Store and other parts of your code that induce side effects like data fetching logic. One way to work around these problems is to separate your components into two categories: Presentational Components and Container Components.

The presentational and container component pattern refers to Dan Abramov's article that aims to write a better React applications, since this dichotomy will make your components much easier to reuse and reason about.

This table shows some of the comparison between them:

Presentational Components	Container Components
Concerned with how things look	Concerned with how things work
Usually have some DOM markup and styles of their own	Usually don't have any DOM markup of their own, except for some wrapping divs, and never have any styles
Don't specify how the data is loaded or mutated	Provide the data and behavior to the presentational or other container components
Rarely have their own state (and when they do, it's related to UI state rather than data)	Often stateful, as they tend to serve as data sources
Receive data and callbacks exclusively via props	Provide callbacks, e.g: API call's response, to the presentational components

To summarize, Container Components are not concerned with how things look, but only with fetching data and initializing one or multiple Presentational or other Container Components. This means, only Container Components are allowed to fetch data from an API or communicate with the Vuex Store. In contrast, only Presentational Components are permitted to render their own markup.