This PR introduces 2 new packages that we can switch to using provided they look good to folks.
@w3ui/core - basically a createClient method and an interface for the core reactive state.
@w3ui/react - React adapter that provides a Provider for the core reactive state and some React based headless components that use the Provider.
Eventually we would have a @w3ui/solid and @w3ui/vue...
Rationale
I wanted to add space usage reports and filecoin info but had to update the access client and w3up-client. This meant that I would have had to make many breaking changes to the old modules, which were exposing methods like createSpace etc. - which are essentially proxies for client methods...Instead I thought that a clean slate that allowed us to more easily update the client in the future without causing massive refactors in w3ui would be beneficial.
Goals
Lean in on exposed client (the w3up-client instance) - this means changes in the client do not lead to big refactors in w3ui
Expose minimal state through providers - right now just accounts & spaces
Reactive datasource, not reactive domain objects - So we don't have to manually update our reactive state or create proxies for the purpose of providing reactivity.
"Current space" is an application concern, not a library concern. - This will be refactored out of the client soon so lets not use it here.
Fewer modules to release - less dependency hell, faster to iterate.
Single entry point @w3ui/react - In applications, we shouldn't have to import types/values from modules other than @w3ui/react - lets not expose our multi-client futzing to our users.
This PR introduces 2 new packages that we can switch to using provided they look good to folks.
@w3ui/core- basically acreateClientmethod and an interface for the core reactive state.@w3ui/react- React adapter that provides aProviderfor the core reactive state and some React based headless components that use theProvider.Eventually we would have a
@w3ui/solidand@w3ui/vue...Rationale
I wanted to add space usage reports and filecoin info but had to update the access client and w3up-client. This meant that I would have had to make many breaking changes to the old modules, which were exposing methods like
createSpaceetc. - which are essentially proxies for client methods...Instead I thought that a clean slate that allowed us to more easily update the client in the future without causing massive refactors in w3ui would be beneficial.Goals
client(thew3up-clientinstance) - this means changes in the client do not lead to big refactors in w3uiaccounts&spaces@w3ui/react- In applications, we shouldn't have to import types/values from modules other than@w3ui/react- lets not expose our multi-client futzing to our users.Non-goals