Thankyou, This looks brilliant! I too really am a fan of the original global store, and redux pattern, and the devtools. When using the other stores, such as component store, I essential thing I really missed was the the devtools, as they have been a life saver to me in the past when debugging and tracking what actions change the state. This would be worth it just for the devtools, but now also with this redux pattern as well, this will really could convince me to swap from the global store over to the signal store.
wie ist das mit dem Feature withDevTools in production Mode... ich muss den Toolkit ja unter "dependencies": { installieren, weil ich ja evtl. withcallState verwenden möchte. In Produktion möchte ich aber nicht die Devtools sehen ?
Hast recht. Es gibt da eine schnelle und eine etwas längere Lösung. Die schnelle ist ein Flag, wo du es während der Produktion nicht läuft, aber das JavaScript trotzdem im Bundle ist. Die lange ist, dass es auch aus dem Bundle fliegt. Das wird ein bisschen knackiger. Kannst du fürs erste Mal mit der schnellen Lösung leben? Installieren musst das toolkit natürlich in dependences (hast eh schon erklärt wieso).
@@RainerHahnekamp Hi Rainer :-) super danke für die schnelle Antwort... das Flag muss ich dann selber in meinen Store einbauen? oder gibt es das irgendwo ? liebe Grüsse :-)
@@koempf Serwas, nein das gibts noch nicht. Das müsste ich noch machen. Wäre super, wenn du mir einen Issue auf GitHub anlegen könntest. Dann hab ich einen offiziellen "Arbeitsauftrag". Falls nicht, kanns aber ich auch so machen.
@@RainerHahnekamp super ich mache einen Eintrag :-) noch kurz eine letzte Frage :-) bei der standalone patchState function... da muss ich bei Objekten immer die immutability beachten ? ich wurde da bei einem internen Vortrag gefragt ob es dafür eine Library gibt um das nicht immer machen zu müssen 🙂
Thankyou, This looks brilliant! I too really am a fan of the original global store, and redux pattern, and the devtools. When using the other stores, such as component store, I essential thing I really missed was the the devtools, as they have been a life saver to me in the past when debugging and tracking what actions change the state. This would be worth it just for the devtools, but now also with this redux pattern as well, this will really could convince me to swap from the global store over to the signal store.
wie ist das mit dem Feature withDevTools in production Mode... ich muss den Toolkit ja unter "dependencies": { installieren, weil ich ja evtl. withcallState verwenden möchte. In Produktion möchte ich aber nicht die Devtools sehen ?
Hast recht. Es gibt da eine schnelle und eine etwas längere Lösung. Die schnelle ist ein Flag, wo du es während der Produktion nicht läuft, aber das JavaScript trotzdem im Bundle ist. Die lange ist, dass es auch aus dem Bundle fliegt. Das wird ein bisschen knackiger. Kannst du fürs erste Mal mit der schnellen Lösung leben? Installieren musst das toolkit natürlich in dependences (hast eh schon erklärt wieso).
@@RainerHahnekamp Hi Rainer :-) super danke für die schnelle Antwort... das Flag muss ich dann selber in meinen Store einbauen? oder gibt es das irgendwo ? liebe Grüsse :-)
@@koempf Serwas, nein das gibts noch nicht. Das müsste ich noch machen. Wäre super, wenn du mir einen Issue auf GitHub anlegen könntest. Dann hab ich einen offiziellen "Arbeitsauftrag". Falls nicht, kanns aber ich auch so machen.
@@RainerHahnekamp super ich mache einen Eintrag :-) noch kurz eine letzte Frage :-) bei der standalone patchState function... da muss ich bei Objekten immer die immutability beachten ? ich wurde da bei einem internen Vortrag gefragt ob es dafür eine Library gibt um das nicht immer machen zu müssen 🙂
@@koempf ja, gibts: github.com/timdeschryver/ngrx-immer. Wir werdens aber auch im toolkit irgendwann aufnehmen.