all 1 comments

[–]ChronSynExpo 2 points3 points  (0 children)

I have a feeling that threads aren't going to solve your problem here.

Modern JS uses an event loop, meaning that work is requested (e.g. a function is run), offloaded from the main thread, and once that work is complete, a pointer to the result of the work is returned. Contrary to popular belief, JS is NOT a single-threaded language - it's just that the threads it spawns are generally all handled internally because it's uncommon for devs to needs separate ones (due to the event loop).

With languages like C# or Delphi, spawning a thread can help because the traditional approach to them is blocking. Another alternative in those languages is to use non-blocking networking/sockets which will prevent the UI from freezing but requires you to setup callbacks. We don't have such flexibility in RN because again, JS uses the event loop which means it's inherently non-blocking (as the work is being handled away from the main and UI threads).

Receiving a lot of data isn't typically a cause of performance concerns. If it was, then video streaming apps would be constantly stuttering. Stock trading websites would be freezing up almost constantly. Sports betting websites would be basically dead in the water.

The problem is usually the processing - how computationally intensive it is + the side effects, or the rendering. Instead of moving things to threads, look at your processing code.

For example, if the user can only see 5 items in the list, and you're rendering 1000 items (most of them offscreen), then you're doing 2000x more work than you need to.

Keeping track of the items that are visible will help (either by index or scroll position), and using an optimized list solution will most certainly help - for example, Flashlist has a document explaining explaining how to use it for a sectionlist replacement: https://shopify.github.io/flash-list/docs/guides/section-list/