-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Cannot freeze array buffer views with elements #4645
Comments
This is probably a duplicate of #4635 |
@timdeschryver, I think that this could be a little bit different. Whereas #4635 is using data that shouldn't be in the state, this might be part of the state. @enrico-bellanti, as Tim said, we would require a short code snippet. |
This is the map.store.ts which throws the error: ` export interface MapState { const initialState: MapState = { export const MapStore = signalStore(
);` this is the part which throws the error
do you suggest a different approach to achieve this in ngrx 19.0.0? |
The quick fix would be to opt out Object.freeze when we encounter unfreezable types. The more important question is if these objects should actually end up in the state. You see, the concept of having an instance of a class is not really compatible with state that requires immutable changes. You would have to create a new instance whenever you want to change the value of a property. For example, layer.setVisible(false);
layer.setPrivate(true)
or set3DMode(is3DEnabled: boolean) {
const oLCesium = store.oLCesium();
if (oLCesium) {
// the next two lines just don't like right to me
oLCesium.setEnabled(is3DEnabled);
patchState(store, { is3DEnabled });
}
}, That's not how it should be. And it is not really related to State Management, that's an issue you have with normal Signals as well. |
So what do you suggest to be available that properties around the app ? with a service? and how to avoid Object.freeze of encounter unfreezable type in that state? |
The quick fix needs to come from us.
I see OpenLayers for the first time. Whereas the SignalStore is optimized for Angular Signals, OpenLayers doesn't use Signals at all. And if you force them into Signals, it might not be optimal. What could work, though, is to use the SignalStore for the state without OpenLayer types and then use |
We have two options:
I prefer the configuration approach, as it aligns with how this is handled in |
SignalStore's state has to be immutable. Mutable objects with methods are state containers themselves. They should not be defined as SignalStore state slices. Instead, you can define them as SignalStore properties using the |
Which @ngrx/* package(s) are the source of the bug?
signals
Minimal reproduction of the bug/regression with instructions
This error occurs because @ngrx/signals is trying to deeply freeze array buffer views in your map layers, which isn't supported. The issue is in the state management of OpenLayers map and layer objects.
map.component.ts:45 Error initializing map: TypeError: Cannot freeze array buffer views with elements
at Function.freeze ()
at deepFreeze (ngrx-signals.mjs:82:10)
at ngrx-signals.mjs:92:9
at Array.forEach ()
at deepFreeze (ngrx-signals.mjs:84:38)
at ngrx-signals.mjs:92:9
at Array.forEach ()
at deepFreeze (ngrx-signals.mjs:84:38)
at ngrx-signals.mjs:92:9
at Array.forEach ()
Expected behavior
there are lots of libraries which use ArrayBufferViews (not only open layers as example) and now updating NGRX signals to 19.0.0 i have lots of bugs come out, which can not store object which cannot be deepFrozen, this won't be happened with version 18.0.0
what is the best way to solve these kind of problems avoiding to entire refactor of the app which use @ngrx/signals?
Versions of NgRx, Angular, Node, affected browser(s) and operating system(s)
ngrx/signals 19.0.0
angular 19.0.0
Other information
No response
I would be willing to submit a PR to fix this issue
The text was updated successfully, but these errors were encountered: