ReelKit renders 3 DOM nodes at any time — previous, current, next — whether you have 4 slides or 40,000. Zero dependencies in core. Touch-first with momentum and snap. ~3.7 kB gzipped.

Try it live on StackBlitz — no setup needed.

Quick start

npm install @reelkit/react

import { useState } from 'react';
import { Reel, ReelIndicator } from '@reelkit/react';

const slides = [
  { title: 'Discover', color: '#6366f1' },
  { title: 'Trending', color: '#8b5cf6' },
  { title: 'Following', color: '#ec4899' },
  { title: 'For You', color: '#14b8a6' },
];

export default function App() {
  const [index, setIndex] = useState(0);

  return (
    <Reel
      count={slides.length}
      style={{ width: '100%', height: '100dvh' }}
      direction="vertical"
      enableWheel
      useNavKeys
      afterChange={setIndex}
      itemBuilder={(i, _inRange, size) => (
        <div
          style={{
            width: size[0],
            height: size[1],
            background: slides[i].color,
            display: 'flex',
            alignItems: 'center',
            justifyContent: 'center',
            color: 'white',
            fontSize: '2rem',
          }}
        >
          {slides[i].title}
        </div>
      )}
    >
      <ReelIndicator count={slides.length} active={index} />
    </Reel>
  );
}

Swipe, keyboard arrows, mouse wheel — all work out of the box. The size prop is optional: omit it and ReelKit auto-measures via ResizeObserver.

Programmatic navigation

const apiRef = useRef<ReelApi>(null);

<Reel count={100} apiRef={apiRef} itemBuilder={(i) => <Slide index={i} />} />

<button onClick={() => apiRef.current?.prev()}>Prev</button>
<button onClick={() => apiRef.current?.next()}>Next</button>
<button onClick={() => apiRef.current?.goTo(50)}>Jump to 50</button>

Navigation methods return promises — await apiRef.current!.next() resolves when the animation completes, so you can chain transitions sequentially.

How it works

Virtualization

Only render what's visible. ReelKit computes a visible range from the current index:

Current index: 50, count: 10,000
Visible: [49, 50, 51]  ← 3 DOM nodes, always

With loop mode, it wraps at boundaries:

Current index: 0, loop: true
Visible: [9999, 0, 1]  ← seamless wrap

When you call goTo(5000) from index 0, it doesn't animate through 5,000 slides. It temporarily swaps the adjacent slide with the target, animates a single step, and resolves. One smooth transition — the virtualization handles the rest.

Signals, not React state

ReelKit implements its own reactive system:

• Signal — writable observable value

• ComputedSignal — lazy derived value (zero cost when unobserved)

• batch() — groups multiple updates into a single notification pass

The React <Reel> component subscribes to these signals in effects and uses flushSync() on each animation frame to apply transforms synchronously — bypassing React's default batching. Your React tree doesn't re-render during swipes — transforms update at 60fps without touching component state.

When an animation completes, the index and transform value update in a single batch() call — observers never see an intermediate state. Navigation methods (next(), goTo()) return promises that resolve on completion, so you can chain transitions or await before taking the next action.

Touch-first gestures

The gesture controller detects the dominant axis from the initial touch vector and locks to it. It tracks per-frame delta, cumulative distance, and velocity. A fast swipe (> 1400 px/s) or drag past the threshold triggers a slide change with snap-back animation.

Packages

@reelkit/core is the engine — all slider logic, gesture detection, keyboard/wheel controllers, and the signal system. Zero dependencies. Framework-agnostic. Vue bindings are in progress.

Everything in core is factory functions, not classes — createSliderController, createGestureController, createKeyboardController, createWheelController. Plain closures, no this binding issues, better tree-shaking.

@reelkit/react bridges the core to React. The <Reel> component creates a SliderController once via useState initializer and never recreates it. <ReelIndicator> renders Instagram-style scrollable dot indicators.

Reel Player

A ready-made TikTok/Instagram Reels overlay:

import { ReelPlayerOverlay } from '@reelkit/react-reel-player';
import '@reelkit/react-reel-player/styles.css';

<ReelPlayerOverlay
  isOpen={isOpen}
  onClose={() => setIsOpen(false)}
  content={items}
  initialIndex={0}
/>

Videos autoplay when the slide becomes active, pause when swiped away. A shared video element is reused across slides for iOS sound continuity.

Lightbox

Full-screen image gallery with three transition modes (slide, fade, zoom-in), swipe-to-close, keyboard navigation, and fullscreen API:

