DEV Community: running squirrel

Parsing hundreds of megabytes of JSON in milliseconds in React Native

running squirrel — Sun, 17 May 2026 13:11:37 +0000

How JSON.parse materializes entire documents in JavaScript, and how react-native-fast-json uses native simdjson + lazy JsonView access to change the cost model in React Native.

react-native-fast-json is an open-source React Native library that wraps simdjson in C++ and exposes a lazy JsonView through Nitro Modules.

Most teams treat JSON parsing as “cheap” because API responses are small. The mental model is:

bytes on wire → JSON.parse → plain objects in JS → app logic

That model breaks when the payload is hundreds of megabytes. The dominant cost is not “JSON syntax is slow” in the abstract, it is allocating and wiring up a full value tree in the JavaScript heap.

What `JSON.parse` actually does in React Native

When you call JSON.parse (or await response.json()), the engine:

Holds the UTF-16/UTF-8 string (or an internal representation of the body)
Walks the entire document
For every object, array, number, boolean, and string, creates JavaScript values with engine overhead (hidden classes, property storage, array backing stores, interned strings, etc.)

For a ~250 MB file, outcomes depend heavily on platform and available RAM:

Symptom	Typical cause
Multi-second freezes	Single-threaded parse + massive allocation on the JS thread
Memory far above file size	JS object graph overhead (often ~2–4× the raw JSON size in bad cases)
OOM / process kill	Peak JS heap + retained tree + rest of the app

On the data_250mb.json fixture in our tests: iOS could complete JSON.parse but only with extreme CPU and memory spikes; Android always crashed before parse finished, making JSON.parse impossible for that payload on Android, while native parseFile worked on both platforms.

Benchmark fixture (source)

Measurements in this repo use the public ~250 MB JSON from antonmedv/json-examples:


Repository	https://github.com/antonmedv/json-examples
File	`data_250mb.json`
Raw URL	`https://github.com/antonmedv/json-examples/raw/refs/heads/master/data_250mb.json`

The example app downloads that URL, caches it on disk, then calls parseFile on the local path.

Measured results (`parseFile`, release builds, physical devices)

Platform	Time to root `JsonView`	CPU / memory (observed)
iOS	~100 ms	Stable, no long CPU peg, no runaway JS heap growth during parse
Android	~500 ms	Stable, same qualitative behavior as iOS, slower wall time

JSON.parse / response.json() on the same fixture:

Platform	`JSON.parse`	`parseFile` + lazy `JsonView`
iOS	Many seconds; extreme CPU and memory spikes (~1.2 GB JS heap ballpark)	~100 ms; CPU and memory stable
Android	Crash, could not complete parse	~500 ms; CPU and memory stable (~400 MB mostly native buffer)

The second row is not “free memory.” The file still occupies roughly file size + simdjson padding in native memory. The win is avoiding a second full copy as a giant JS object graph until you explicitly materialize pieces.

Why “read file as string, then `JSON.parse`” can be worse at peak

A common variant:

const text = await readFile(path, 'utf8');
const data = JSON.parse(text);

At peak you may briefly hold:

The entire file as one JS string
The entire parsed tree
Parser scratch allocations

response.json() can sometimes avoid exposing one giant application-level string, but the end state is still the same: a full tree in JS. For large files, peak heap is the killer.

The technique: how react-native-fast-json does it

react-native-fast-json is what makes the native lazy model practical in React Native. Instead of returning a plain object from JSON.parse, it shifts work across a different boundary:

file bytes → native buffer (simdjson) → JsonView handle → read paths on demand

1. Native buffer (simdjson)

parseFile loads the file into a padded native buffer (simdjson::padded_string::load). Parsing runs in C++ with simdjson (SIMD-accelerated, widely used for large JSON).

The document’s canonical bytes live in native memory, not as nested JS objects.

2. Lazy `JsonView` (Nitro hybrid object)

The root returned to JavaScript is a JsonView, a Nitro hybrid object backed by C++. Calling:

getValue('metadata')
atPath('$.a.b.c')
asString() on a scalar

…does targeted native work and only crosses the bridge with small results (another JsonView handle or a primitive), not the whole document.

3. Materialization is explicit and expensive

When you call:

asObject(), subtree becomes a JS-friendly map/array structure
rawJson(), subtree becomes a JS string

