Is your feature request related to a problem? Please describe.
BehaviorSubjects are extremely useful for state management. Subjects by being observable streams are pure-functions, but to really make it useful for the state management, the state the subject contains should be read-only. getValue method is extremely useful because it is synchronous, but it returns the reference to the state that can be modified.
Describe the solution you'd like
getValue should return a deep copy of the state.
Describe alternatives you've considered
I use a wrapper for BehaviorSubject, where getValue returns a deep copy.
getValueshould return a deep copy of the state.
This would be a breaking change, would be potentially expensive and cannot be implemented in a general way. IMO this is not something for which this package should be responsible. The caller has the opportunity to pass whatever she/he wants to the constructor and the next method. The caller should assume the responsibility for managing that value's immutability. That is, rather than rely upon getValue to return a copy, the caller should ensure the aforementioned values are not mutated after they are next-ed.
Thanks for the quick response. I can see that. Maybe there could be an optional configuration in the BehaviorSubject's constructor that would allow such scenario?
Maybe there could be an optional configuration in the
BehaviorSubject's constructor that would allow such scenario?
That would mean all users would have to pay the price for something few will need, use or want. IMO, this package should be providing primitives that people can compose into solutions. And BehaviorSubject already allows you to do that. User-land solutions should be encouraged, IMO.
Closing this as out-of-scope regarding this package's responsibilities.
Most helpful comment
This would be a breaking change, would be potentially expensive and cannot be implemented in a general way. IMO this is not something for which this package should be responsible. The caller has the opportunity to pass whatever she/he wants to the constructor and the
nextmethod. The caller should assume the responsibility for managing that value's immutability. That is, rather than rely upongetValueto return a copy, the caller should ensure the aforementioned values are not mutated after they arenext-ed.