import { LightboxOverlay } from '@reelkit/react-lightbox';
import '@reelkit/react-lightbox/styles.css';

<LightboxOverlay
  isOpen={index !== null}
  images={images}
  initialIndex={index ?? 0}
  onClose={() => setIndex(null)}
  transition="fade"
/>

Video support is opt-in and tree-shakeable — image-only usage pays zero extra cost.

Both packages expose render props for controls, navigation, and slide content — replace anything you need.

Links

• Documentation & demos

• GitHub

• npm: @reelkit/core | @reelkit/react | @reelkit/react-reel-player | @reelkit/react-lightbox

• StackBlitz starter

If you're building a vertical feed, a reel player, or a gallery lightbox in React — give ReelKit a try. MIT licensed, open source.

Feedback, suggestions, and bug reports are welcome — open an issue or drop a comment below. And if ReelKit saved you some time, a GitHub star would mean a lot — it's a small thing, but it really helps the project get noticed.

Proto is a universal version manager (think nvm or asdf, but faster and cross-platform) — and now it supports Flutter and Dart through community WASM plugins.

Why proto over FVM or asdf?

FVM is Flutter-specific. It works, but it's one more tool in your stack. If you already manage Node, Go, Rust, or Python versions, that's yet another version manager with its own config format.

asdf supports many tools via plugins, but it's historically been shell-script based, Unix-only, and can be slow.

proto gives you:

• One tool for all your SDKs (Node, Go, Rust, Python, Flutter, Dart, PHP, and more)

• Blazing fast — plugins are compiled to WASM, not shell scripts

• Cross-platform — Linux, macOS, and Windows

• Per-project version pinning via .prototools (one file, all tools)

• Automatic version detection from pubspec.yaml

• Auto-switching — proto picks the right version when you cd into a project

Getting started

Install proto

# macOS / Linux
curl -fsSL https://moonrepo.dev/install/proto.sh | bash

# Windows
irm https://moonrepo.dev/install/proto.ps1 | iex

Add the Flutter plugin

proto plugin add flutter "github://KonstantinKai/proto-flutter-plugin"

One command. No git clones, no compiling from source. Proto downloads a tiny WASM plugin and you're ready to go.

Install Flutter

# Install the latest stable
proto install flutter

# Install a specific version
proto install flutter 3.29

# Install a beta version
proto install flutter beta

Proto downloads the official Flutter SDK archive from Google's servers, extracts it, and makes it available immediately.

Pin a version per project

cd my-flutter-project
proto pin flutter 3.29

This creates (or updates) a .prototools file in your project root:

flutter = "3.29"

Now every teammate gets the exact same Flutter version on proto install. No surprises.

Automatic version detection

The plugin reads your pubspec.yaml out of the box. If you have:

environment:
  flutter: ">=3.22.0 <4.0.0"

Proto will detect and resolve the appropriate Flutter version — no extra configuration needed.

Managing Dart alongside Flutter

Flutter bundles Dart, so in most cases you don't need a separate Dart plugin. But if you have pure Dart projects (CLI tools, server apps, packages), there's a Dart plugin too:

proto plugin add dart "github://KonstantinKai/proto-dart-plugin"
proto install dart 3.7

It reads environment.sdk from pubspec.yaml and supports the same version pinning and auto-detection workflow.

One config file for your entire stack

Here's where proto really shines. A single .prototools file manages everything:

flutter = "3.29"
node = "22"
go = "1.24"

[plugins.tools]
flutter = "github://KonstantinKai/proto-flutter-plugin"

Your whole team gets consistent SDK versions across Flutter, Dart, Node, Go — whatever your project needs. One file, committed to git, no ambiguity.

How it works under the hood

Curious about the internals?

Proto plugins are compiled to WebAssembly (WASM) and run in a sandboxed environment. The Flutter plugin:

1. Fetches the official Flutter release manifest from Google's servers

2. Filters versions by your OS and architecture

3. Downloads and verifies the SDK archive (with SHA-256 checksum)

4. Extracts it to proto's tool directory

5. Exposes both flutter and dart executables

There are no shell scripts, no git clones, no channel management. Just clean, deterministic version management.

Supported platforms

The Flutter plugin covers all officially supported platforms:

Useful commands

# List all available Flutter versions
proto versions flutter

# Check which version is active
proto run flutter -- --version

# Switch between versions
proto install flutter 3.22
proto pin flutter 3.22

