While React has its fair share of state management solutions, Elf, the new kid on the block, aims to be the leanest, most modular solution yet. It’s built on top of RxJS and provides you with a wide array of tools to manage your state.

To acquaint yourself with everything Elf has to offer, check out Netanel Basal’s article, then come back and read this article. It’s ok, I’ll wait 😉 You can also find extensive data on all of Elf capabilities in its docs. My aim in this article is to show some of those capabilities via an example.

Setting up a Store with Elf

The first step to set up a store with Elf is to figure out what we want to hold in the store state. In this case, we’re building the classic TODOs app, and allowing users to add or remove their own tasks, as well as mark them complete, so we’ll maintain a collection of TODO tasks.

To hold tasks in our state, we call the built-in method createState(). This method returns a state and a config, both used in the store creation. The parameters passed are features of the store — in this case we pass, withEntities means this is an entity store, representing a collection of similar entities (in this case, our TODOs). To use this feature, the @ngneat/elf-entities library needs to be installed. This can be done in a breeze using the Elf CLI.

todos$ uses the build-in selectAll() entity method to return an Observable emitting the entire store’s TODO task collection.

updateTodosCompleted() uses the store.update() method to update our TODOs collection, in order to set a TODOs complete property. It receives a callback function, which gets the current state and returns a new immutable state — in our case we already have the built-in updateEntities() we can use here, another boilerplate saving solution from the Elf the entities package.

Similarly, addTodo() and deleteTodo() make use of the built-in addEntities() and deleteEntities() methods respectively, with addTodo() making sure that each new TODOs starts as incomplete, and gets it’s own id.

Now let’s create some TODOs and add them to our store:

This is the parent component which holds all our TODOs. We’re also using @ng-neat/use-observable here — it’s an additional library maintained by the creators of Elf which lets you use Observables in your React apps. useObservable() receives an Observable, subscribes to it, and stores the current version in a react state, ensuring that it persists between re-renders.

The parent component iterates over all the TODOs we have and displays each inside a TODO component. Let’s add that component:

Clicking on a TODO’s delete button will lead via the parent to the repo’s deleteTodo() method, and clicking on the TODO task name itself will similarly toggle its completion state. Let’s add a component that enables us to add a task:

Now we can add, remove, and toggle task completion. But what about viewing only complete or incomplete tasks? Definitely a useful proposition 👍

To achieve that we can add the withProps() Store feature, which lets us add an additional property to our store — in this case a filter describing which TODOs the user wants to see at any given moment.

Now we can get a current value of the filter and use it to filter our Store entities, so we replace todos$ with visibleTodos$:

We also add the updateFilter() method that uses store.update() to update the selected filter. All that remains it to update the parent component accordingly:

And add a filtering component that allows the user to choose between the available filters:

Let’s see it in action:

Here’s the final result:

I hope this gave you enough of an appetite to check out these features in Elf and some of other ones on offer, including, but not limited to:

• UI Entities
• Cache management
• DevTools
• Request Management
• Pagination Support
• Persist State

While Angular has its fair share of state management solutions, Elf, the new kid on the block, aims to be the leanest, most modular solution yet. It’s built on top of RxJS and provides you with a wide array of tools to manage your state.

To acquaint yourself with everything Elf has to offer, check out Netanel Basal’s article, then come back and read this article. It’s ok, I’ll wait 😉 You can also find extensive data on all of Elf capabilities in its docs. My aim in this article is to show some of those capabilities via an example.

Setting up a Store with Elf

The first step to set up a store with Elf is to figure out what we want to hold in the store state. In this case, we’re building a website displaying a book database, and allowing users to build their own libraries from it, so we’ll maintain a collection of books.

To hold books in our state, we call the built-in method createState(). This method returns a state and a config, both used in the store creation. The parameters passed are features of the store — in this case we pass, withEntities means this is an entity store, representing a collection of similar entities (in this case, our books). To use this feature, the @ngneat/elf-entities library needs to be installed. This can be done in a breeze using the Elf CLI.

books$ uses the build-in selectAll() entity method to return an Observable emitting the entire store’s book collection.

setBooks() uses the store.update() method to update our book collection. It receives a callback function, which gets the current state and returns a new immutable state — in our case we already have the built-in setEntities() we can use here, another boilerplate saving solution from the Elf the entities package. Now let’s fetch some books and add them to our store:

Populating the Store