…you have chosen to pay the JS heap cost for that slice. On a 250 MB document, calling these on the root is equivalent to opting back into the problem you avoided.

Architecture

HybridFastJson (cpp/HybridFastJson.cpp):

parseFile(path), load file, construct HybridJsonView, cache by path string
parseString(str), copy string into native view (not path-cached)
release(path), erase cache entry for that path

HybridJsonView, navigation, path helpers, scalar coercion, optional materialization.

Until release(path), a cached parseFile keeps the full native buffer alive even if JS drops its JsonView reference, plan releases when the flow ends.

What you still pay for (honest accounting)

Cost	Still there?
File-sized native memory	Yes, roughly JSON size + padding
Parse CPU	Yes, but native simdjson is much faster than building a JS tree
JS heap for the whole tree	No, unless you `asObject()` / `rawJson()` large parts
Bridge traffic	Per access; keep reads coarse-grained for huge docs
Path cache	`parseFile` retains buffer until `release(path)`

There is no zero memory overhead. The claim that holds up is: near-zero additional JS heap for the full document while you navigate lazily.

Why milliseconds (or low hundreds of ms) are plausible for hundreds of MB

simdjson is designed for throughput on large valid JSON. On the data_250mb.json fixture, parseFile after the file is on disk landed at ~100 ms on iOS and ~500 ms on Android in our release builds, with stable CPU and memory. By contrast, JSON.parse on iOS took many seconds with extreme spikes; on Android it always crashed, so native parse was the only viable option there.

Caveats when you reproduce benchmarks:

Fixture, use the same public file or disclose yours
Cold vs warm storage (first read after download vs re-parse)
Platform, Android was ~5× slower than iOS in our tests; do not assume one number for all devices
Device tier and storage speed
JSON shape (depth, string density) affects constant factors
Debug vs release native builds, ship measurements on release binaries

Comparison table (same fixture, measured + observed)

Dimension	`JSON.parse` (our tests)	Native `JsonView` (`parseFile`)
iOS	Completes after many seconds; extreme CPU/memory spikes	~100 ms; stable CPU/memory
Android	Crash, parse not possible on ~250 MB	~500 ms; stable CPU/memory
Primary memory	Full JS object graph (when it survives)	Native padded buffer (~file size)
UI thread risk	High during parse	Lower; still avoid huge sync work in JS
Best access pattern	Whole-tree mutation	Few paths / scalars / wildcards
Foot-guns	Retaining whole `data`	`asObject()` / `rawJson()` on huge nodes; never calling `release`

Wildcards and paths

atPath('$.a.b.c'), simple dotted segments, no [index] in the path string.
atPathWithWildcard('$.items[*].id'), dynamic segments; returns string[] | null for matched scalar strings.

For very large documents, prefer narrow paths over scanning wildcards across the whole tree unless you have measured the cost.

When native lazy parsing is the wrong tool

Not a common use case, prefer better alternatives

Shipping ~250 MB JSON to a phone is a smell, not a pattern. We benchmark it because it stress-tests the parser and matches real legacy pain, not because every app should do it.

Try these first (usually cheaper than optimizing parse):

Don’t send the file, paginate, stream, or return only fields the UI needs.
Don’t use JSON on the wire, schema-driven binary formats decode faster and smaller.
Don’t keep one blob, SQLite (or similar) with indexes for the queries you actually run.
Don’t parse on the critical path, generate summaries or shards on the server; sync deltas.

Native lazy parsing is a mitigation when you are locked into large JSON. It is not a substitute for a sane data contract.

When this library still does not help enough

Small payloads, JSON.parse is simpler and fast enough.
You need the entire document in JS anyway, you will materialize everything eventually; measure whether native parse + bulk asObject() is still a win.
Heavy in-place mutation of arbitrary subtrees in JS, work on plain objects.
You cannot hold file-sized native RAM (low-RAM devices + multiple huge files), budget and serialize access; even native buffers are ~file size.

Benchmark methodology

import { fastJson } from 'react-native-fast-json';

const root = await fastJson.parseFile('/path/to/large.json');
const version = root?.getValue('metadata')?.getValue('version')?.asString();
fastJson.release('/path/to/large.json');

