(Result is to be treated like a standard monad, with helper functions like `mapResult`, `mapError`, `flatMapResult`) Without a strategy to avoid flickering, you’re causing A LOT more rendering passes by asynchronous operation, which are expensive.Īnd so we’ve been experimenting with using WatermelonDB synchronously to get rid of flickering and to improve performance.Īs of v0.15, I recommend using new LokiJSAdapter(.So you’re adding a lot of overhead on main thread, while only moving the minority of work to a separate thread
#Flickery thoughts how to
And we’ve never fully documented how to do this, so I suspect most 🍉 users just deal with glitches and flicker. The idea was that React Suspense is just around the corner, and it will make asynchronous data fetching and rendering really simple and awesome, and in the meantime we can use prefetching to make sure we load all necessary data ahead of time so that it’s already cached by the time it’s needed.Ī year or more has passed, and React Suspense is still around the corner - and while amazing, it’s not a magic bullet (more on that later).Īnd prefetching has not worked super great for us, because it’s a really fragile solution. There’s just this thing: data fetched in React components that doesn’t come back synchronously means that the component will always render twice: first blank, then with content. And there are a few more potential powerful features that async api enables (you could make a network-based database adapter! 😱).īuuuuuut. Partly due to a belief that since databases are heavy, harnessing the power of parallelism/multithreading (both on React Native, and on the web using web workers), we’ll be able to make our app a lot faster. Long story short, this is partly due to necessity - in 2017-2018 there has not been a good/easy/sanctioned way in React Native to make synchronous Native Modules (this has been a big selling feature for people coming from Realm RN which is really annoying to use with Chrome debugger because it’s designed as fully synchronous, and remote debugger is not). Flickeringįrom the very beginning, 🍉 has had a fully asynchronous API, based on Promises and Observables. I’ve made huge progress in 0.15, making sync time 5x faster on web and 23x faster on iOS + a lot of incremental improvements here and there. For example: adding massive amounts of data at once has not been very fast on iOS and Android.
Lazy loading of data making app launch time fast has been a selling point for WatermelonDB from day one. Performanceįirst of all: I’ve been working on making 🍉 really, really fast.
#Flickery thoughts free
This is a request for comments, too, so please feel free to comment with your thoughts.
#Flickery thoughts update
An update on what I’ve been working on recently, and my plans for the upcoming weeks and months.
0 kommentar(er)
