Since its inception, the Akita state management solution has delivered hundreds of thousands of developers an easy, simple way to manage their application state data and ui data. The newest complementary feature to come out is Akita’s Entity Service.

What is Akita?

Akita is a state management pattern, built on top of RxJS, and based on OOP design principles. It saves you the hassle of creating boilerplate code and offers powerful tools with a moderate learning curve, suitable for both experienced and inexperienced developers alike.

Why Add a Service?

Till now, the main components of Akita were the Akita Store and the Akita Query, which both have a regular version and an Entity version. Both query and store save on a huge amount of boilerplate code, by including the most common methods needed for state management.

What we realized here in Datorama (a Salesforce company), is that there’s even more boilerplate we can save you, by creating an Akita entity service, which follows the standard RESTful naming conventions by default.

Specifically, this service can be extremely useful in systems that use strict url patterns, such as CMS, admin dashboards, etc.

Getting Started

After installing Akita, we simply run:

npm install @datorama/akita-ng-entity-service

(or the equivalent in the package manager you use).

Let’s use JSONPlaceholder as our REST API and quickly scaffold a feature for Posts. To get started we run:

ng g af posts

This schematics command generates an Akita PostsStore , PostsQuery , and PostsService . First we need to define the base api url that will be used for each request. This is done when adding the service configuration to the module:

Note that if you have server calls that use a different base url than the one you defined in the above setting, you can modify the url per service, or use a factory if you dynamically generate the url based on other providers’ data. Our service looks like this:

This ensures that the service will automatically perform its CRUD operations on the PostsStore we’ve generated. By extending NgEntityService , we get a several built-in API calls without the need to add them ourselves: get() , add() , update() and delete() . Next, let’s create a component that uses those calls:

As you can see, since all the tasks of initializing the requests and updating the store are all baked in to the entity service, all we need to do is call the relevant methods. Additionally, each method takes a config object where we can pass some or all of the following parameters:

The resourceName used in the urls is by default identical to the store name, but we can easily configure it. For instance, if we want our posts service to fetch its posts from the articles url we can set it in the service config:

Alternatively, we can pass the config as the second parameter in the super() call in the service’s constructor.

Entity Service Loader

Loading indication is a very common scenario — we often need to display to the user an indication that the server call has been made, and our app is currently in the process of loading the resulting data.

Akita’s Entity Service comes with a built-in solution for these cases; The NgEntityServiceLoader can listen to any entity service’s built-in method and give us an indication of its loading status:

The loaders object now contains loading indicators for each of the PostsService methods; Each one holding an Observable boolean value, indicating the method’s loading status. Thanks to that we can create customized gui in the component’s template, based on those indicators :

We can also get indicators for a specific entity being updated or deleted by calling loaders.updateEntity(id) and loaders.deleteEntity(id) , respectively.

Entity Service Notifier

In addition to that, there are cases when we need to know whether a certain operation has succeeded or failed. For example, a global component that displays toast notifications to the user.

For this purpose the Entity Service package provides the NgEntityServiceNotifier service, which we can subscribe to and get the status of any HTTP call that was made:

The resulting data looks like this:

The package also exposes built-in operators, which allow us to filter the type, store, and http method. For example:

What Else is New in Akita?

Here are a couple more Akita innovations you might have missed:

Akita now features integration with Firebase.

In dev mode, you can now use window.$$stores and window.$$queries in your console, to obtain a reference to the stores or the queries.

and in your console, to obtain a reference to the stores or the queries. The persistState plugin features a performance optimization option.

The persistState plugin also supports custom hooks now.

The EntityStore now has a replace method.

method. The PaginatorPlugin now has a refreshCurrentPage method.

method. The HistoryPlugin can now have a custom clear function.

function. The Query Entity’s selectEntity method now supports a predicate function as a parameter, i.e.: query.selectEntity(e => e.title === ‘title’) .

method now supports a predicate function as a parameter, i.e.: . The Query Entity can now listen for a specific action performed on the entities.

The StoreConfig object can take a custom deep freeze function.

Want to learn more about Akita? Check out these articles:

Follow me on Medium to read more about Angular, Akita, JS!