Migrate mobx to zustand #583
Conversation
enigma0Z
force-pushed
the
feature/migrate-mobx-to-zustand
branch
from
d7d441a to
5da37f1
Compare
enigma0Z
force-pushed
the
feature/migrate-mobx-to-zustand
branch
from
dd1ea2e to
17e18fb
Compare
…store setups to use `_get` and `_set` for future prep
|
Question, btw: What is the process for an updated version of the app to be built and released to the app stores (particularly iOS) -- the current version is 1.5.0 and is two years old. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #583 +/- ##
==========================================
- Coverage 60.10% 58.68% -1.43%
==========================================
Files 47 47
Lines 945 973 +28
Branches 189 198 +9
==========================================
+ Hits 568 571 +3
- Misses 342 365 +23
- Partials 35 37 +2 ☔ View full report in Codecov by Sentry. |
How much does this report matter for getting things merged? The code I changed was more just getting the state references updated, I suspect the coverage for these was roughly at these numbers before I touched anything. |
…tive or something similar -- this only happens in ts files
Well... this is in progress. We are working on setting up GitHub Actions to build and publish to TestFlight. Previously we used Expo's legacy build service to build and then manually upload. We have been more or less blocked from publishing new releases since the legacy build service was discontinued. |
It's probably fine 👍 |
Understandable; Do you need any help with this? |
|
I don't think so... at least for now the main thing is getting some secrets added to the repo (there have been some other more pressing issues Anthony has been dealing with so this is understandably taking some time) then we can iterate on the action until we get a working build. We have been able to reference Swiftfin so hopefully it will be pretty straightforward once the secrets are available. |
|
Overview
use<Store>Store()call (such asuseDownloadStore()vs. anew StoreClass()calluseStores()has been preserved for convenience and refactoringjsdomenvironment if they manipulate stateset()function added to all that allows you to set any property in state; logical setters (e.g.addSever()) have been preservedBackground
mobx is currently blocking an upgrade to Expo 51 & React 18. See PR #539. @thornbill suggested zustand as a reasonable replacement. This PR resolves issue #564 .
Implementation
Zustand is functional (vs. mobx's class-based code). Essentially, instances of
StoreClasshave been replaced withuseStore()calls instead. The stores have been broken out into their individual components, which are serialized and stored separately inAsyncStore, persisted by zustand middleware into the same (already in use)AsyncStorageState Storage
To access state, use the
use<Store>Store()method from the correct store's module (e.g.useDownloadStore().Test Development
jsdomenvironment to be establishedact(() => {<state change here>})call (you'll see this in most store test suites)Merging
While I normally don't like squash merges, I think that it's the right call here since this is essentially one wholesale sweep of changes that convert from mobx to zustand. If the package maintainers object, I'm happy to try to rewrite my commit history to be more concise, though I think that's probably not the right call personally.