Fixture, data_250mb.json from antonmedv/json-examples, via https://github.com/antonmedv/json-examples/raw/refs/heads/master/data_250mb.json
RN Version 0.85.0, New Architecture.
Device, physical iOS and Android (document model, OS, RN version, Hermes on/off).
Build, release native binary.
Scenarios
- A: response.json() or JSON.parse after full string in memory
- B: download/cache to disk → parseFile(localPath) → read N fields → release(path)
Metrics, wall time to root JsonView, JS heap snapshot, CPU/memory stability in Instruments / Android Studio.
Our results, parseFile: iOS ~100 ms, Android ~500 ms, CPU/memory stable. JSON.parse: iOS many seconds with extreme spikes; Android always crashed on this fixture.

The example app implements download + parseFile + timing UI, use it as a starting point, not as universal truth.

Summary

Idea	Detail
Problem	`JSON.parse` materializes the whole document in the JS heap.
Technique	Parse in native with simdjson; expose `JsonView`; read lazily.
Speed	`data_250mb.json`: ~100 ms (iOS) / ~500 ms (Android) for `parseFile` in our tests.
CPU / memory	Stable on native parse; `JSON.parse` had extreme spikes on iOS and crashed on Android for this fixture.
Memory model	Avoid blowing up the JS heap; native still holds ~file size.
Discipline	`release(path)`, avoid huge `asObject()` / `rawJson()`, extract scalars to plain JS when done.

Try react-native-fast-json

yarn add react-native-fast-json react-native-nitro-modules

Install pods, rebuild, then use fastJson.parseFile for large files on disk. Peer dependency: react-native-nitro-modules.

Yoga: A Simple Guide to Layout in React Native

running squirrel — Sat, 02 May 2026 10:51:20 +0000

When you build layouts in React Native, you write styles that look a lot like CSS: flexDirection, alignItems, justifyContent, and so on.

But here's the interesting part:

There's no browser.

So… what's actually calculating your layout?

That's where Yoga comes in.

What is Yoga?

Yoga is an open-source, embeddable, high-performance layout engine that implements a subset of CSS Flexbox (and evolving toward broader web standards).

It calculates the size and position of UI elements ("boxes") based on styles like flex properties, margins, padding, and alignment.

Written primarily in C++ (with earlier C implementations), Yoga is not a full UI framework, it does no drawing or rendering.

Your Code (JS)
 ↓
React Native
 ↓
🧠 Yoga (calculates layout)
 ↓
Native Views (iOS / Android)

How Did Yoga Come About?

Early on, Meta/Facebook faced a big challenge: building consistent layouts across platforms.

iOS had its own layout system
Android had a completely different one
Web used CSS and Flexbox

Maintaining separate layout logic for each platform quickly became painful.

So Meta built Yoga, a layout engine that could:

Run on multiple platforms
Deliver consistent layout behavior
Be fast enough for mobile apps

Eventually, they open-sourced it, and it became a core part of React Native.

Today, Yoga lives at yogalayout.dev and continues evolving with contributions from the community and Meta.

Why React Native Needs Yoga

Unlike web apps, React Native doesn't have access to browser engines like Chrome or Safari.

That means:

No built-in Flexbox engine
No CSS layout engine
No DOM

Native platforms use different layout systems:

iOS: Auto Layout (constraints-based) or manual frame setting.
Android: Various ViewGroup layouts (LinearLayout, ConstraintLayout, etc.).

Without a unified system, developers would face platform-specific code, inconsistent behavior, and harder maintenance.

React Native's promise is "learn once, write anywhere," so layout must feel consistent and declarative.

Consistency for the same layout code to produce identical results across iOS, Android, web (in some contexts), and other platforms.

How Yoga Solves Layout

Whenever you write styles in React Native, Yoga steps in behind the scenes.

<View style={{
  flexDirection: 'row',
  justifyContent: 'space-between'
}}>
  <View style={{ width: 50, height: 50 }} />
  <View style={{ width: 50, height: 50 }} />
</View>

Here's what happens:

Style Translation: React Native passes these props to Yoga nodes.
Layout Calculation: Yoga builds a tree of nodes and runs its Flexbox algorithm to compute exact positions and sizes. It handles nesting, wrapping, stretching, shrinking, percentages, and more.
Native Application: Results are applied to native views (UIView on iOS, View on Android) for rendering.

What Yoga actually does:

