Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

@rx-signals/angular-provider

Package Overview
Dependencies
Maintainers
1
Versions
15
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@rx-signals/angular-provider

angular module for an opinionated @rx-signals/store integration

  • 3.0.0-rc4
  • Source
  • npm
  • Socket score

Version published
Weekly downloads
1
decreased by-50%
Maintainers
1
Weekly downloads
 
Created
Source

@rx-signals/angular-provider

You can use this lib for an opinionated rx-signals integration into your Angular application.

Installation

npm install --save @rx-signals/angular-provider@3.0.0-rc4

If you have not yet installed the rx-signals store, please see @rx-signals/store documentation on how to install the latest 3.x version of that peer-dependency.

License

MIT

Usage

The standard-case should be to use a single Store instance over your whole application.

Using a single store instance over the whole application

In the topmost module that should use the store (AppModule, SharedModule, CoreModule, or whatever it is for you), you can just import RxSignalsStoreModule. This will provide a Store singleton everywhere (so even lazy-loaded feature-modules will receive the same instance).

Instead, if you have functions performing setup with the store ((store: Store) => void), you can use RxSignalsStoreModule.withRootStore(), passing as many of those setup-functions as arguments as you like.

You can also use RxSignalsStoreModule.withRootStore() in your feature-modules (whether lazy or not) to pass corresponding setup-functions of those feature-modules.

You might be used to modules that come with forRoot() and forFeature() functions. These names make no sense in case of the RxSignalsStoreModule, because the standard-case is to use a single store-instance in all your modules and thus, all these modules should call withRootStore(). See the next section on use-cases for withChildStore().

Optionally using child-stores

If you are really sure that you have a feature-module where you want to use a child-store (derived from the root-store that you get with RxSignalsStoreModule or RxSignalsStoreModule.withRootStore()), then you can do so by importing RxSignalsStoreModule.withChildStore().

Make sure to read the documentation on child-stores.

Also, be aware that store-lifecycles might be a better option for your use-case.

Setup effects

If you read about the concept about side-effect-isolation with the store, you know that the only side-effect that the functions passed to RxSignalsStoreModule.withRootStore() and/or RxSignalsStoreModule.withRootStore() are allowed to to is calling methods of the passed store. All the signals being setup in this process should be free of side-effects (allowing you to call the setup-functions in your tests without any need of mockup).

Consequently, the side-effects must be injected to the store by corresponding calls to store.addEffect.

The suggested way to do so, is to inject the store in services that perform the effects and call store.addEffect there. In your unit-tests, you would then just mock the effects themselves by store.addEffect(effectId, () => someMockupReturn) (so no need to mock the whole service).

Keywords

FAQs

Package last updated on 13 Apr 2022

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc