\n\n# fluixi\n\n**A compiler-native reactive framework. The compiler knows what's reactive, so you write ordinary TypeScript.**\n\n[](./LICENSE)\n\n[](https://www.npmjs.com/package/fluixi)\n\n---\n\nMost reactive frameworks ask you to keep a model in your head that the language doesn't share: which reads are tracked, what you may not destructure, where a value has to stay a function. The compiler can't help, because it doesn't know what your values are — so the burden is yours, and the failures are quiet ones.\n\nFluixi's compiler knows. It resolves a reactive primitive by the binding it came from, not by how the name reads, and carries that through JSX and `` html`` `` templates, the DOM it generates, SSR, hydration and routing as one model.\n\n## Features\n\n- 🧠 **The compiler understands reactivity** - resolves primitives by binding, not by name; an alias is recognised, a same-named local function is not\n- ✂️ **Destructure your props** - `function Card({ title })` keeps updating; `...rest` becomes the `splitProps` call you'd have written\n- ✍️ **Two syntaxes, one model** - JSX and `` html`` `` templates compile to the same reactive representation\n- 🚀 **Direct DOM** - a change runs the binding that depends on it; no component re-render, no diff, no virtual tree\n- ⏳ **Load strategies** - `load:visible`, `load:idle`, `load:interaction`, `load:media` split a component into its own chunk\n- 🛣️ **Router, SSR and hydration** - the same reactive graph end to end, not agreed at the edges\n- 📡 **Resources + Suspense** - async data with loading/error state, awaited and seeded during SSR\n- 🏗️ **TypeScript first** - full types, and a language-service plugin for `` html`` `` templates\n\n## Installation\n\n```bash\nnpm install @fluixi/core @fluixi/reactive\n# or\npnpm add @fluixi/core @fluixi/reactive\n# or\nyarn add @fluixi/core @fluixi/reactive\n```\n\n## Quick Start\n\n### Creating a New Project\n\n```bash\nnpm create fluixi my-app\n# or: pnpm create fluixi my-app\n```\n\n### Basic Example\n\n```tsx\nimport { render } from '@fluixi/core';\n\nconst Counter = () => {\n const count = $signal(0);\n\n return (\n
\n
Count: {count()}
\n \n \n \n
\n );\n};\n\nrender(() => , document.getElementById('app')!);\n```\n\n`$signal` needs no import — the compiler resolves it and adds what it needs. `signal(0)` from `@fluixi/reactive/signal` is the same primitive when you'd rather import it, and works in a package that never runs this compiler.\n\n> JSX is compiled by `@fluixi/vite-plugin`. Scaffold a ready-to-run app with `npm create fluixi`.\n\n## Core Concepts\n\n### Signals\n\nSignals are reactive state. Reading one inside an effect or JSX subscribes to it; setting it updates only what depends on it.\n\n```tsx\nconst count = $signal(0);\nconst name = $signal('Alice');\n\n$effect(() => {\n console.log(`${name()} counted to ${count()}`);\n});\n\ncount.set(5); // \"Alice counted to 5\"\nname.set('Bob'); // \"Bob counted to 5\"\n```\n\nCall it to read, `.set()` to write. `$memo` derives, `$store` holds an object you read\nproperties off, `$resource` wraps async data. Each has an importable twin — `signal`,\n`memo`, `effect`, `store`, `resource` from `@fluixi/reactive/signal` — and they are the\nsame primitives, so the two spellings mix freely in one file.\n\n`createSignal` and its `[read, write]` pair are unchanged, and plenty of code is written\nagainst them.\n\n### Components\n\nComponents are plain functions that return JSX. A component runs **once**; props are live\nreads rather than values handed over at call time.\n\n```tsx\nfunction Greeting(props: { name: string }) {\n return
Hello, {props.name}!
;\n}\n```\n\nDestructuring them is fine — the compiler rewrites the bindings into reads, so they keep\nupdating, and `...rest` becomes the `splitProps` call you would have written:\n\n```tsx\nfunction Card({ title, tone = 'calm', ...rest }) {\n return
{title}
;\n}\n```\n\nWhere it can't prove a rewrite is safe — a reassigned binding, a computed key, a default\nit would have to re-run on every read — it leaves your code exactly as written and says\nwhy at build time.\n\n### Control Flow\n\nUse control-flow components instead of ternaries and `.map()` so updates stay fine-grained.\n\n```tsx\nimport { Show, For, Switch, Match } from '@fluixi/core';\n\n// Show — conditional rendering (child callback receives the narrowed value)\n user()} fallback={
Please log in
}>\n {(u) =>
Welcome, {u.name}!
}\n\n\n// For — keyed list rendering (index is an accessor)\n\n {(todo, i) =>
{i() + 1}. {todo.text}
}\n\n\n// Switch / Match — multi-branch\nIdle}>\n status() === 'loading'}>
Loading…
\n status() === 'success'}>
Done!
\n status() === 'error'}>
Error
\n\n```\n\n`Portal`, `Dynamic`, `Index`, and `ErrorBoundary` are also exported.\n\n### Load strategies\n\nA `load:` directive decides *when* a component's module is fetched, and moves it into its\nown chunk:\n\n```tsx\nimport { RevenueChart } from './RevenueChart';\n\n // when it scrolls near the viewport\n // on first pointer, focus or key\n\n\n```\n\nDeferring replaces your static import with a dynamic one, so it applies when the name is\nused only as a tag. Reference it as a value too and the import stays — the build says so\nrather than silently shipping the chunk eagerly.\n\n### `` html`` `` templates\n\nThe same reactive model without configuring JSX — useful in a library, a script, or a\nplain-TypeScript codebase:\n\n```ts\nimport { html } from '@fluixi/core';\n\nfunction Counter() {\n const n = $signal(0);\n return html``;\n}\n```\n\nBoth syntaxes compile to the same representation; `@fluixi/ts-plugin` gives templates\nhover, completion and type-checking in the editor.\n\n### Resources & Suspense\n\n`createResource` fetches async data and tracks loading/error. `` shows a fallback while it's pending (works on the client and during SSR).\n\n```tsx\nimport { Suspense } from '@fluixi/core';\n\nfunction UserCard() {\n const id = $signal(1);\n const user = $resource(id, (id) =>\n fetch(`/api/users/${id}`).then((r) => r.json())\n );\n\n return (\n Loading…}>\n
{user()?.name}
\n \n );\n}\n```\n\n### Context\n\nShare state down the tree without prop drilling.\n\n```tsx\nimport { createContext, useContext } from '@fluixi/core';\n\nconst ThemeContext = createContext<'light' | 'dark'>('light');\n\nfunction App() {\n return (\n \n \n \n );\n}\n\nfunction Toolbar() {\n const theme = useContext(ThemeContext);\n return
…
;\n}\n```\n\n### Router\n\nThe router takes a `routes` config; nested routes render through ``, and `lazy()` code-splits.\n\n```tsx\nimport { render } from '@fluixi/core';\nimport { Router, Outlet, lazy } from '@fluixi/core/router';\n\nconst routes = [\n {\n path: '/',\n component: () => (\n
},\n { path: 'about', component: lazy(() => import('./About')) },\n ],\n },\n];\n\nrender(() => , document.getElementById('app')!);\n```\n\n## Lifecycle Hooks\n\n```tsx\nimport { onMount, onCleanup } from '@fluixi/core';\n\nfunction Clock() {\n const now = $signal(Date.now());\n\n onMount(() => {\n const id = setInterval(() => now.set(Date.now()), 1000);\n onCleanup(() => clearInterval(id));\n });\n\n return ;\n}\n```\n\n## Derived State & Batching\n\n```tsx\nimport { batch } from '@fluixi/core';\n\nconst first = $signal('Ada');\nconst last = $signal('Lovelace');\n\n// Memo — cached, recomputes only when a dependency changes\nconst fullName = $memo(() => `${first()} ${last()}`);\n\n// Batch — coalesce multiple writes into one update\nbatch(() => {\n first.set('Grace');\n last.set('Hopper');\n});\n```\n\n## SSR\n\nServer rendering, hydration, file-based routing and the dev/build tooling live in [`@fluixi/start`](https://www.npmjs.com/package/@fluixi/start). Scaffold an SSR app with `npm create fluixi` and pick the SSR template.\n\n## TypeScript\n\nFluixi is written in TypeScript and ships full types. Configure JSX in your `tsconfig.json`:\n\n```json\n{\n \"compilerOptions\": {\n \"jsx\": \"preserve\",\n \"jsxImportSource\": \"@fluixi/jsx\"\n }\n}\n```\n\n## Ecosystem\n\n| Package | Purpose |\n| --- | --- |\n| `@fluixi/core` | Framework façade — components, control flow, router, render |\n| `@fluixi/reactive` | Signals, memos, effects, store — usable on its own |\n| `@fluixi/dom` | The DOM rendering runtime |\n| `@fluixi/compiler` | JSX and `` html`` `` → IR → direct DOM calls |\n| `@fluixi/vite-plugin` | The compiler as a Vite plugin (rollup, esbuild and webpack adapters too) |\n| `@fluixi/start` | SSR, streaming, SSG, file routing, server functions, deploy adapters |\n| `@fluixi/router` | The routing core |\n| `@fluixi/server` | Server rendering |\n| `@fluixi/head` | Document head and SEO |\n| `@fluixi/ts-plugin` | Editor support for `` html`` `` templates |\n| `@fluixi/template-parser` | The `` html`` `` parser, standalone |\n| `@fluixi/auth` · `@fluixi/session` | Auth bindings and sessions |\n| `@fluixi/testing` · `@fluixi/devtools` | Test helpers, reactive-graph devtools |\n| `@fluixi/cli` · `create-fluixi` | Generators and the app scaffolder |\n\n## License\n\nMIT\n\n## Links\n\n- [npm](https://www.npmjs.com/package/fluixi)\n","readmeFilename":"README.md"}
![\"Fluixi\"](\"https://raw.githubusercontent.com/fluixi/assets/main/logos/128x128.png\")
\n