Roadmap

The component list is taken from Element Plus as a checklist of what an admin panel needs. Every component is implemented in-house; the library in brackets is what the behaviour leans on.

Legend: ✅ done · 🚧 in progress · ⬜ planned

Wave 1 — basics

Complete: every component below has a demo, tests and a page it is documented on — the four typographic ones share Typography, since a page each would be four pages of the same paragraph.

Component	Status
Button	✅
ButtonGroup	✅
Icon	✅
Input	✅
Textarea	✅
InputNumber	✅
Select (Reka Combobox)	✅
Checkbox, CheckboxGroup	✅
Radio, RadioGroup	✅
Switch	✅
Form, FormItem	✅
Card	✅
Tag (as Badge)	✅
TagsInput	✅
Badge (count: Indicator)	✅
Alert	✅
Divider	✅
Layout (Container, Header, Aside, Main, Footer)	✅
Grid (Row, Col)	✅
Space	✅
Tabs (Reka)	✅
Menu / Sidebar	✅
Breadcrumb	✅
Link	✅
Text, Heading, Prose	✅
Scrollbar	✅

Wave 2 — data and overlays

Complete. Two notes on where this list stopped matching the one it was copied from:

• Message and Notification are one component. The difference between them is a title and a corner, so both are Toast — one queue, one WxToaster, a placement.
• Upload is ours, rather than a wrapper around Uppy or FilePond. Those bring their own UI and their own theme, which is the one thing this library does not do; and since a component here never calls an API, there was no request logic to inherit either.

Component	Status
Table (Laravel Paginated)	✅
Pagination	✅
Dialog (Reka)	✅
Drawer (Reka)	✅
Dropdown (Reka)	✅
Tooltip	✅
Popover (Reka)	✅
Popconfirm	✅
Message (one line, Toast)	✅
Notification / Toast (Reka)	✅
Loading	✅
Skeleton	✅
Empty	✅
Result	✅
Progress	✅
Descriptions	✅
Avatar	✅
Image	✅
Upload (ours)	✅
DatePicker, TimePicker, DateTimePicker (@vuepic/vue-datepicker)	✅
DateRangePicker	✅
Steps	✅
Collapse (as Accordion)	✅
Segmented	✅
Statistic, Countdown	✅
Backtop	✅
Affix	✅

Wave 3 — as needed

ColorPicker ✅, Slider ✅, Rate ✅, Autocomplete ✅, Cascader ✅, Timeline ✅ and Transfer ✅ are done.

Tree ✅ — ours rather than he-tree-vue, because a drop is three zones on a row and a <mark> in a label, and neither survives being themed through somebody else's CSS. It brings the part most trees skip: Alt and the arrow keys move a node the same four ways a drag does, which is also the only way to rearrange one on a touch screen.

Table in tree mode ✅ — the same nesting inside WxTable: indentation and a disclosure in the first column, the rest of the row still columns. Not a second component — both run on useTreeNodes, so a drop means the same thing in each. It is the screen a pages or categories module wants: the tree and the data in one pane, instead of a sidebar tree beside a list of the same records.

It gives up sorting and pagination, because both destroy a structure, and has no keyboard equivalent for the drag — a row wants a Move action and a picker for that.

TreeSelect ✅ — the same tree as a form field, single or with checkboxes. It is the "parent category" field, so it reads a key and reports a key: parent_id is what the form sends, and the node comes along with the event for whatever the screen needs to show.

Still open: Carousel, Anchor, Splitter, Watermark, Marquee.

Some day, maybe — wanted, but nothing is waiting on them:

• Mention — the @name picker inside a text field.

Dropped, so that the list stays a list of things somebody is going to write:

• Calendar — a month of boxes to pick a date out of is what DatePicker already does, and does with a keyboard. What a calendar would add is a month of events, which is a scheduler and a different component with a different name.
• Tour — the step-by-step walk over a screen. An admin panel earns its explanations in the screen itself; when one truly needs a tour, that is a sign to go back to the screen.

CMS-specific (not in Element Plus)

RichText (Tiptap) ✅ — see RichText. It edits one language at a time under localized, its toolbar takes its words as props, and a picture it takes from a library carries that library's key into the document rather than an address that will not survive the next deployment. Its </> button opens the HTML source and says what the editor would drop before it drops it. On a screen it is wx-rich-text, from module-admin — see Screens. CodeEditor (CodeMirror 6) ✅ — the same field for code: JSON with a linter, HTML, CSS, PHP, YAML and the rest, see CodeEditor. The screens mechanism needs its patches written somewhere better than a textarea. IconPicker ✅ — the icon set, picked from rather than typed into, see IconPicker. A name the set does not have draws nothing and says nothing, so anywhere an editor names an icon — a block type, a menu entry — the name has to come out of the set rather than out of a keyboard. EntityCard ✅ — one record as a row, see EntityCard. Actions ✅ — the icon buttons at the end of a row, see Actions. confirm asks in a popover by the button before a row goes — the panel asks so for every row of a list, and keeps the dialog for a whole record. ActionBar ✅ — the same screen's buttons along the bottom of it, see Layout. A panel's screens scroll natively, so the head goes with the scroll and takes the save button with it; the bar is where the button waits. Kanban ✅ — a board of columns cards are dragged between, see Kanban. ListDetail ✅ — filters, records, the open one, and the rule for when there is room for all three: see ListDetail. An inbox and an orders screen are the same furniture.

