Akita: Why Query and Store?

[hoisel]

First, congratulations! Very good. Just one question. Why not unify "Query" and "Store"? I mean make Query methods available on the store (select, etc). It seems strange for me to have 2 services, 1 to change and hold state (Store) and another (Query) to listen for modifications made in the first one (store). Currently these 2 services have to be injected in each place that have operations to change/listen to the state for changes. What is the point I am missing ?

[andrewtw]

Well, I'm not the author, but currently enjoying the Akita after switching one of our state management from NGRX.

I would say, in normal cases, these two may not be injected in the same class together, in some classes you just need to set the values of state and in some places, you just want to query the values from the state instead of setting them.

Imagine that, you have a class to receive data from UI and store the input values to state, and another class is used to control the filter of the current stored data, the query will be able to be separated, even they are in the same UI.

In this way, Akita helps me doing more readable and maintainable codes.

[NetanelBasal]

Thanks, @andrewtw .

In addition to what @andrewtw said, there are a couple of reasons:

1. We wanted to decouple the queries from the store; This provides the power to swap the implementation of the store to something else in the future, for example, native observables.
2. We wanted to keep on the single responsibility principle; it means that the store is responsible for updates and the query on queries.
3. We believe that the component doesn't need to know where the data came from. It just needs to "get" the data.

The beauty of Akita, by the way, is that it doesn't couple to Angular DI. You can leverage ES2015 singletons and use it. For example:

export const todosStore = new TodosStore();
export const todosQuery = new TodosQuery(todosStore);

// component.ts
import { todosQuery } from '...';

class ProductsComponent {
  products$ = todosQuery.selectAll();
}

[michaelkrog]

I agree with @hoisel on this one.

Most of the time a component needs to both query and edit - in effect have the whole CRUD pattern available.

I am totally new to Akita. My first though is to somehow give my service the query ability so I can always just inject my service into the component and nothing else. Only thing is that I then have to extend my service with the Query class, which I don’t want to. But I could use it as a Mixin.

[NetanelBasal]

I think this is the beauty of Akita; it's opinionated but still gives you the freedom you need.

We actually started with both the store and the query combined, but we realized that when your app grows, and you starts having custom queries and custom update methods, the store class becomes vast and hard to maintain.

We like the separation of concerns and find it very clean and scalable.

[michaelkrog]

I can see your point @NetanelBasal. And I just love the fact that I can “hide” the state machine behind my services. Then my components need not know anything besides the application services and observables. Awesome and very clean!

It allows me to implement the state machine later on or even change state machine if something more suitable comes along. That is only possible with ngrx if you are prepared to rewrite almost everything, because of the fact that it has no separations that match a regular Angular application.

Thank you for letting this project out in the open. Looking forward to get back from my holiday and start implementing this in some of our projects