@ngrx/signals: mockSignalStore feature

[rainerhahnekamp]

Which @ngrx/* package(s) are relevant/related to the feature request?

signals

Information

It would be great, if we can provide a similar provideMockStore feature whenever we want to mock the SignalStore. It would also contain jest.fn or jasmine.createSpy for the methods and computeds:

const PersonStore = signalStore(
  withState({id: 1, firstname: 'Rudolf', lastname: 'Weber'}),
  withMethods(store => {
    return {
      async load() {
        // ...
      },
      rename() {
        // ...
      }
    }
  }),
  withComputed(state => {
    return {
      prettyName: computed(() => `${state.firstname()} ${state.lastname()}`)
    }
  })
)

And then inside a test

const mockedStore = mockSignalStore(PersonStore, {id: 2, firstname: 'Anna', lastname: 'Niedermayer'});

TestBed.configureTestingModule({providers: [
  {provide: PersonStore, useValue: mockedStore}
]});

// jest
mockedStore.load.mockImplementation(() => true)

//jasmine
mockedStore.load.and.returnValue(true);

Describe any alternatives/workarounds you're currently using

At the moment, I'd have to do that manually.

I would be willing to submit a PR to fix this issue

• Yes
• No

[jits]

(Bear with me as I unravel some thoughts)

I'm currently trying to standardise on using ng-mocks. With that I can currently do the following:

// In a spec file

// Note: `MockXX` are special ng-mocks helpers.

beforeEach(() => MockBuilder(MyComponent, null).mock(MyStore));

// `buildRxMethodSpy` is my ugly helper method to generate a Jasmine spy with the correct TypeScript signature
// (see: https://github.com/ngrx/platform/issues/4206#issuecomment-1932448978 if you want to get very annoyed).
it("should call the store method on creation", () => {
  const methodSpy = MockInstance(
    MyStore,
    "myRxMethod",
    buildRxMethodSpy("myRxMethod")
  );

  const fixture = MockRender(MyComponent);

  const component = fixture.point.componentInstance;
  expect(component).toBeTruthy();
  expect(methodSpy).toHaveBeenCalled();
});

With mockSignalStore I could just provide the mock instance to ng-mocks directly and check spys on it. Neat!

However, I quite like to let ng-mocks take care of mocking things (in this case, the Store), to keep things consistent and predictable, and then provide spy functions (using MockInstance). So is it worth also having some form of buildRxMethodSpy(…) utility function provided by @ngrx/signals? This would be a lower-level utility that folks could use with whatever testing framework / helpers they want.

[rainerhahnekamp]

I see. Well, in that case, we might want to discuss a set of testing helpers.

[jits]

@rainerhahnekamp — I do think having a mockSignalStore high level helper is a very good first step (and probably more impactful to the community at large). My particular need could come out of that work, or later.

[rainerhahnekamp]

Yeah, then it's up to the NgRx guys to decide if that is something we should have or not.

[markostanimirovic]

Another suggestion on this topic: #4252

[rainerhahnekamp]

Oh, that's a coincidence. That's huge. Congrats @gergelyszerovay. We could take this issue as the "issue" and #4252 as the official PR.

What I'd like to discuss is the dependency to sinon.js. I think we have three options here:

1. Don't use any third-party library, but provide methods and computers returning undefined. It is the up to the user to use their tools to mock/spy in whatever way they want.
2. Use a framework-agnostic mocking mechanism. So the provideSignalStore function would then allow to define the behavior directly (very similar to ng-mocks): https://ng-mocks.sudo.eu/api/MockProvider/#useclass
3. Provide different implementations for the common frameworks. This might act as an example: https://github.com/cartant/rxjs-marbles/tree/main/source

[jits]

Aside: @rainerhahnekamp — you may have intended to use a different link for your point (2) above?

[gergelyszerovay]

I published an article that compares manual Signal Store mocking and my provideBasicMockSignalStore() prototype (automatic mocking).

I chose to use Sinon in my prototype because I believe that many teams are currently using Jasmine and are considering moving to Jest in the long run. For these teams, using test framework-agonistic spies may be the best solution.

@rainerhahnekamp We should also consider implementing both options (1) and (3):

(1). The basic version of provideBasicMockSignalStore() would return a mocked version of the original store, its properties would be replaced with these symbols: MOCK_COMPUTED, MOCK_METHOD and MOCK_RXMETHOD s. And it's up to the user to replace these property values with spies.

(3). Additionally, we might provide test/mock framework specific tools: these would 'auto-spy' the basic mock store, for example the Sinion version would it replace:
MOCK_COMPUTEDs by WritableSignals
MOCK_METHODs by Sinon fakes
MOCK_RXMETHODs by FakeSinonRxMethods

The drawback of this approach is that supporting more test/mock frameworks would mean more dependencies.

[rainerhahnekamp]

Great article, @gergelyszerovay!

Please give me some days to collect and structure all my thoughts on your implementation.

[LPCmedia]

@rainerhahnekamp any thoughts so far ? Looks like the PR is closed and there will be another direction.

Looking at the API of the existing provideMockStore can we have something similar for mocking signal stores. MockStore enables us to overrideSelector in our tests. Can we have a similar approach here for computed, method and rxmethod ?

[rainerhahnekamp]

I see two non-technical reasons that speak against Sinon.

• We want to have as few libraries as possible. The more you have, the harder it becomes to upgrade Angular. We even see that companies decide against libraries because of too many dependencies.
• Jasmine & Jest have their own spy/mock implementation. As @jits pointed out, provideMockStore should integrate into the existing testing tools that developers use already.

That being said, at the moment I’d like to propose another possibility:

The signalStore itself requires an absolute minimum of code to set it up. Maybe we don’t need a mocking feature at all.

Let me give you an example:

const UserStore = signalStore(
  withState({ id: 1, firstname: 'Rudolf', lastname: 'Weber' }),
  withMethods((store) => {
    return {
      async load() {
        // ...
      },
      rename() {
        // ...
      },
    };
  }),
  withComputed((state) => {
    return {
      prettyName: computed(() => `${state.firstname()} ${state.lastname()}`),
    };
  })
);

Version without mocking function

const MockedStore = signalStore(
  withState({ id: 2, firstname: 'Sandra', lastname: 'Smith' }),
  withMethods(() => ({ load: jest.fn() })),
  withComputed(() => ({ prettyName: signal('Sandra Smith') }))
);
TestBed.configureTestingModule({
  providers: [{ provide: UserStore, useClass: MockedStore }],
});
const store = TestBed.inject(UserStore) as unknown as InstanceType<
  typeof MockedStore
>;
store.load.mockImplementation(() => {
  // mocking behavior
});

What do you say?

[ddamiankowalski]

@rainerhahnekamp @markostanimirovic A little late to the party, but I would still like to contribute.

This seems great when you have one or two stores that you need to mock, that are not that big. In reality, stores are much bigger and complex than that and change over time.

Additionally, this work is still tedious when you need to create this mock over and over again for possibly many components throughout your application. Not mentioning how tedious it later becomes to maintain this code.

I would love to somehow contribute and create very simple set of methods that would help you automate the mocking process for signal stores. Let me emphasize once more - I'd like for those methods to be as simple to understand as it is possible.

Let's imagine these tools are created and think about the problems they solve

1. Allowing for signal stores to be easily mocked with very simple API and in a structured, controlled and standardized manner
2. Allowing for the state to be altered during the arrange phase of the test, so that the components could be tested under different state variations
3. Allowing for the entities to be easily set in between tests

I feel like you don't always want to mock computed, because computed should always be correctly calculated based on the state you provided inside the signal.

Also, when it comes to spying on store methods I feel like it could be done outside of that theoretical utility tool. This is because developers use different testing environments and tools (jest/karma/sinon) - it would be a shame to force someone to use only one of them.

I've made some simple pseudocode demo that looks like this

/**
 * Provides a mocked store with initial values patched in test
 *
 * @param ctor
 * @param initialState
 * @returns
 */