SelectionArea ✅ — the rubber band over a grid or a list, see SelectionArea. A media library is unusable without it.

FileCard ✅ — one file in that library: a preview or a glyph, the name, and the few things that can be done to it, see FileCard. It does none of them — renaming reports a name, deleting reports a wish — so the same card sits in a library, in a picker and in a form field. The icon set gained a file-<extension> family to go with it, and an extension nobody has drawn gets the plain page with its own name written underneath.

ImageEditor ✅ — what the card's edit action asks for: a crop with the eight grips everybody knows, aspect ratios, quarter turns, mirrorings, an output size, and a blob at the end of it. See ImageEditor. It is deliberately not folded into the card, which is a tile and should stay one — the card asks, openImageEditor() answers.

It uploads nothing, the way nothing here does: the answer is a blob, its measurements and the crop it was cut from, so the same editor crops an avatar before a form is submitted and re-cuts a file that is already in a library. Everything on screen is geometry, and the picture is drawn exactly once — at the end, under one transform — because a chain of canvases softens a photograph at every link.

Lightbox ✅ — a gallery over the whole screen: arrows, keys, a swipe, a counter, a strip of thumbnails, zoom and pan, and videos (YouTube, MP4, WebM) behind their posters. See Lightbox. It opens three ways — from a WxImageGroup of previewed pictures, from one cover with a preview-list, and from code with openLightbox() — for the product galleries, the media library and the audit's pictures. Its dimming is a token of its own, --wx-bg-lightbox, dark in both themes.

ThemeSwitch ✅ — light, dark, or whatever the machine says: see ThemeSwitch. Three states rather than two, because a toggle cannot say I have not decided, which is the state most people are in — and following the machine is what makes a panel go dark at sunset along with everything else on the desk. It reports the choice and nothing else: applying it is applyTheme(), and remembering it belongs to whoever knows where that person's settings live.

SortableList ✅ — a list whose order is the point, dragged by a grip or moved with the arrow keys: see SortableList.

Repeater ✅ — the same list once every row is a form: a set of fields, repeated, in an order that is part of the answer. See Repeater. It is SortableList underneath, with the two things a form needs on top — rows that fold to a name taken from their own fields, and a key of its own per row, so writing a field, removing the row above or dragging one elsewhere never rebuilds the form under the caret. In a described screen it is wx-repeater, the one type whose model is nested.

Gantt ⬜ — the other way to look at the same work: a task per row, a bar across a timeline. Decided, not started. It will be ours rather than a wrapper around frappe-gantt or vis-timeline, because a Gantt is a header of dates and bars placed along it — a CSS grid, in other words — and a wrapper would mean styling somebody else's SVG through their theme instead of our tokens, which is the one thing this library does not do. The first pass reads: a sticky column of task names, a scale of days, weeks or months, bars with progress, a marker on today, and hovering or clicking a bar reported as an event. Dragging the dates and the arrows between dependent tasks come after that, once the first pass has been lived with.

MediaLibrary / Gallery ✅ — the library itself, and the fields that reach into it: wx-media for one picture, wx-gallery for a grid of them in an order somebody dragged them into, wx-file and wx-files for documents. See Media fields.

LinkPicker ✅ — WxLinkPicker and the wx-link field in the panel: pick a page, an article or any other entity that has an address, or type your own. It came with the menus.

BlockPicker ✅ — choosing a block type to insert, in the block constructor.

Markdown ⬜ — still open.

Not components

Two things here are reached from code rather than from a template, and are easy to miss in a list of components:

• Toast — toast.success('Saved') from anywhere, including an HTTP interceptor or a store, with one WxToaster on the page to show them.
• Dialogs from code — confirm(), and openModal / createModal for mounting any component and awaiting its answer. A picker reached as await productBrowser().

Beyond components

1. @webx-ui/adapter-laravel ⬜ — paginator, 422 validation errors, sort/filter query parameters. Not started.
2. The panel ✅ — sections on top of core, each a pair of packages (npm @webx-ui/module-* and composer webx-ui/module-*), and each also a set of MCP tools, so an agent reaches the panel through the same doors an editor does:
   • the core of a site: the file manager, administrators, settings, SEO, the block constructor with its layout regions — the header and the footer made of blocks, pages, menus, the inbox and database backups;
   • content: the blog, services, FAQ, reviews, team, banners, tariffs, recipes, events, press and vacancies;
   • the libraries underneath, which live without the panel too: routing (the address registry), nested-set, localization and mcp.
3. A new site in one command ✅ — composer create-project webx-ui/site, see A new site.
4. Block types edited in the panel ✅ — fields, a Blade template, CSS and a script, kept in the database rather than generated into files; see Blocks.
5. Many sites from one install ⬜ — one panel, many domains, a design per domain. Designed, not started.
6. A catalogue for shops ✅ — a core plus satellites: properties, stock, brands, labels, landing pages, a gallery with video, CSV/XLSX exchange and Manticore search; see Catalogue. Wave B (linked products, groups, configurable products, sizes, more exchange formats) is not started.