WithReducers (access to Store or possible to Inject Services)?

[dreamstar-enterprises]

Hi,

I try to use reducers to change the state of a store, with a full state change or a partial.

Using WithReducers, though, I cannot access props from the store (where I originally injected services).
I also cannot inject services in the 'on' method, as I get a DI error.

For example, here I simple cannot use any logging service:

Do I have to use WithEffects, or is it possible with a Reducer?

return signalStoreFeature(
    {
      state: type<UserProfileState>(),
      props: type<{
        _logger: LoggingService,
        _storeName: string,
      }>(),
    },
    withReducer(
      on(
        userProfileEvents.gotUserBasicWithStatus,
        ({payload: response}) =>  (state) : Partial<UserProfileState>  => {

          const logger = inject(LoggingService)
          const storeName = 'UserProfileStore';

          logger.info('Reducer: DTO.', storeName, { backendUserStatus: response.userAccountStatus, hasProfileData: !!response.userProfileBasic });

          try {
            UserBasicWithStatusDTOSchema.parse(response);
          } catch (validationError) {
            const errMessage = 'Invalid DTO structure received from backend.';
            logger.error(errMessage, storeName, validationError);
            return {
              userProfileBasic: null,
              status: UserProfileOperationStatusEnum.ERROR,
              error: errMessage,
            };
          }

[rainerhahnekamp]

That's by design. reducers should be pure functions. No async tasks, no access to DI or similar. So you should add all the necessary information for the reducer to the event when it is dispatched. That could be done by an effect for example

Logging is actually a cross-cutting concern. You could also inject the events service in a service and listen to all events separately.

[dreamstar-enterprises]

Hi Rainer,

Thanks for explaining. Ok that does make sense.
I guess I cannot use an injected logging service in side a reducer either.

I've refactored my code and moved the reducers into an effect (as I also have access to the store that way)
You're likely right too. Any changes to the state, if using a reducer, should be passed through the event, when it is dispatched.

Thanks again,

Sachin

[rainerhahnekamp]

(as I also have access to the store that way)

Just a quick note: you shouldn’t directly update the state from an effect either. There’s a reason the effect has access to the store, but it’s not for direct mutation: #4769 (comment)

In general, Redux-style architecture follows two clear steps:

1. Effects handle side effects (like calling services or accessing DI). Once complete, they dispatch a second event with all the necessary data to update the state.
2. That second event is handled by a reducer, which is a pure function that updates the state.

That’s the canonical model. But if you find this a bit too boilerplate-heavy, you’re not forced to go that route — Events are optional.

[dreamstar-enterprises]

Hi Rainer,

Thank you for clarifying.

Yes, I moved the function from the reducer, to the effect, to then back into the method (as a private helper method)
I did want it in the reducer, but really needed a logging service, so have a method with patchState that does the same.

My effects now just really detect dispatched events (from component or another store), and then either

• emit another event (that a reducer listens to), or
• directly call a store method (e.g. for state updates that reducers can't do, e.g. when I want a logging service, or need access to other parts of the store)

Overall, I see the effect as an intermediary. Listen to an event, and then get something else (a reducer or method) to do something.

Lots of coding to do!

Sachin