Platform: Add overload support for StoreModule.forFeature({ name, reducer })

Created on 8 Dec 2020  路  10Comments  路  Source: ngrx/platform

Proposal

I propose a new overload signature of StoreModule.forFeature().

StoreModule.forFeature({ name, reducer });

Motivation

The interface {name, reducer} is compatible with the Slice type from Redux Toolkit package.

Redux Toolkit is a set of best practices for using Redux. I think it's better to have interoperability with that.
With Redux Toolkit, a typical small example will be like below:

import { createSlice } from '@reduxjs/tooklit';
import { StoreModule } from '@ngrx/store';

const counterSlice = createSlice({
  name: 'counter',
  initialState: { count: 0 },
  reducers: {
    increment: (state) => { state.count++; }
  }
});

@NgModule({
  imports: [
    StoreModule.forFeature(counterSlice.name, counterSlice.reducer)
  ]
})
export class CounterFeatureStoreModule {}

A slice has its name and reducer. Its concept is similar to NgRx's "feature". So I want to link them seamlessly. The following is an example when forFeature()supports {name, reducer} option.

import { createSlice } from '@reduxjs/tooklit';
import { StoreModule } from '@ngrx/store';

const counterSlice = createSlice({
  name: 'counter',
  initialState: { count: 0 },
  reducers: {
    increment: (state) => { state.count++; }
  }
});

@NgModule({
  imports: [
    StoreModule.forFeature(counterSlice)
  ]
})
export class CounterFeatureStoreModule {}

Describe any alternatives/workarounds you're currently using

Other information:

If accepted, I would be willing to submit a PR for this feature

[x] Yes (Assistance is provided if you need help submitting a pull request)
[ ] No

Store enhancement

Most helpful comment

Hey, just wanted to say that I love this idea! It's really neat to see interop back and forth between the Redux and NgRx ecosystems. We probably _should_ have more interop than there is now, so it's great to see suggestions like this!

All 10 comments

Just out of interest, are you using redux toolkit with NgRx @lacolaco ?

@timdeschryver Recently I'm experimenting that interop and I feel it works well more than I expected.

NgRx's Redux-compability (shape of actions and reducers) is great for integrate to Redux ecosystem.

Demo: https://codesandbox.io/s/ngrx-store-redux-toolkit-example-pg930?file=/src/app/counter/counter-slice.ts

When I use Redux Toolkit with NgRx Store, the role of NgRx is just bridging Angular's dependency injection system and Redux state management. Redux Toolkit can help developers to create state management logic with (almost) zero boilerplates but it doesn't have a lazy-loading mechanism. I think NgRx store can be thinner by delegating Redux-things to the Toolkit.

@lacolaco
Here's the library with similar functionality: https://github.com/markostanimirovic/ngrx-handlers

When I created it, I was not aware of createSlice function from Redux Toolkit. Anyway, in V11 NgRx Handlers will be adapted to good action hygiene, it will be in accordance with [source] event action style.

Hey, just wanted to say that I love this idea! It's really neat to see interop back and forth between the Redux and NgRx ecosystems. We probably _should_ have more interop than there is now, so it's great to see suggestions like this!

@lacolaco seems reasonable to me to have some interop here.

@markerikson Glad to see you're here. If this lands, would it make sense to have createSlice to allow for customize the action.type to allow for Good Action Hygiene? Eg:

createSlice({
   name: 'counter',
   initialState: { count: 0 },
   reducers: {
      increment: state => state.count ++
   }
})

slice.actions.increment() returns { type: 'counter/increment' }. It would be nice if createSlice provides a custom function: (sliceName: string, actionName: string) => string to customize the type on the action creators. This would allow for slice.actions.increment() to return { type: '[counter] increment' } instead.
https://github.com/reduxjs/redux-toolkit/blob/d5f1b65541c8b2a7b99b7e7ba5d34c6c3e2ac896/src/createSlice.ts#L231

I'm _reallllly_ hesitant to do that, especially because our TS types are already stupidly complex, and more options are just going to make that more difficult to deal with.

Also, part of the point of RTK is to be opinionated and just handle that stuff for you.

If someone wants to take the time to figure out how that _might_ be implemented and file a PR, I'm open to discussing it, but I'm going to need convincing this is a thing that is really worth adding to RTK.

@brandonroberts Thanks. Does it mean could I start creating a PR?

@lacolaco sure

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hccampos picture hccampos  路  3Comments

itprodavets picture itprodavets  路  3Comments

doender picture doender  路  3Comments

Matmo10 picture Matmo10  路  3Comments

brandonroberts picture brandonroberts  路  3Comments