export const provideMockStore = <State extends object>(
  ctor: Type<State>,
  initialState: any
): Provider => {
  const store = new ctor();

  untracked(() => {
    patchState(getWritableState(store), { ...initialState });
  });

  return [{ provide: ctor, useValue: store }];
};

/**
 * Utility function for setting store entities in tests.
 *
 * @param ctor
 * @param entities
 */
export const setStoreEntities = <T extends { id: number | string }[]>(
  ctor: Type<any>,
  entities: T
) => {
  const store = TestBed.inject(ctor);

  untracked(() => {
    patchState(getWritableState(store), setAllEntities(entities));
  });
};

/**
 * Patches the state of the store in tests.
 *
 * @param ctor
 * @param state
 */
export const setStoreState = (ctor: Type<any>, state: any) => {
  const store = TestBed.inject(ctor);

  untracked(() => {
    patchState(getWritableState(store), { ...state });
  });
};

const getWritableState = <T extends object>(store: T): WritableStateSource<T> =>
  store as WritableStateSource<T>;

This allows the developers to build up on those easy tools creating their own "test providers" for domain-specific parts of their application like so:

export const provideBookStore = (initialState: Partial<BookStoreState>) => {
  return [
      provideMockStore(BookStore, { ...initialState }), 
      // some other providers connected with this domain
  ];
};

