Limitations of watermelon:
-
You will never get rid of loading states, even if data is already cached, because watermelon doesn’t use in-memory cache, so it makes IO operation on each request. App will never feel fast, like Telegram for example.
-
If user doesn’t have free space on disk the app just won’t work at all, again because app uses disk as the main cache, not RAM. Proper handling is just to stop persisting new data but allow to use the app, send and receive messages etc. But it is not possible with watermelon.
-
Optimistic UI also doesn’t exist from the box, if you implement it with watermelon it can lag because SQLite is pretty slow, much slower than RAM, especially if it already has some queue of tasks to read / write.
V1 has pretty bad redux architecture (but can be improved pretty fast), it also uses redux-persist which is not supposed to be used for big amounts of data, doesn’t throttle websocket events (which is also simple to do), so its performance can be greatly improved and app will feel much faster because it uses in-memory cache.
But persistence should be minified and used something better than redux-persist.