SignalStore V19: Warnings

[leomayer]

I have a Search component and an Edit component. For the search component I have a SignalStore. This should be initiated any time as I switch to the Search component. Therefore I don't inject the SearchStore on root level, I inject it on component level, i.e.

@Component({
...
providers: [SearchStore],
})
export class MySearchMainComponent {
  mySearchStore=inject(SerachStore);

In SearchStore I have defined something like

export const SearchStore=signalStore(
...
  withComputed((state)=> {
    const userCache=inject(UserCache);
    return {
      hasAccessToAdvancedSearch: computed(() => userCache.priviliges.includes('ADVANCED_SEARCH');
    }

The problem/issue/remark:

Any time I switch to SearchComponent I get a warning:

MySearchMainComponent.ts:17 @ngrx/signals: SignalStore members cannot be overridden. Trying to override: hasAccessToAdvancedSearch

• Any suggestions how to define hasAccessToAdvancedSearch in a better way? The intention was/is that the field is computed just once and the result will be kept.
• Is it worth opening an issue?

[leomayer]

Sorry, after posting my comment I've got an idea how to fix this "initial" state. But than I've discovered that I have defined hasAccessToAdvancedSearch already as state in the initialState. Therefore comment makes sense !
Perhaps a more clear description would help. AND additionally in my case: I would have expected an thrown Error since the double definition (as state & computed) won't make any kind of sense.

Please feel free to close the ticket.

[timdeschryver]

What do you suggest to make the message more clear?

[leomayer]

hasAccessToAdvancedSearch cannot be defined multiple times

Multiple definitions found hasAccessToAdvancedSearch

SignalStore allows only one definition of hasAccessToAdvancedSearch

Or similar...

And additionally an error - or is there a use case when multiple definitions make sense? One can hardly know which one is used.

[timdeschryver]

Thanks for the suggestions, we'll take them in consideration.

Overriding members is by design, because it's a plugin-based system we see that there might be a use-case where overriding a previous member (e.g. from a 3rd party) can be desired.
See #4144 (comment)

[leomayer]

Hmmm... I'm getting little bit confused cause with the new V19 there is deep frozen state machine which should assist in preventing some "hard to debug" issues and on the other hand the "plugin system" should allow this.

For me these things are contradictory and the arguments of the current behaviour in V19 with the deep frozen state would apply as well for protection for overriding. And if protection is not required I don't understand why then deep freezer?

Anyway I guess there is an unknown direction I cannot grasp and with V19 the changes are major - especially when V18 already finished, up and running.