And finally, they could use it in tests like so:

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [provideBookStore({ isLoaded: true, books: [] })],
    });

    fixture = TestBed.createComponent(BookshelfComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('shows correct amount of books', () => {
    setStoreEntities(BookStore, [{ id: 1 }, { id: 2 }]);
    const booksElements = getElementsByTestId(fixture, 'test-id');
    
    expect(booksElements.length).toBe(2);
  });

The code above is merely a pseudocode that serves as a proof of concept. I think a set of functions that are simple would be a great help. They don't force you into deciding on a pattern, you can still use your own strategies if you prefer so, but I feel like it would save some time as your application grows.

I would gladly expand on this proposal a bit more, just let me know if it has any perspective in your opinion :)

[rainerhahnekamp]

@ddamiankowalski you might want to take a look at #4540. W'd like to start with removing the state protection for tests.

[ddamiankowalski]

That looks great, thank you! That's what I had in mind. This would greatly help me with building my own testing solutions on top of that.

[jits]

Hi @rainerhahnekamp,

I think your proposal works very well for simple cases (which may be the majority?). I guess it has the same implications as managing any manual mocks — e.g. keeping it in sync with the implementation (especially from a TypeScript typing perspective). I'm not a fan of the manual typecasting as we're then breaking out of TypeScript's protections. Still, this goes a very long way in testing and is a good first port of call.