The service we’ve created handles the side-effects, but they can also be handled via Redux-inspired actions. You can read more about that here. If we also wanted to add a loading state, that could easily be handled via the requests status package.

Let’s display our book collection:

Now we can display it in our app:

In order to let the user maintain their own library by adding books from the collection, we add a library property in our state representing it. We could do that ourselves, but once again, Elf’s good the goods 🎁

Adding a Store Property

The propsArrayFactory lets us add an array to our store via the generate feature (withLibraryIds). It also provides us with any methods we might need to maintain the array’s values. Let’s put some of those methods to use:

ownBooks$ supplies us with all the matching book data from our store, for the books in the user library. It does so using the selectLibraryIds() method generated by the propsArrayFactory and the Entities package’s built-in selectEntities(). So you see, the makers of Elf have thought of it all 😎

Finally, let’s add a component displaying the user’s library:

And add it to our app:

Let’s see it in action:

Here’s the final result:

Elf State Management in Angular Apps - StackBlitz

I hope this gave you enough of an appetite to check out these features in Elf and some of other ones on offer, including, but not limited to:

• UI Entities
• Cache management
• DevTools
• Request Management
• Pagination Support
• Persist State

I’ve been working with Akita pretty much since its inception, and while I’ve created many, many Akita stores in Angular, and wrote about it extensively, and even played around with an Akita/Svelte combo, I had yet to use it myself in a React App. I’ve decided to check that box, and whip up a classic todo app in React, using Akita for state management. Let’s get cooking 👩‍🍳👨‍🍳

This article assumes some familiarity with Akita State Management. To learn more about Akita and all its capabilities, check out one of the articles I’ve listed above or its great documentation.

Getting Started — What Do We Want to Save, and Where Do We Want to Save It?

We start by creating the model for the entity we want to save, in this case a ToDo item:

This includes the model itself, as well as a function to generate new ToDo items. Note that the guid() method is our first little morsel from Akita 😋

We also add a VISIBILITY_FILTER filters enum, which we’ll use later to filter the display of the items.

Next up is adding an Akita EntityStore:

The store is used to hold our ToDo items (the state), as well as the currently selected VISIBILITY_FILTER (aka the UI state). To read more about managing UI state with Akita check out this article. As you can see, very little code is needed at this stage — this is part of the charm of Akita, it saves a ton of boilerplate 💪

Every Akita entity store comes with a set pair of EntityQuery (for reading data from the store) and EntityService (for modifying the store). Let’s add the query first:

Once again, Akita’s EntityQuery provides us with any basic selection functions we need (check the docs for more on that). All we need to add is a function that returns the currently selected VISIBILITY_FILTER, and one that returns the ToDo items, filtered by it. Let’s move on the service:

The service is also pretty lean — the basic CRUD operations are already supplied by the EntityStore, all we need to do is call them.

The Secret Sauce: useObservable

Starting from v.16.8.0, React provides us with a bunch of hooks that let us interact with the lifecycle directly. You can read more about React Hooks here.

I’ll import useObservable, which uses those hooks (specifically, useRef, useState, and useEffect) and a given Observable, to update a React state with its emitted values. You can read more about useObservable here.

Using that, with the query’s selectVisibleTodos$ method as input, gives us the last piece of the puzzle:

And voilà! That’s all the ingredients we need for an efficient, DRY todo app!

You can also see the full app in action here:

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

Akita + React Hooks = a Recipe for Sensational State Management was originally published in Datorama Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.
• The persistState plugin features a performance optimization option.
• The persistState plugin also supports custom hooks now.
• The EntityStore now has a replace method.
• The PaginatorPlugin now has a refreshCurrentPage method.
• The HistoryPlugin can now have a custom clear function.
• The Query Entity’s selectEntity method now supports a predicate function as a parameter, i.e.: query.selectEntity(e => e.title === ‘title’).
• 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:

• 10 Reasons Why You Should Start Using Akita as Your State Management Solution
• Introduction
• Let's Build a Pizza Store with Akita - State Management for Angular Applications

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

Introducing Akita’s New Entity Service — At Your Service! was originally published in Datorama Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a new player in the world of JS frameworks — Svelte. As its name suggests, Svelte is lean, extremely lean. In fact, Svelte’s modus operandi, of compiling code to (ideal) vanilla js during the build phase rather than interpreting it during the run phase, has had people describing it as a non-framework and its own creator calling it a language, rather than a framework. Specifically, one created for describing reactive user interfaces.

