-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: SignalStore with WritableSignals and ReadOnlySignalStore #4283
Comments
This RFC proposes a different approach to #4210 feat(signals): Encapsulation |
@marklagendijk: I have a prototype for that So if you have const user = signalStore(withState({firstname: 'Hugo', lastname: 'Schmidt'})); It would be great to have an easy option to use it in the template like <input [(ngModel)]="user.firstname">
<input [(ngModel)]="user.lastname"> |
That could indeed be nice. Especially for component level stores. I think it could make sense to have these two options be separate functions. For example |
I think this is a great idea! Although it seems pretty complicated as you can't use computed here. |
@Harpush I think for the Form use case, it is not necessary to use computed. If yes, we are talking here about two different models. One "state model" and a "form model" which will eventually require a mapper in between. |
Maybe a graph flip is possible? Leaves will be signals while parents will be computed. Not entirely sure this is possible though |
@Harpush do you have an example? I'm afraid I don't fully get your point. |
@rainerhahnekamp For example if I have: interface State {
a: number;
}
const initialState: State ={
a: 2
}; The logic will be (somehow dynamically if possible which I am not sure): const a = signal(2)
const state = computed((): State => ({a: a()})); So we have |
As SignalState, let's say "FormState". It would simplify a lot |
Which @ngrx/* package(s) are relevant/related to the feature request?
signals
Information
When thinking about how Signals should change the Store concept, I thought: there should be a SignalStore.
So I googled for 'signal store' and found the beautiful implementation that has been created in NgRx.
There were two main features that I loved:
However, I also found two points that were disappointing:
patchState
which is called with the Store instance, instead of being done viaWritableSignal
. This point goes against 'building on existing Signal functionality'.This morning I woke up with an idea for tackling both these points. I do not know if:
It will be acceptable to introduce such a big change to the SignalStore. I would expect it would at least be a major version.Since the package is still in developer preview, it should be fine.The idea:
SignalStore
will holdDeepWritableSignal
s.withX
calls get theSignalStore
as argument, and can update any signal value via the normalset
andupdate
methods of those signals. For nested values this would look like this:store.person.address.street.set(value)
.signalStore
is not aSignalStore
but aReadOnlySignalStore
. TheReadOnlySignalStore
is a clone of itsSignalStore
, except that all it's signals are read only (asReadOnly)I would be willing to submit a PR to fix this issue
I would love to, but I don't think it is feasible for me to do so.
The text was updated successfully, but these errors were encountered: