Rxjs: BehaviorSubject state should be read-only (getValue should return a new copy of state)

Created on 26 Oct 2019  路  4Comments  路  Source: ReactiveX/rxjs

Feature Request

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.

Most helpful comment

getValue should 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.

All 4 comments

getValue should 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.

Was this page helpful?
0 / 5 - 0 ratings