I’ve started playing around with Svelte and so far I’ve been having a blast. The tutorial offered by creator Rich Harris functions as a very pleasant introduction. After completing it, I started to wonder how Akita, the state management solution we’ve created here in Datorama, would work in conjunction with Svelte.

Svelte + Akita = A Great Combo

If you’re already familiar with Svelte, you might be asking yourself why additional state management is even required, as Svelte comes with built-in reactive store functionality. If you have a small application, you can probably get away with using Svelte API alone. However, larger and more complex applications require a full-fledged state management solution. It’s similar to how we need Redux when we have React’s Context API.

A note on Akita’s architecture:

The two main components of Akita are the store and the query. You can think of the store like a table that contains data in a database, and you can perform various actions on it like inserting, updating, etc. My svelte component will reactively get the data from the query. And since I want it to remain agnostic of its data source, I won’t import the store inside the component; Instead, I’ll create a service for the component to work with.

As you can see, Akita defines a strict pattern for managing your state data. It comes with powerful Entity management, a robust set of plugins and dev-tools, and its own cli. Svelte and Akita are a great natural combo because Akita’s queries can return observables, which Svelte supports out of the box. So here is one example of how the two can be used in tandem:

Incorporating Akita

To add Akita to my svelte app, I install it, and its cli, via npm. I start with a fresh Svelte seed and go ahead with creating the traditional “TODO” app using Svelte and Akita.

The TODO Entity Store

Since we’re dealing with TODO items, I opt to create an Entity Store in Akita. You can think of an entity store as a table in a database where each row represents an entity. To do that I use the Akita CLI.

The store itself has all the built-in methods I need in order to perform CRUD operations on my entities.

In addition to those methods, I add a filter parameter in the store creation, representing the UI State data used to filter the display of the TODO items.

The TODO Service

Next, I’ll create the aforementioned service:

It contains all the methods I’ll need to update/read from the server and the store.

The TODO Entity Query

Akita Entity Query’s built-in methods can be divided into two types. A method that starts with select, for which you get an observable for the requested data, and methods that start with get, in which you get the requested data directly. It’s important to emphasize that the subscription won’t be triggered unless the value you asked is changed by reference. To those, I add the following methods:

I use combineLatest to subscribe to the store, get the latest version of the TODO list, and filter it according to the latest filter selection.

The next step is to create the Svelte components that interact with the Akita Entity store:

The Filter Component

This component’s sole responsibility is to let the users determine the criteria by which they filter the TODO list:

The Add TODO Component

This component is in charge of dispatching a todo event for the purpose of adding a TODO:

The TODO Component

It is used to display a single TODO item, along with a button for deleting it, and a checkbox to toggle its ‘completed’ status:

Connecting the Dots

Finally, a TODOs component will use all the previously mentioned components, along with the query and service I’ve created, to manage my list:

The End Result

Before we conclude, I wanted to add one last tidbit: Another thing you can get from Akita out of the box, is the ability to persist the state via local storage. I simply add in the main JS file:

And voila, your state is now persistent!

You can find all the files for this example here.

In summary: Both Akita and Svelte offer a moderate learning curve and enable the easy creation of incredibly lean apps with super-efficient state management out of the box. I encourage you to try both, either together or separately 👯‍♀️

Here are some more articles about Akita:

• 10 Reasons Why You Should Start Using Akita as Your State Management Solution
• Introduction

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

A neat package offered to Akita users

The Akita ng-router-store is a neat package offered to Akita users, which enables binding the Angular router state to an Akita store. The benefits of this approach are:

• The router state is stored in an Akita store named router, which serves as the single source of truth for things such as URL, state data parameters, query parameters, etc.
• Our components don’t have to be familiar with the data source. The RouterQuery can be injected in any one of the queries to create an encapsulated derived selector.
• The library exposes Akita style queries, saving you from dealing with all the required boilerplate code.
• We can examine the current router state in the Redux devtools and perform ‘time-traveling’.

To get started, install the package and add it, as well as Akita’s devtools module, to the app module:

At this point you should see the router store in the Redux devtools, and you have at your disposal the following query API:

For example, let’s say we want to query the current entity based on the URL id parameter, we can do the following in our ArticlesQuery class:

And use it in our component:

Voila — easy breezy navigation management!

