Side project
Lattice
Server-driven React for Laravel — specify a whole UI, and its interactions, from the server side.
Early development
Described in PHP
Pages, forms, tables and actions are plain PHP classes on the server. No hand-wired API, and no UI contract duplicated across two languages.
Rendered as real React
The server serializes a typed tree of nodes over Inertia; a component registry on the client renders it. Real React components, not Blade with extra steps.
A contract AI can read
Because the whole interface is a precise, server-owned spec, AI can add and change UI reliably instead of guessing at markup. That was the need I built it for.
Building Lattice
I'm building it in public — the decisions, the trade-offs, and the things I get wrong along the way. 13 parts so far.
- 01 Introducing Lattice: server-driven React for Laravel, without the coupling
- 02 How Lattice turns PHP into React: the server-driven contract
- 03 Forms in Lattice: fields you choose, not columns you inherit
- 04 Tables in Lattice: columns in PHP, rows from anywhere
- 05 Actions in Lattice: a click runs PHP, the server sends effects back
- 06 Layouts & menus in Lattice: the shell is a schema too
- 07 Fragments in Lattice: reusable pieces of a page, loaded lazily
- 08 Realtime in Lattice: the page decides what to listen for
- 09 Notifications in Lattice: a feature that is just another payload
- 10 Component packages: ship a Lattice component, not a release pipeline
- 11 The contract is generated: how PHP becomes TypeScript in Lattice
- 12 Testing Lattice: assert the payload, not the pixels
- 13 Remote components: borrowing UI from another application
On Packagist as lattice-php/lattice and npm as
@lattice-php/lattice.