Builds a layout tree

Parent View
├── Child 1 (50x50)
└── Child 2 (50x50)

Applies Flexbox rules

flexDirection: row → horizontal layout

justifyContent: space-between → push items apart

Calculates positions

Parent Width = 300 (example)

Child 1 → x: 0 Child 2 → x: 250

Then React Native simply renders this using native components.

|[■]--------------------[■]|

All of this happens incredibly fast because Yoga is written in C++ and optimized for performance.

One important detail: Yoga doesn't render anything, it only calculates layout.

Are There Alternatives?

Yoga dominates in React Native, but alternatives and related options exist:

Native-only approaches: Use platform-specific tools like ConstraintLayout (Android) or Auto Layout/SwiftUI (iOS). These require more conditional code and lose the "write once" benefit.

Other Flexbox engines: Older css-layout (Yoga's predecessor) or community ports.

Emerging alternatives: Libraries like Taffy (Rust-based, supports more CSS features like Grid and calc) are discussed in other UI contexts as potential future options, though not integrated into React Native.

Web-based: For React Native Web, it aligns with browser Flexbox/Grid, but Yoga handles the native side.

Custom or third-party: Some apps mix Yoga with manual native layout for performance-critical sections, or use libraries like Reanimated for animated layout changes on top of Yoga.

Conclusion

Yoga is one of those tools you rarely think about, but rely on constantly.

It quietly powers every layout in React Native, translating simple style rules into precise, performant UI across platforms.

Next time you align a few views with justifyContent, take a moment to appreciate the sophisticated engine working behind the scenes, doing Yoga, so you don't have to.

For deeper dives, check the official docs at yogalayout.dev or experiment in a React Native project. Happy coding!

Offline React Native Apps: How to Cache Files That Must Open Without Network

running squirrel — Sat, 25 Apr 2026 09:41:36 +0000

If you search for “offline React Native,” you will find a lot of guidance about images, lists, and optimistic UI. That is useful, but it often misses the assets that actually stop work in the field: PDFs, JSON manifests, small binaries, audio clips, and other HTTP-hosted files your app must open right now, even when connectivity is unreliable.

One of the best libraries for that specific “cache downloads to disk, open them later” capability is react-native-nitro-cache with it's simplistic api anyone can use easily.

This post is about that second category: file caching for offline-capable React Native apps.

Why “offline React Native” advice often skips the hard part

Most offline guidance optimizes what users see immediately: scrolling, perceived speed, optimistic updates. That matters, but field workflows also depend on what users can open from storage when the network disappears.

Operational apps tend to fail for file reasons, not layout reasons:

a PDF checklist did not download before the technician walked into a basement
a rules manifest is stale after a midnight policy change
a small binary or audio instruction is missing when the user is already offline

What you want in those situations is not a prettier loading state. You want a predictable HTTP file cache with explicit freshness and cleanup tools.

That is the shape of problem a file cache is meant to solve: downloads you can treat as local files, with TTL, forced refresh, and simple ways to inspect and clean up what is on disk—so your app can open operational assets offline, not only render UI faster.

The offline-first file workflow

Think in layers:

Prefetch the critical path while the user still has good connectivity (login, sync screen, “prepare for today” action).
Serve from disk during the session using stable local file paths.
Revalidate on a schedule using TTLs that match how often each asset class changes.
Force refresh when the server says “this version is invalid” (feature flags, emergency policy updates).
Observe and prune using cache stats/entries so support and QA can reason about what is on-device.

This maps cleanly to the react-native-nitro-cache primitives:

getOrFetch(url, options?) — return a valid cached file or download it
get(url) — read-through without downloading
has(url) — fast synchronous membership check against the in-memory index
getBuffer(url) — read bytes into an ArrayBuffer for small in-memory consumers
remove(url) / clear() — targeted invalidation vs nuclear reset
getStats() / getEntries() — operational visibility

Example: different TTLs for different file classes

In real apps, “freshness” is not one number. Treat manifests, templates, and media differently.

import { rnNitroCache } from 'react-native-nitro-cache';

export async function cacheManifest(url: string) {
  // Changes frequently: short TTL 10mins
  return rnNitroCache.getOrFetch(url, { ttl: ttl: 60 * 10 });
}

export async function cachePdfTemplate(url: string) {
  // Changes rarely: longer TTL 7days
  return rnNitroCache.getOrFetch(url, { ttl: 60 * 60 * 24 * 7 });
}

When an entry is returned, you typically care about:

url: absolute on-disk path you can hand to viewers/players
contentType: useful for routing and validation
size: useful for UI and telemetry
expiresAt: 0 if the entry has no TTL; otherwise the expiry instant in milliseconds since epoch

Example: parse cached JSON without inventing a parallel storage system

For small JSON blobs, getBuffer can be convenient if your consumer wants bytes in JS.

import { rnNitroCache } from 'react-native-nitro-cache';

export async function readCachedJson(url: string) {
  const buf = await rnNitroCache.getBuffer(url);
  if (!buf) return null;

  const text = new TextDecoder().decode(buf);
  return JSON.parse(text) as unknown;
}

Invalidation that matches real product events

Offline support is not only “store more.” It is also “remove the right things at the right time.”

Common triggers:

User logs out → clear() if your policy requires wiping cached HTTP assets from the device
Tenant/workspace switch → clear() or selective remove(url) for tenant-scoped URLs
Server publishes a new bundle version → getOrFetch(url, { forceRefresh: true }) for the entry points that must update immediately

Observability: treat the cache as part of your release story

If you have ever debugged “it works on Wi‑Fi,” you know the missing ingredient is visibility.

import { rnNitroCache } from 'react-native-nitro-cache';

const stats = await rnNitroCache.getStats();
console.log('cache entries:', stats.totalEntries, 'bytes:', stats.totalSize);

const entries = await rnNitroCache.getEntries();
console.log(entries.map(e => ({ path: e.url, type: e.contentType, bytes: e.size })));

This is valuable for:

QA scripts (“did we prefetch the manifest?”)
internal diagnostics screens
coarse “disk budget” warnings before downloads

Installation and platform reality (so your readers do not get stuck)

What I would emphasize in a Medium conclusion

Offline React Native is getting more attention because teams are shipping more serious mobile workflows. But it is not just "more caching", it is the right kind of caching:

operational files you can open from disk under poor connectivity
explicit freshness (TTL) and forced refresh paths
disk-first retrieval for large assets
targeted invalidation and introspection APIs

If your roadmap includes offline inspections, offline forms, offline training content, or any “must open on-site” PDFs and manifests, a general-purpose file cache belongs in your architecture review alongside your sync and persistence strategy.

Repo link

To learn more about the library checkout it's repository on GitHub

Top 4 React Native Image Caching Libraries in 2026

running squirrel — Wed, 22 Apr 2026 20:09:14 +0000

An opinionated guide to image caching in React Native, from battle-tested classics to the blazing-fast newcomer built for the New Architecture.

Caching images in React Native has always been painful. The default <Image> component is slow, flickers on reloads, and offers almost zero control.
For years developers have relied on a handful of libraries but most of them were built before the New Architecture, before Turbo Modules or Nitro Modules, and before apps started demanding smooth video caching and zero-copy performance.

In 2026, the game has changed. Here are the Top 4 image caching libraries I recommend today, ranked by real-world usage, performance, and developer experience.
Make sure you check out the last one!

1 react-native-fast-image - The Veteran King (Still Dominant)

The library is no longer actively maintained but still being used by many. I strongly recommend the fork - @d11/react-native-fast-image

Pros

Battle-tested for years
Excellent image prioritization and cache control
Huge community

Cons

New Architecture support is patchy (community fork required)
Higher bridge overhead compared to modern Nitro solutions

Still the go-to for many production apps, but it's starting to show its age.

2 expo-image - The Expo Ecosystem Favorite

Pros

Beautiful API and great DX
Excellent New Architecture support
Built-in memory + disk caching with cachePolicy

Cons

Tied to the Expo ecosystem (less ideal for bare React Native)
Limited programmatic control (no easy remove(url) or cache inspection)

Perfect if you're already in Expo.

3 react-native-turbo-image - The Modern Native Contender

Built on Nuke (iOS) and Coil (Android), this library delivers excellent native performance and is gaining traction fast.

Pros

Very fast native image loading
Good New Architecture compatibility

Cons

Smaller community than fast-image

A strong option if you want native speed without Nitro.

4 react-native-nitro-cache - The Newcomer That's Stealing the Show

This is the one I'm most excited about in 2026.
Built from the ground up with Nitro Modules + C++, react-native-nitro-cache is a unified asset cache for images, videos, and any binary files. Has a very simple api interface, very easy to use.

Why it stands out:

Unified caching (images + videos + arbitrary files)
Zero-copy ArrayBuffer support for raw binary data
Blazing-fast in-memory retrieval with safe atomic persistence
Built-in TTL, programmatic remove(url) and cache inspection
Full New Architecture support out of the box

It feels like someone finally built the cache library we've all been waiting for since the New Architecture landed.

Conclusion

react-native-fast-image and expo-image are still solid choices, they are battle tested and the community love them.

My 2026 recommendation:

Expo-heavy project → stick with expo-image
Need maximum battle-tested stability → react-native-fast-image (with the community fork)
Want the future of unified, high-performance caching → try react-native-nitro-cache.

The library is brand new, actively developed, and already solving real pain points that the older solutions never addressed.
Have you tried it yet? Drop a comment below with your current caching setup. I'd love to hear what's working (or not working) for you in 2026.

Why Mobile Apps Deserve Their Own CMS

running squirrel — Wed, 20 Aug 2025 04:16:50 +0000

Every website has a CMS. WordPress, Shopify, Contentful — platforms that make content management simple and instant.
But mobile apps? Still waiting days for app store approvals just to fix a typo.

Why do apps lack the same content management flexibility as websites?
Because app stores were built for static releases, not agile content updates.

Product managers, marketers, and even compliance teams often need quick updates:

Change a banner for a flash sale
Update legal disclaimers
Fix onboarding text
Roll out seasonal content

None of these should require a rebuild.

ResyncBase is filling this gap:

Built for React Native apps
Instant content updates
Live previews on iOS & Android
Version history & rollback

The Benefit Beyond Speed?

Empower non-developers to make changes
Reduce developer distraction
Keep users happy with bug-free, up-to-date content

Just as websites couldn’t scale without CMS platforms, mobile apps can’t stay competitive with app store delays.
It’s time for a CMS for apps.

Join the ResyncBase waitlist now at www.resyncbase.com

How to Add a Vertical Timeline To your React Native App

running squirrel — Fri, 07 Mar 2025 07:24:58 +0000

To add a component to show the progress/timeline of a process with different statuses, you can use the library react-native-vertical-status-progress. Works with Expo and React Native.

The component from the library is designed to visually represent the progress of a multi-step process. Each step is represented by a status indicator that can be customized to show whether the step is completed or pending. This component is ideal for workflows, onboarding processes, or any scenario where you need to display progress through a series of steps. It is compatible with both Expo and React Native projects, making it versatile and easy to integrate into your existing applications.

Features

Accordion Support: Each status can be expanded or collapsed to show more details. This is useful for providing additional information or actions related to each step.
Customizable Content: You can render any component within the accordion, including call-to-action (CTA) buttons, forms, or any other React Native components.

Installation

npm install react-native-vertical-status-progress

Usage

import { VerticalStatusProgress } from 'react-native-vertical-status-progress';

const statuses = [
  {
    title: 'Sign Up Complete',
    subtitle: 'You have successfully signed up.',
    status: 'registered',
  },
  {
    title: 'Set up your account',
    subtitle: 'Add your account details to get started.',
    renderContent: (
      <TouchableOpacity>
        <Text>vbireuvgbireubgireuf</Text>
      </TouchableOpacity>
    ),
    status: 'setting_up',
  },
  {
    title: 'Account Verification',
    subtitle: 'We are verifying your account.',
    renderContent: (
      <View>
        <Text>
          We will contact you shortly if we need any additional information.
          Please contact us if you have any questions. Check your email for
          updates.
        </Text>
        <TouchableOpacity
          style={{
            backgroundColor: colors.ACCENT_BLUE,
            padding: 10,
            borderRadius: 5,
            width: 150,
            alignItems: 'center',
            marginTop: 10,
          }}
        >
          <Text style={{ color: '#fff' }}>Resend Email</Text>
        </TouchableOpacity>
      </View>
    ),
    status: 'verifying',
  },
  {
    title: 'Account Verified',
    subtitle: 'Your account has been verified.',
    status: 'waiting',
  },
  {
    title: 'All Set!',
    subtitle:
      "You're all set up and ready to go. Start using your account now.",
    renderContent: (
      <View>
        <Text>
          Lorem ipsum dolor sit, amet consectetur adipisicing elit. A ullam
          assumenda obcaecati? Minima libero vitae ducimus, omnis, excepturi
          saepe, doloribus corrupti hic deleniti id iure? Qui consequuntur at
          magnam consequatur!
        </Text>
      </View>
    ),
    status: 'ready',
  },
];

const App = () => {
    return (
        <VerticalStatusProgress statuses={statuses} />
    );
};

export default App;

Customization

You can customize the appearance of the react-native-vertical-status-progress component by passing in custom styles and render functions. Here are some examples:

Custom Ball Component

const renderCustomBall = (label, idx, isPrev, isFuture) => (
  <View style={{ backgroundColor: isPrev ? 'blue' : 'grey', width: 16, height: 16, alignItems: 'center', justifyContent: 'center', borderRadius: 4 }}>
    <Text style={{ color: 'white', fontSize: 10 }}>{idx}</Text>
  </View>
);

<VerticalStatusProgress
  statuses={statuses}
  renderBall={renderCustomBall}
/>

Custom Stick Component

const renderCustomStick = (label, idx, isPrev, isFuture) => (
  <View style={{ flex: 1, width: 5, backgroundColor: isPrev ? 'blue' : 'grey' }} />
);

<VerticalStatusProgress
  statuses={statuses}
  renderStick={renderCustomStick}
/>

Custom Chevron Component

const renderCustomChevron = (open, index) => (
  <Text>{open ? '-' : '+'}</Text>
);

<VerticalStatusProgress
  statuses={statuses}
  renderChevron={renderCustomChevron}
/>

With react-native-vertical-status-progress it becomes very easy to add any timeline for status progress on your app.

To see more details about customisation, props and example, visit the library page on npm or github.

How to Generate Types from Your Api Responses in Realtime in Typescript

running squirrel — Wed, 04 Dec 2024 11:16:35 +0000

I have always felt a bit annoyed whenever I’m working on a project and I have to add types to an api response.

The process usually goes like this:

write a function to fetch data
call the function on a component or page
either log the response or inspect the network tab to view the response
copy this response, create a new file and paste the response
start editing the response to create a new type or interface
import the new type to the function file and set it’s return type.

This had been going on for a while and then I thought to find a way to automate it.

This led to my discovery of a few libraries that can generate types. Unfortunately they were not convenient to work with because they were not generating the types effortlessly and in realtime. They required a lot of manual process as well. I wanted something I could just plug in and be done with and continue with my normal development flow.

So I decided to build a library that will automate this process for me.

realtime-api-types

The aim of this library is to take the pain away from trying to add types from your api responses.

Find out more on: npm or github

With this library, as you get responses from an api, it generates the type for you and saves it to your project, in real time.

It also imports the new type and sets it as the return type of your api call. How awesome is that!

Just import the helper function and start the server. Thats all. You can then go on with your normal development flow.

This setup is meant only for development and not for production! You should not deploy this into your production pipeline.

This library was inspired by an old project I stumbled upon, called MakeTypes.

Installation

To get started, simply run:

npm install realtime-api-types --save-dev

Configuration

There are some configs you need to set. Go to your package.json and add the following:

"realtime-api-types": {
    "objectType": "type",
    "typePath": "src/types",
    "apiPath": "src/apis",
    "fetchType": "axios"
  }

The shape of the config is:

export type Config = {
  objectType: 'interface' | 'type'; // whether you want to generate interfaces or types 
  fetchType: 'fetch' | 'axios'; // how you fetch data, fetch or axios
  typePath: string; // the path to where you want to save generated types
  apiPath: string; // the path to where your api methods exist
};

Start Service

To start the type generator service, run: npx realtime-api-types --init.

Code Sample & Usage

Wrap your apis in an object and wrap the object with typedApiWrapper.

You should make your api methods pure, simply return the api call.

You can use property assignments or methods or both.

Please note that when you're done developing, remove typedApiWrapper from this file completely.

// Example 

// src/apis/exercise.ts api file

import {typedApiWrapper} from "realtime-api-types"
import axios from 'axios'

export const ExerciseApi = typedApiWrapper({
  // with fetch, property assignment style
  getExercises: () => fetch("https://example-api.com").then((res) => res.json()),
    // with axios, method style
   getExerciseById(id: string) {
    return axios.get(`https://example-api.com/${id}`);
  },
  // api post method
  postExercise(data: any) {
    return axios.post(`https://example-api.com`, data)
  }
});


// src/App.tsx file

useEffect(() => {
   ExerciseApi.getExercises()
}, [])

With this setup, whenever an api is called at any point in time, the service will intercept and try to generate type from the response.

When type generation is successful, the example file above would be automatically updated to something like this:

// updated exercise.ts api file

import {typedApiWrapper} from "realtime-api-types"
import axios from 'axios'
import { GetExercises } from "../types/getExercises";
import { GetExerciseById } from "../types/getExerciseById";
import { PostExercise } from "../types/postExercise";

export const ExerciseApi = typedApiWrapper({
  // with fetch, property assignment style
  getExercises: (): Promise<GetExercises> => fetch("https://example-api.com").then((res) => res.json()),
    // with axios, method style
   getExerciseById(id: string): Promise<{ data: GetExerciseById }> {
    return axios.get(`https://example-api.com/${id}`);
  },
  // api post method
  postExercise(data: any): Promise<{ data: PostExercise }> {
    return axios.post(`https://example-api.com`, data)
  }
});

Note the difference in structure of return type from fetch and axios.
axios returns a data: Type. Do not mix axios and fetch in your project, else you'll get wrong types.

Naming Convention

Note the naming convention in the example above.

The name of the type file is the same as the name of the api method called.
The name of the type itself is the same as the name of the api method but in pascal case.

React Native or Expo

For this to work with React native or Expo, make sure you follow their guide on how to enable api calls to localhost

Limitations

Cannot generate enums from response.
Cannot extend type from different type files. If the response from a call contains object that is similar to another type in another file, it cannot extend it. A new type will be generated in the new file.
Cannot give custom file names or type names. File name and type name is solely based on the name of the api method.
Once a type has been generated for an api call, the type will not update with new api calls. You need to delete the previous generated type file to generate a new one.

This library only serves to help you get started quickly and reduce time spent adding types to api calls. You might need to make some updates to the generated types sometimes. It does not solve all your type problems.

DEV Community: running squirrel

Parsing hundreds of megabytes of JSON in milliseconds in React Native

What JSON.parse actually does in React Native

Benchmark fixture (source)

Measured results (parseFile, release builds, physical devices)

Why “read file as string, then JSON.parse” can be worse at peak

The technique: how react-native-fast-json does it

1. Native buffer (simdjson)

2. Lazy JsonView (Nitro hybrid object)

3. Materialization is explicit and expensive

Architecture

What you still pay for (honest accounting)

Why milliseconds (or low hundreds of ms) are plausible for hundreds of MB

Comparison table (same fixture, measured + observed)

Wildcards and paths

When native lazy parsing is the wrong tool

Not a common use case, prefer better alternatives

When this library still does not help enough

Benchmark methodology

Summary

Try react-native-fast-json

Yoga: A Simple Guide to Layout in React Native

What is Yoga?

How Did Yoga Come About?

Why React Native Needs Yoga

How Yoga Solves Layout

Are There Alternatives?

Conclusion

Offline React Native Apps: How to Cache Files That Must Open Without Network

Why “offline React Native” advice often skips the hard part

The offline-first file workflow

Example: different TTLs for different file classes

Example: parse cached JSON without inventing a parallel storage system

Invalidation that matches real product events

Observability: treat the cache as part of your release story

Installation and platform reality (so your readers do not get stuck)

What I would emphasize in a Medium conclusion

Repo link

Top 4 React Native Image Caching Libraries in 2026

Conclusion

Why Mobile Apps Deserve Their Own CMS

How to Add a Vertical Timeline To your React Native App

How to Generate Types from Your Api Responses in Realtime in Typescript

realtime-api-types

Installation

Configuration

Start Service

Code Sample & Usage

Naming Convention

React Native or Expo

Limitations

What `JSON.parse` actually does in React Native

Measured results (`parseFile`, release builds, physical devices)

Why “read file as string, then `JSON.parse`” can be worse at peak

2. Lazy `JsonView` (Nitro hybrid object)