Open bowheart opened 4 months ago
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
@bowheart: PR needs rebase.
Description
Remove the Store class's
hierarchyConfig
static property. This is a breaking change, but likely won't affect any Zedux users since we left this feature undocumented, intending to remove it.The hierarchy config allowed stores to use different hierarchical data structures besides the default JS object. Zedux would then be able to intelligently merge nested reducers and stores together in e.g. an Immutable Map. Its
setStateDeep
would also use thehierarchyConfig
In practice, this is never used. Reducers are almost never used in Zedux and there's no point to using Immutable JS to wrap a simple child store mapping. It's easy to create an ImmutableJS zero-config store by setting that as the value and using
setState
on that value directly, ignoringsetStateDeep
.If deeper functionality is needed, users are still able to extend the
Store
class (another undocumented feature) and modify absolutely everything. While that's more involved, it's probably necessary anyway - as it is,hierarchyConfig
doesn't work intuitively for nested stores. Expanding Zedux's currenthierarchyConfig
model to cover all use cases would not be simple, would add codebase bloat, and would still never be used. Most importantly it would be redundant - since extending theStore
class is already possible, we should make it the only way to add rarely-needed functionality like this.