with-Methods and shared variables

[leomayer]

To my understanding the signalStore provides functionallity to encapsulate specific domain handling - supported by the with-methods. But one downside (or plus - don't know) is that the variables are somehow encapsulated, meaning I cannot access from the signalStoreFeature to the signalStore. Is there a way to achieve it?

I have currently defined a store like this

initSearchState={
  selectedFlightNo: number
  ... // other properties, e.g. paging details
}
export const SearchStore=signalStore(
  withState(initSearchState),
  ...
  withPermissions(),
  ....
}

and the withPermissions feature like

initPermissionState={
  selectedFlightNo: number
... // permission-related properties
}
export function withPermissions(){
  return signalStoreFeature(
    withState(initPermissionState),
    ...
    withMethods((permissionState) => (
    ...
     handOverSearchFlight(selectedFlightNo: number) {
       patchState(permissionState, {selectedFlightNo}
    

My idea is to forward the selectedFlightNo from the store to the encapsulated signalStoreFeature. Right now the above code complains that selectedFlightNo is overridden which sounds somehow strange. Strange in sense of: I cannot access from the feature to the store - so how can they override?

If I change

initPermissionState={
  selectedFlightNo_permission: number
... // permission-related properties
}

no further complaints. But nevertheless it won't solve the initial problem with handover.

[rainerhahnekamp]

You don't add a new state but withPermissions should define that the signalstore which calls it, must have a certain state already:

export function withPermissions(){
  return signalStoreFeature(
    type<{ state: { selectedFlightNo: number } }>(),

     withMethods((permissionState) => (
       handOverSearchFlight(selectedFlightNo: number) {
         patchState(permissionState, {selectedFlightNo}

More info: https://ngrx.io/guide/signals/signal-store/custom-store-features#creating-a-custom-feature-with-input

[leomayer]

Thx for the suggestion.

Nevertheless I'm getting confused about the "real" value of the variable selectedFlightNo. I have declared it in the signalStore and use it there as read/write. In the withPermission I need to have "read"-access for further evaluation, e.g. admins only see on prime flights (like those leaving from "Graz") additional information. So, with your proposal I should have access to the selectedFlightNo within withPermission AND I don't need to "handOver" the variable? If I would run a patchState than it would overwrite the value from the signalStore as well? (And everything might get messed up)

IFFF I follow your suggestion than I would implement type from ngrx/signals. I tried to do so with your basic sample of QuizStore. https://stackblitz.com/edit/github-wmbu93qc But this won't compile. Basically I have quiz-permission.state and tried to implement it the way I would have done it in our project.

If you comment the line with type<... and adapt the computed it should compile.

[rainerhahnekamp]

Here’s the corrected version. It looks like the typing is incorrect in your implementation: StackBlitz link.

I’m still trying to fully grasp your requirement. Could you provide an example using the flight store that better aligns with your original intent?

[leomayer]

Honestly its quite some time when I adapted the code.

Use case for the 'fligh app': Once you've selected a flight you can start editing the flight, e.g. airplane-type, free seats, price per seat, etc. But this is only possible if you have the proper user permissions.

Basically this would mean you need to add 2 dimensions: permission and editing data. Both you need to hand over from one to the other. Right now I would think about splitting into several stores, nevertheless there is some kind of hand over required. Which is my basic question about "hand over" and/or "shared variables" (see above).

For me the signalFeature is more a way to capsulate the code into different sections which could be maintained differently - not all in one file.