Repository navigation
Replies: 1 comment
|
Quick update: we've changed the release plan slightly. Support for building custom fields, schema components, and widgets with JavaScript, React, Vue, or Svelte will ship in the next minor release. This works independently of Inertia, so we've decided not to hold it back while the pages work is still unresolved. We're still waiting for initial feedback from the Inertia team on the proposed upstream changes. Until we have that, we can't confirm whether JavaScript pages will ship or what shape the integration will take. Separately, the JavaScript versions of Filament's own UI components—things like avatars, breadcrumbs, and inputs—will remain on hold. These are mainly useful when building whole pages in JavaScript, so we want to establish the direction for JavaScript pages before committing to those APIs and releasing them. TLDR: custom JavaScript fields, schema components, and widgets are coming in the next minor; JavaScript pages and the accompanying UI components are still pending a decision on the Inertia integration. |
Uh oh!
There was an error while loading. Please reload this page.
Hi everyone 👋
I wanted to give you an update on adding JavaScript support to Filament. There's a lot of draft work spread across different PRs, so here it is in one place.
Where things stand
I've made a lot of progress on letting you build parts of Filament with JavaScript. This includes plain JavaScript, React, Vue, and Svelte. None of it has been merged or released yet.
I'm waiting to hear back from the Inertia team about a core PR before I do anything else on this. I want to ship JavaScript support as one coherent release, not merge parts of it now and come back to the rest later.
The Inertia core PR
The key dependency is this PR to Inertia:
It would let an app keep control of its own shell and navigation while individual pages use Inertia. For Filament, that means Livewire would still handle the panel, navigation, browser history, and page transitions. Inside a page, you could use React, Vue, or Svelte with Inertia features like props, forms, validation, partial reloads, and deferred data.
It also lets Filament cleanly remove one Inertia page and mount another without reloading the browser. That's needed so requests, callbacks, polling, and head tags from an old page can't leak into the next one.
The change is optional and isn't specific to Filament. Any app could use it to move individual pages to Inertia gradually. I've asked the Inertia maintainers whether this approach and API fit in Inertia core. I've also mentioned an alternative design I tried locally, in case they'd prefer that direction.
Without an upstream change, I'd have to either maintain an Inertia fork or ship a deliberately limited integration. I don't want to do either, so I'm waiting for their feedback first.
Inertia pages in Filament
This PR adds Inertia-backed Filament pages. The current work covers:
The API of this PR depends on what happens with Inertia core, so I'm holding it until that direction is clear.
Custom JavaScript components
I've also been working on letting you write custom Filament components in JavaScript without needing Inertia. Filament and Livewire still own the form state, validation, and server responses. Your JavaScript only handles the rendering and client-side behaviour.
This work is a stack of PRs, each building on the one before:
Together, they add:
These PRs don't technically depend on the Inertia PR. I'm still holding them so the JavaScript APIs, docs, generators, and package setup can all be reviewed and released together.
JavaScript versions of Filament UI components
To make custom JavaScript UI feel native to Filament, I've also started on React, Vue, and Svelte versions of some of Filament's UI components. The goal is to reuse Filament's existing markup and theme classes, so they look and behave like the Blade components.
I've also prepared, but not opened PRs for, Breadcrumbs, Fieldset, Loading Indicator, Checkbox, Radio, Icon, Input Wrapper, Input, Select, Empty State, Callout, Actions, Loading Section, and Badge.
Larger interactive components like buttons, dropdowns, modals, tabs, sections, and pagination need more design work first. That's especially true where focus management, keyboard behaviour, positioning, loading states, or data contracts are involved.
Why one big push?
These pieces depend on shared ideas: how JavaScript code mounts inside Filament, how PHP passes data to it, how generators set up projects, how TypeScript types work, and where Livewire's responsibilities end and JavaScript's begin.
If I merge parts of it early, there's a real risk of changing public APIs or setup steps after people have started using them. I'd rather wait, make sure the foundations are right, and release something complete and well documented.
What happens next
I'll wait for feedback on the Inertia PR before doing anything else. Depending on that feedback, I'll update the Inertia integration, refresh the Filament PRs against current Filament, do a final review of the APIs and docs, and then plan the release.
I don't have a release date yet. I'll update this discussion when there's real movement.
Thanks for your patience and all the excitement around this. Questions and use cases are welcome below. Real-world examples of what you'd build are especially helpful.
All reactions