Last but not least: A new version of Akita just landed in Github! You can check out the breaking changes and the new features here.

Manage Your State Navigation Data with a Breeze Using Angular and Akita was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

State management is ubiquitous in web applications, be they big or small. One of the notable solutions in this field is Akita. Whether it’s entities arriving from the server or UI state data, Akita has custom-built stores, powerful tools, and tailor-made plugins, which help you manage the data and negate the need for massive amounts of boilerplate code. Here are ten reasons why you should start using it:

1. Akita is a veteran in the field: It’s been out for a year already and even before that it was used for over a year in Datorama, as part of a real-world app utilized by thousands of customers. The app includes elaborate state management, component communication, complex form handling, dirty checking, undo functionality, and rapid manipulation of big data.
2. Akita has the backing of Datorama: Akita doesn’t rely on sponsors to continue evolving. It was created here, in Datorama, a Salesforce company. Datorama developers maintain it and improve it as part of our work schedule. Additionally, we often get inspiration for new Akita features from the needs of the continually growing and evolving Datorama app.
3. Akita is easy to pick up: It has a moderate learning curve, suitable for both experienced and inexperienced developers alike. It features a robust set of tools, anything you might need for quickly deploying a quality app.
4. Akita isn’t coupled with Angular: Once you get the hang of using it, Akita can be used with React, Vue, Svelte, Angular, or even vanilla JS. No framework-specific adapter is needed; This means that if you swap framework, changes to Akita code are kept to a minimum.
5. Akita has a 0 bugs policy: Here at Datorama, we consider your bugs as our bugs. Since Akita is deployed in our production environment, it’s crucial for us to solve any bugs you might discover ASAP. The Akita repo issues section is a testament to that.
6. Akita is very well documented: We understand the importance of thorough documentation, and do our best to supply Akita users with complete documentation of all necessary information. Additionally, we often write blog posts detailing the various ways in which Akita can be used in your apps. Like Akita itself, we constantly work on growing and improving this knowledge base.
7. Akita’s community is growing, fast: With over 320,000 downloads to date, Akita is growing in popularity in lightning speed. Another sign of its ubiquity — familiarity with Akita has recently started showing up in Front-End position postings.
8. Akita is well-suited for full stack developers: Akita is based on object-oriented design principles rather than functional programming, so developers with OOP experience should feel right at home.
9. Akita developers are easy to reach: Akita has a dedicated Gitter channel which is staffed daily.
10. Akita has a full suite of accompanying plugins: redo-undo, persist state, dirty check, pagination, devtools, router integration, CLI, and more.
    See something missing that you want to be added? We’re very receptive to requests 🙂

In summary: There are plenty of reasons to pick up Akita today. I highly recommend you give it a try — you’ll discover it provides you with an efficient and easy to use solution for all your state management needs! To get started go to the Akita repo on github.

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

10 Reasons Why You Should Start Using Akita as Your State Management Solution was originally published in Datorama Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

When creating web applications we sometimes come across the need to perform a certain operation repeatedly over time, with a set period of time between runs. The most common example is when we need to poll a server for data.

The Bad: setInterval

While the initial inclination might be to use setInterval for such cases — after all, it seems made for the task, and setting it would take a single line of code — however, this is not advised if the operation in question is asynchronous. This is because we cannot control when the asynchronous operation concludes, and as a result multiple operations might run simultaneously and their results might not arrive in the correct order:

The Ugly: setTimeout

Instead, we want to ensure that the periodic delay initiates only when the operation concludes. The tried-and-true method that’s used in these cases is to call setTimeout with the operation, and in the asynchronous callback method repeat the setTimeout call:

The Good: RxJS Timer/concatMap combo

However the good people at RxJS have a more elegant solution — if you use the RxJS timer in conjunction with the RxJS concatMap, we get the desired result. This is because the concatMap subscribes to the inner observables returned by the getData method in the order they were called, and emits them in that order. In fact, it doesn’t subscribe to the next observable until the previous one completes. This ensures behind the scenes that the delay isn’t initiated until the operation of that cycle concludes, guaranteeing that successive operations remain separated and do not coincide:

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

When it comes to maintaining a multistep form in your application, it can turn into quite a big headache, as any step or combination of steps can affect others, and you need to have real-time knowledge of both the form’s overall validity as well as each step’s status.

