3 ms·
Yes, I have read and found similar articles to what you've posted! It is an ongoing exploration for us to find the best way to store/consume reactive state dat
by softfalcon 2y ago
Yes, I have read and found similar articles to what you've posted!
It is an ongoing exploration for us to find the best way to store/consume reactive state data within our client sites/apps. So far, MobX has given us a lot of leeway since we can create the data store we want for our data.
Going forward, I foresee us switching to something closer to WatermelonDB or maybe even just SQLite with a thin wrapper in React to create observability. I'm not 100% sure where it's going to go, but I agree with you that flexible state management for large platforms evolves fast and the difficulty of creating fast look-ups rapidly approaches "reinventing the DB" client-side.
I've had to build similar on top of SQLite for various other mobile/desktop apps, the problem hasn't really changed, the only difference is we're now using React + JS instead of C++, C#, or Java.
All roads so far have led to SQLite though.
- svilen_dobrev 2y agoi have built similar thing long time ago, using couchdb as replication-storage mechanism, and it's variants on non-server platforms - touchdb/android/ios <-> pouchdb/js-browser etc , but yes, except serverside, all other platforms still had sqlite underneath. Long live sqlite :)
- bhl 2y agoI've done the same with mobx-state-tree, and realized I was essentially building a relational database with cache-ing in JavaScript. The only thing SQLite is missed, which is important when integrating with React, is incremental view maintenance: how do we maintain as much immutable state on an update as possible to avoid wasteful re-renders?