A sticking point I (personally) have right now is mocking rxMethods because of their particular TypeScript signature. (Hence the ugly utility method I've had to use). I think if something could be done about this then using tools like ng-mocks as an extra layer becomes quite powerful. Though note that I haven't gone too deep into testing SignalStores so there may be other issues / nuances that need considering. And I'm yet to go through @gergelyszerovay's impressive-looking article.

As you say, we may not need a full mocking capability (e.g. mockSignalStore), especially as libraries like ng-mocks already provides the ability to "auto mock" things. I think what's key is the public interface of a store — in a test you probably only need to mock a few things in the whole store. ng-mocks essentially allows me to mock out the whole object / class instance (it just nullifies stuff) and plug in in spys where I need, whilst maintaining the whole shape of the thing being mocked out. I need to look into how ng-mocks works under the hood — it's quite possible that it too resorts to manual typecasting to achieve it's mocking capabilities.

(Apologies for focusing so much on ng-mocks — that just happens to be the thing I'm focused on using at the moment, but hopefully the principles are useful generally).

[rainerhahnekamp]

I wouldn't have too high expectations for the internal implementation of the mocking libraries. They are very good in terms of typing, but internally, they are a collection of functions created with their specific mocks.

We usually use these libraries because writing manual mocks generally requires more code than automatic ones.

What if we take 3 or 4 examples and compare them?

---

If the manual turns out to be exactly the same amount of code, I suggest that the documentatios shows how to mock the signalStore properly with the common mocking libraries.

About mocking rxMethod: To the component/consumer it is a simple method. Maybe ng-mocks make it more complicated than it actually is? I hope the examples will bring some answers.

[jits]

Hi @rainerhahnekamp, sorry it's taken me so long to get back to you with an example. Here's a concrete example of how I'm mocking the internals of a store in a component test, in particular an rxMethod that returns a spy:

• The store
• The component that uses the store
• The component's test (mocking the store and its internal state and methods)
• The buildRxMethodSpy helper

[gergelyszerovay]

@rainerhahnekamp

We want to have as few libraries as possible ...
As @jits pointed out, provideMockStore should integrate into the existing testing tools that developers use already.

To remove Jest/Jasminse/Sinon dependencies we should consider the following API:

export const spies = {
  'function': () => sinon.fake(), // for mocking function
  asyncFunction: () => sinon.fake.yieldsAsync(), // for mocking async functions
}

provideMockSignalStore(PersonStore, {
  spies,
  // ... other config options
})

So users have to specify they preferred mock functions, similarly to ng-mock's custom auto spies works. In the documentation, we can provide sample Jest/Jasminse/Sinon spies configurations.

The type of provideMockSignalStore(PersonStore) and PersonStore would be the same, but in the documentation we can also provide sample implementations for helper functions such as asSinonSpy or asMockSignalStore() .

Alternatively, we might provide a configuration file generator, users can specify one of the following: Jest/Jasminse/Sinon, and the generator will generate a signal-store-test-config.ts with the spy framework specific spies config, and the asSinonSpy, asMockSignalStore() and asMockRxMethod() helper functions, that can typecast the store and its properties to their mocked version.

 Maybe we don’t need a mocking feature at all.

I think it depends on the application. I've used ComonentStores extensively in the past, and in an large enterprise application we can easily have dozens of stores with 20-30+ properties (selectors, updaters, effects) per store.

I expect a higher property number per store if I use Signal Store, because with the Custom Store Features, it's really easy to create Signal Stores with dozens of signals/computeds/methods. For example if I use the withDataService Custom Store Feature, it adds 6 new properties to the store.

For example, when we create a store for a component, that can modify a Book object (it can read and write a Book), the store has at least 13 properties. If we add a few selectors an methods, for example for supporting tags for the books, we can easily have 20-30 properties. So this is the store:

export const BookStore = signalStore(
  withState({ book: Book }),
  withDataService({
    actionName: 'loadBook',
    // ...
  }),
  withDataService({
    actionName: 'saveBook',  
    // ...
  }),
});    

The minimal, auto-mocked version of the store:

provideMockSignalStore(ArticleListSignalStoreWithFeature, {
  spies,
  mockComputedSignals: false,
}

If we need a pre-loaded book in the mocked store:

provideMockSignalStore(ArticleListSignalStoreWithFeature, {
  spies,
  mockComputedSignals: false,
  initialStatePatch: {
    book: {
      title: "Algorithms + Data Structures = Programs",
      author: "Wirth, Niklaus"
    },
    loadBookRequestState: HttpRequestState.FETCHED
  }
}

The manually mocked version of the previous store (with a pre-loaded book):

const MockedStore = signalStore(
  withState({ 
    book: {
      title: "Algorithms + Data Structures = Programs",
      author: "Wirth, Niklaus"
    },
    loadBookRequestState: HttpRequestState.FETCHED,
    saveBookRequestState: HttpRequestState.INITIAL,
	// if we want to mock the computeds
	isLoadBookRequestStateInitial: false,
	isLoadBookRequestStateFetching: false,
	isLoadBookRequestStateFetched: true,
	getLoadBookRequestStateError: undefined,
	isSaveBookRequestStateInitial: true,
	isSaveBookRequestStateFetching: false,
	isSaveBookRequestStateFetched: false,
	getSaveBookRequestStateError: undefined,
  }),
  withMethods(() => ({ 
    loadBook: fakeRxMethod(),
    saveBook: fakeRxMethod(),  
  })),
  withComputed((state) => ({ 
    // if we want to keep the original logic of computeds:
	isLoadBookRequestStateInitial: computed(() => state.loadBookRequestState() === HttpRequestStates.INITIAL),
	isLoadBookRequestStateFetching: computed(() => state.loadBookRequestState() === HttpRequestStates.FETCHING),
	isLoadBookRequestStateFetched: computed(() => state.loadBookRequestState() === HttpRequestStates.FETCHED),
	getLoadBookRequestStateError: computed(() => state.loadBookRequestState() === HttpRequestStates.FETCHED),
	isSaveBookRequestStateInitial: computed(() => state.saveBookRequestState() === HttpRequestStates.INITIAL),
	isSaveBookRequestStateFetching: computed(() => state.saveBookRequestState() === HttpRequestStates.FETCHING),
	isSaveBookRequestStateFetched: computed(() => state.saveBookRequestState() === HttpRequestStates.FETCHED),
	getSaveBookRequestStateError: computed(() => state.saveBookRequestState() === HttpRequestStates.FETCHED),
  }))
);

So it's possible to manually mock stores like this, but I think it's a time-consuming task. Automatic mocking can also reduce the required amount of coding, when we add new features to the store later.

@jits

in a test you probably only need to mock a few things in the whole store.

This also depends on the use case. I like Storybook, and prefer to make Stories:

• for all the dumb components ('UI components', they render the UI based only on their inputs, and usually they have no external service dependencies, and all the components in their template are dumb components). Some of them also have a component-level store, to manage the internal state
• for many of the smart components. Most of these have a component-level store and several service dependencies. In addition, application and function/domain level stores are used in complex applications.

So If I want to mock a Signal Store of a smart or dumb component for use in Storybook, I need to provide meaningful values for all the state signals and computeds, otherwise the component will not render correctly in Storybook.

---

I like and use ng-mocks, but I found that MockProvider can't properly mock ComponentStore's updaters and effects, and the new RxMethods. These three methods work similarly, all the three return a function, that can be called:

• with a static value
• with a signal argument, and the inner function might be executed when signal's value changes
• with an observable argument, and the inner function is executed each time when the observable emits

To mock these, I've created a fakeRxMethod function, we can also use this inside a MockProvider.

[jits]

@gergelyszerovay — thanks for the Storybook use case, that makes a lot of sense.

And also thanks for pointing me to your fakeRxMethod function; I've been using something similar (but much more simplistic in nature): https://github.com/FullStacksDev/angular-and-firebase-template/blob/main/app/src/test/helpers/ngrx.ts.

I still do think that it would be useful for NgRx Signals to provide testing helpers to make this kind of thing easier. But at the moment I don't have any concrete suggestions on how to enable this across different test libraries.

[rainerhahnekamp]

I'm sorry for not getting back to you sooner. For some reason, I've missed your answer.

I was also thinking about providing something like createMock from the testing library, but your version is much better suited for the signal store's needs, like keeping computeds and the initial state patch.

We can provide the spies property for different testing frameworks without requiring new dependencies. The testing library, for example provides jest-specific functions but doesn't list jest as a dependency: https://github.com/testing-library/angular-testing-library/blob/main/projects/testing-library/package.json.

@markostanimirovic: The question is how should we proceed? I think we kind of agree that we want to have that mocking feature.

[markostanimirovic]

Hey 👋

I'm going to convert this issue into a discussion for now. Feel free to create a standalone library/prototype with @ngrx/signals testing utilities and we will take a look.

To consider introducing a testing plugin as part of the core package, it has to be independent of testing frameworks.

[gergelyszerovay]

Hey,

I'm really glad that this is going forward :)

I'm going to update my initial implementation (https://github.com/gergelyszerovay/store-extensions/tree/main/projects/mock-signal-store/src), and I'm going to:

• push some fixes for injection context related issues
• try to remove the test framework dependency, I'll have a look on how the Testing library handles this, as @rainerhahnekamp suggested
• suggest a solution for mocking the lifecycle hooks

[gergelyszerovay]

I pushed an updated prototype and a demo app with a readme file containing some explanation.

This version of provideMockSignalStore:

• is assertation library independent
• contains a mock injector which mocks the services injected into the mocked store
• prevents the execution of the mocked store's lifecyce hooks
• makes the SignalStore's state unprotected

In the mock version of a SignalStore:

• Signals are replaced by WritableSignals
• RxMethods are replaced by FakeRxMethods
• Functions are replaced by spies

FakeRxMethods are generated by the newFakeRxMethod() function. A FakeRxMethod is a function, that accepts a static value, signal, or an observable as an input argument. It has a RX_METHOD_SPY property, contains a spy. This spy can store the call information, when:

• the FakeRxMethod was called with a static value
• the FakeRxMethod was called with a signal argument, and the signal's value changes
• the FakeRxMethod was called with an observable argument, and the observable emits

Source code for @ngrx/signals/testing with the provideMockSignalStore:

• The source code of @ngrx/signals/testing with the provideMockSignalStore function, added to my gergelyszerovay/ngrx-platform fork is here, PR with the changes
• The source code of @ngrx/signals/testing with the provideMockSignalStore function in the demo app's repo is here (this is the same code as the one in the gergelyszerovay/ngrx-platform repo)

This @ngrx/signals/testing implementation is assertation library independent, so I provided two examples with two different assertation library:

• Component test example with Jest assertations are here
• Component test example with Sinon assertations are here

[markostanimirovic]

Thank you Gergely! Do you plan to publish the plugin to NPM?

[gergelyszerovay]

Hey Marko,
Previously you mentioned that you might consider including this as an Ngrx core package. I'd be happy to contribute.
What do you think, would it be better to publish it independently from Ngrx?

[markostanimirovic]

Yes, I think it would be better to publish it as a community plugin. On the SignalStore side, we can allow unprotected state patching for tests to facilitate plugin implementation.

Btw, what's the difference between using rxMethod testing helpers compared to someRxMethod: jest.fn() / jest.spyOn(store, 'someRxMethod') ?

[gergelyszerovay]

we can allow unprotected state patching for tests to facilitate plugin implementation.

Would it be possible to provide a way to disable the lifecycle hooks from unit tests, too?

---

Btw, what's the difference between using rxMethod testing helpers compared to someRxMethod: jest.fn() / jest.spyOn(store, 'someRxMethod') ?

The  jest.spyOn(store, 'load') approach tracks when the component does this.store.load(...) calls:

it('should show movies (native Jest)', () => {
  // 👇 jest.fn()
  const load = jest.fn<void, [Signal<string>]>();

  const moviesStore = {
    movies: signal(new Array<Movie>()),
    loading: signal(false),
    load,
  };

  TestBed.configureTestingModule({
    imports: [MoviesComponent],
    providers: [
      {
        provide: MoviesStore,
        useValue: moviesStore,
      },
    ],
  });

  const fixture = TestBed.createComponent(MoviesComponent);
  fixture.autoDetectChanges(true);

  // 👇 the call we reference here was done in MoviesComponent's consturctor
  const studio = load.mock.calls[0][0]; 
  const input: HTMLInputElement = fixture.debugElement.query(By.css('input')).nativeElement;

  expect(studio()).toBe('');

  // ...

Source: https://github.com/ngrx/platform/blob/2dece709d7650e37404473f373e54377b79004b2/projects/ngrx.io/content/guide/signals/signal-store/testing.md#native-mocking

In some cases, we want to also track the times when the internal pipe in the rxMethod has been triggered. For example, if we would like to verify whether upon the <input>'s value change the pipe of load() has been triggered or not, we can use the newFakeRxMethod helper:

it('should show movies (native Jest)', () => {
  // 👇 newFakeRxMethod()
  const load = newFakeRxMethod(jest.fn());

  const moviesStore = {
    movies: signal(new Array<Movie>()),
    loading: signal(false),
    load,
  };

  TestBed.configureTestingModule({
    imports: [MoviesComponent],
    providers: [
      {
        provide: MoviesStore,
        useValue: moviesStore,
      },
    ],
  });

  const fixture = TestBed.createComponent(MoviesComponent);
  fixture.autoDetectChanges(true);

  const input: HTMLInputElement = fixture.debugElement.query(By.css('input')).nativeElement;

  // 👇 in MoviesComponent's consturctor, we passed the studio() signal to the rxMethod, and
  // the studio() signal's default value is '', we expect that RX_METHOD_SPY recorded it
  expect(load[RX_METHOD_SPY].mock.lastCall).toBe(['']);

  input.value = 'Warner Bros';
  input.dispatchEvent(new Event('input'));

  TestBed.flushEffects(); 

  // 👇 we expect that the code inside load() was executuded, as the studio() signal emitted a new value
  expect(load[RX_METHOD_SPY].mock.lastCall).toBe(['Warner Bros']);

  // ...

The example above is a unit test, but we can also use this approach in Storybook Stories and Storybook Play integration tests:

• we mock the store
• we simulate the user interactions on the UI and
• we make expectations to verify whether the UI interactions have triggered (or called) the store's updaters and effects properly

---

Yes, I think it would be better to publish it as a community plugin

I don't think I'll push this forward then. In case you decide to include it in the Ngrx core, I'm happy to support you in any way I can, but currently I don't have enough free time to maintain a separate community plugin.

[markostanimirovic]

Got it. Thanks for the explanation!

I don't think I'll push this forward then. In case you decide to include it in the Ngrx core, I'm happy to support you in any way I can, but currently I don't have enough free time to maintain a separate community plugin.

Sorry to hear that, but in case you change your mind, let us know and we'll try to provide the necessary support for the plugin implementation.