But not when you have Akita! Apart from being one of the leading state management libraries, with over 240K downloads to date, Akita has an additional library, AkitaNgFormsManager, which offers form-specific functionality that can significantly simplify your form management experience.

The AkitaNgFormsManager lets you sync Angular’s formGroup, formControl, and formArray, via a unique store created for that purpose. The store will hold the controls' data such as values, validity, pristine status, errors, etc. Unlike other libraries, this form manager doesn’t require the user to learn a brand new API; Instead, it relies on the existing Angular forms API.

Let’s take a look at a multi-step form and see how we can use AkitaNgFormsManager with it and what benefits we get from that. We won’t use the entire library API, but you can read about all the available methods here.

Form Value Persistence via a Single API Call

For this example we create a form with three steps; The first will ask for the user’s name and email, the second for details in the user’s address, and the third will ask for the user’s children’s names. We store each step in our AkitaNgFormsManager store separately, by using the library’s upsert method.

Here’s how the form management looks like when we inspect the store in Redux DevTools:

Step one:

Step two:

Step three:

This isn’t your regular run-of-the-mill upsert method —it inserts the form in AkitaNgFormsManager’s store if a form by that name doesn’t already exist for the given key, but if it does, it updates the component’s newly created form with the values and fields already stored for the existing form. This ensures that the changes made in each form are preserved even as we leave that form and the component in charge of it is destroyed. And it does that in a single, elegant, API call.

The component in charge of the third step is a bit more clever than a regular form: it adds and removes form fields dynamically, based on the selected number of children. To ensure that the modified FormArray can be recreated the next time the component is initialised, we add a third config parameter in the upsert call, containing a factory function for generating each FormControl in the array. This ensures that upon ensuing visits to the form page, the correct number of fields will be generated based on the form saved in the store.

Tracking Validity via the Store

To keep track of each step’s validity and dirty status we create a directive, ValidStepDirective:

The directive receives as input the form’s key in the store, allowing it to simply observe the required form status values (using the combineLatest operator). In this case, we combine the two values and return false if and only if the form is both dirty and invalid. The result controls whether the host element receives the “invalid” class, allowing us to signal to the user which step is invalid.

Accessing Form Values via the Store

The parent component also requires each step’s validity status for an additional reason: Since these are all steps of a single form, the parent component, OnBoardingComponent, holds the single submission button for the entire form, enabled only when all steps are valid:

Once again, simply by accessing the store, OnBoardingComponent can easily determine the overall validity of the form at any given moment. And upon submission, it gets each step’s form value from the store in order to submit it to the server (or in our example’s case, log it in the console).

Here’s the end result:

In summary: Managing the state of complex, multi-step forms, has never been easier. AkitaNgFormsManager takes care of all the boilerplate needed to consistently deliver each step’s values, as well as track its validity and dirty status.

Here are some more articles about Akita:

• Let's Build a Pizza Store with Akita - State Management for Angular Applications
• Akita and Firebase — a Match Made in Angular Heaven
• Infinite Scroll in Angular Using Akita

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

Akita continues to evolve and attract more users, and while using it is pretty simple and straightforward, there are ways where Akita can become even more efficient and useful to us. One such way is implementing the mediator pattern by combining multiple Queries and/or Stores.

Even the most casual Akita users are familiar with the Query. It’s a class used to query the Akita Store, which functions similarly to database queries. Its constructor function receives as parameters its own store or other query classes. This last part is where it gets interesting: By combining them, we can use one Query to query multiple Stores, which can be ideal in some cases.

Combining Queries

Say we have an app offering themes, games and ringtones to our users. Naturally since these entities are inherently different we create a Store for each. But in the overall app we need to query all three stores in order to display the contents side-by-side.

Rather than querying each at a time, a more elegant solution would be to create an overarching Query, which contains each store’s EntityQuery:

Combining Stores

Similarly, we can create an overarching Store, which includes references to the three Entity Stores:

And based on that store, we can create a Service, that can interact with all three stores at once, or any individual store:

End Result

Finally, we can use our new Query and Service in components which require this type of “big-picture” data:

In summary: In components which require access to multiple stores, consider creating mediators which combine the stores and their respective queries to keep your code DRY and make it more elegant.

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

📝 Read this story later in Journal.

🗞 Wake up every Sunday morning to the week’s most noteworthy Tech stories, opinions, and news waiting in your inbox: Get the noteworthy newsletter >