# Remove a version
proto uninstall flutter 3.22

Links

The plugins are open source and available on GitHub:

• proto-flutter-plugin

• proto-dart-plugin

If you hit any issues or have feature requests, open an issue on GitHub.

If you also work with PHP, check out proto-php-plugin and proto-composer-plugin — same approach, same workflow.

• "How many requests are we getting?"

• "Who's our heaviest consumer?"

• "Why did error rates spike at 3am?"

So you write a few SQL queries. Maybe stand up a Grafana instance. Add some log parsing. Before you know it, you've spent two days on infrastructure that has nothing to do with your actual product.

The pattern I kept repeating

For every API project, I built some version of the same system:

1. Log request metadata to a database

2. Write queries to aggregate it

3. Build a dashboard to visualize it

4. Set up alerts when things go wrong

The fourth time I did this, I realized it should be a product.

PeekAPI: one middleware call, full API analytics

PeekAPI is a middleware you add to your API server. Here's the full setup:

Node.js (Express):

import { peekapi } from "@peekapi/sdk-node";
app.use(peekapi({ apiKey: "pk_..." }));

Python (FastAPI):

from peekapi import PeekAPIMiddleware

app.add_middleware(PeekAPIMiddleware, api_key="pk_...")

Go (net/http):

handler := peekapi.Middleware(mux, peekapi.Config{
    APIKey: "pk_...",
})
http.ListenAndServe(":8080", handler)

Rust (Actix Web):

App::new()
    .wrap(PeekApi::new("pk_..."))
    .service(/* your routes */)

Ruby (Rails):

# config/application.rb
config.middleware.use PeekAPI::Middleware, api_key: "pk_..."

PHP (Laravel):

// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    $middleware->append(\PeekAPI\Laravel\PeekApiMiddleware::class);
})

Java (Spring Boot):

# application.properties
peekapi.api-key=pk_...

Dart (Shelf)

final client = await PeekApiClient.create(PeekApiOptions(
    apiKey: 'ak_live_...',
  ));

  final handler = const Pipeline()
      .addMiddleware(peekApiMiddleware(client))
      .addHandler(_router);

That's the entire integration for each language. No agents, no config files, no infrastructure to manage.

What you get

Once the middleware is running, your dashboard shows:

Real-time request stream — every API call as it happens, with method, path, status, latency, and consumer identity.

Endpoint analytics — request volume, error rates, and average latency for each route. Spot which endpoints are most used, which are failing, and which are slow.

Consumer tracking — PeekAPI automatically identifies who's calling your API from authorization headers or API keys. Consumers are identified by a SHA-256 hash — raw credentials never leave your server.

Smart alerts — get notified when error rates spike, latency exceeds thresholds, or an endpoint goes silent. Notifications via email, Slack, Discord, Telegram, or generic webhook.

What it captures (and what it doesn't)

Captures: HTTP method, path, status code, response time, request/response size, and a hashed consumer identifier.

Does NOT capture: request/response bodies, query parameters, or raw authentication credentials.

This is a deliberate design choice. PeekAPI answers "who, what, when, how fast" — not "what data was in the request." If you need payload inspection, you need a different tool.

Zero dependencies, by design

Every SDK is zero-dependency. The Node SDK uses only built-in modules (https, crypto, fs, os). Python uses only stdlib. Same for Go, Rust, Ruby, PHP, Java and Dart.

Why? Two reasons:

1. No supply chain risk. Your API middleware shouldn't pull in a tree of transitive dependencies.

2. No conflicts. The SDK will never clash with your existing dependency versions.

Built for reliability

The SDKs are designed to never affect your API's performance or reliability:

• Async buffering — events are collected in memory and flushed in batches (configurable interval and batch size)

• Exponential backoff — if the analytics server is down, the SDK backs off automatically (max 5 consecutive failures)

• Disk persistence — after max flush failures, on non-retryable errors, or on process shutdown, undelivered events are saved to a JSONL file. Recovered automatically every 60 seconds and on startup

• Graceful shutdown — SIGTERM/SIGINT handlers persist buffered events to disk, recovered automatically on restart

If PeekAPI's servers are unreachable, your API keeps running normally. Analytics are best-effort — they should never be a single point of failure.

8 SDKs, 20+ frameworks

Try it

Free tier at peekapi.dev — 500K events/month, no credit card required. SDKs are MIT licensed.

If you have questions about the architecture or feature requests, I'd love to hear them in the comments.