Is your feature request related to a problem? Please describe.
When using Neo.state.Provider to manage Neo.data.Store instances, binding to reactive properties of these stores (e.g., store.count_) requires a cumbersome multi-step process:
- Defining a separate reactive data property within the
StateProvider's data config.
- Adding a
listeners config to the store definition within StateProvider.stores to listen for the relevant change event (e.g., countChange).
- Implementing a handler method within the
StateProvider to update the data property when the store's reactive property changes.
- Finally, binding components to this newly created
data property.
This boilerplate makes it less intuitive and more verbose to leverage the reactivity of stores within the StateProvider system.
Describe the solution you'd like
Enhance Neo.state.Provider to automatically expose or allow direct binding to the reactive properties of its managed stores. Ideally, a syntax like bind: { text: 'stores.mySharedStore.count' } should directly reflect the count_ property of the mySharedStore instance, without requiring manual proxying through the StateProvider's data config and event listeners.
Possible approaches could include:
- Automatic proxying of reactive store properties into the
StateProvider's data namespace.
- A more sophisticated binding mechanism within
StateProvider that can directly resolve and observe reactive properties of nested store instances.
Describe alternatives you've considered
The current workaround involves manually proxying the store's reactive properties to the StateProvider's data config, as described in the problem statement. While functional, it adds unnecessary complexity and boilerplate, especially for common reactive properties like count_.
Additional context
This enhancement would significantly improve developer experience and reduce boilerplate when working with reactive stores and Neo.state.Provider, making the state management system even more powerful and intuitive.
Is your feature request related to a problem? Please describe. When using
Neo.state.Providerto manageNeo.data.Storeinstances, binding to reactive properties of these stores (e.g.,store.count_) requires a cumbersome multi-step process:StateProvider'sdataconfig.listenersconfig to the store definition withinStateProvider.storesto listen for the relevant change event (e.g.,countChange).StateProviderto update thedataproperty when the store's reactive property changes.dataproperty.This boilerplate makes it less intuitive and more verbose to leverage the reactivity of stores within the
StateProvidersystem.Describe the solution you'd like Enhance
Neo.state.Providerto automatically expose or allow direct binding to the reactive properties of its managed stores. Ideally, a syntax likebind: { text: 'stores.mySharedStore.count' }should directly reflect thecount_property of themySharedStoreinstance, without requiring manual proxying through theStateProvider'sdataconfig and event listeners.Possible approaches could include:
StateProvider's data namespace.StateProviderthat can directly resolve and observe reactive properties of nested store instances.Describe alternatives you've considered The current workaround involves manually proxying the store's reactive properties to the
StateProvider'sdataconfig, as described in the problem statement. While functional, it adds unnecessary complexity and boilerplate, especially for common reactive properties likecount_.Additional context This enhancement would significantly improve developer experience and reduce boilerplate when working with reactive stores and
Neo.state.Provider, making the state management system even more powerful and intuitive.