React Native support

[hoangman1108]

Summary

Would love to use Liveline in React Native apps. The current implementation is canvas-based (HTML <canvas> + requestAnimationFrame) which doesn't run in RN environments.

Use case

Real-time price charts and live data dashboards are a common need in React Native apps (trading, monitoring, sports data). Liveline's feature set — smooth lerp, candlestick mode, multi-series, momentum indicators — is a strong match for native mobile, where equivalent libraries are sparse.

Technical gap

Web	React Native equivalent
<canvas> + 2D context	@shopify/react-native-skia or react-native-svg
ResizeObserver	View onLayout callback
Mouse events (hover/scrub)	PanResponder / react-native-gesture-handler
CSS cursor, className, style: CSSProperties	StyleSheet / ViewStyle

react-native-skia is the most capable option — it exposes a GPU-accelerated Skia canvas with a React API, supports Path, Paint, gradients, and runs at 60/120fps. The drawing logic in src/draw/ should map fairly directly to Skia primitives.

Possible approaches

1. Separate liveline-native package — keeps the web bundle clean, ships its own peer deps (@shopify/react-native-skia, react-native-gesture-handler). Cleanest separation.
2. Shared core + platform renderers — extract engine/math/lerp logic into a renderer-agnostic core, then ship thin liveline/web and liveline/native entry points. More maintenance surface but avoids duplicating animation logic.
3. react-native-svg renderer — lighter peer dep than Skia, but SVG path updates have higher JS-thread overhead at 60fps; probably fine for non-degen use cases.

Happy to help

I'm willing to contribute a proof-of-concept Skia renderer if there's interest in the direction. Let me know if you'd prefer a separate package or a renderer abstraction in this repo.

[ministic-dev]

Hey @hoangman1108 — this is the exact gap I hit, so I built it: nativeline, a React Native + Expo port of liveline on Skia. It's on npm — npm install nativeline.

Your breakdown is spot on; that's essentially the mapping I ended up with:

liveline (web)	nativeline (RN)
<canvas> + 2D context	@shopify/react-native-skia (PictureRecorder + SkPath/Paint)
ResizeObserver	View onLayout
mouse hover / scrub	react-native-gesture-handler Pan
className / CSSProperties	ViewStyle + a single accent-color theme

Approach: I went with your option 1 — a separate package with its own peer deps (@shopify/react-native-skia, react-native-reanimated, react-native-gesture-handler) rather than a shared-core abstraction. The math (spline, lerp, range, momentum, interpolate) and theme derivation port near-verbatim, but the platform glue — frame loop, present, hover, sizing — diverges enough that a clean separate port was less maintenance than a renderer abstraction spanning web + native. src/draw/ mapped almost directly to Skia: ctx.bezierCurveTo → path.cubicTo, globalCompositeOperation='destination-out' → BlendMode.DstOut, canvas gradients → Skia LinearGradient.

What's in it:

• Every liveline mode: line, candlestick (+ line↔candle morph), multi-series, orderbook stream, degen particles/shake
• One addition over liveline: a static viewport for historical / fixed-range data (liveline is live-only) — same animation engine, it just doesn't chase the wall clock
• 60fps: a JS-thread rAF loop records an SkPicture per frame that Skia composites off-thread; formatValue/formatTime stay ordinary JS (no 'worklet')
• Unit-tested core, dual ESM/CJS + TS types, and a README with a live/static data-integration guide

On the Skia-vs-svg question you raised: I picked Skia because degen (a particle field) and the orderbook stream would thrash the JS thread as per-frame SVG updates. For plain line/candle, react-native-svg would likely be fine — Skia just gave one renderer that covers everything.

It's early (0.0.x) but feature-complete, MIT, and a port of liveline with attribution. I've also been implementing the other open feature requests here as I've hit them (x-/y-axis label toggles, per-part typography, the candlestick badge), so if that direction is useful upstream I'm glad to help — and @benjitaylor, happy to have it linked from the README, or to explore a renderer abstraction if you'd ever want to fold native support into this repo.