Lesson 6 — The Table component: vanish for configuration
Named slots use vanish to collect content. The Table component uses vanish for something subtly different — collecting configuration.
The column-based API
We want to describe a table by its columns rather than its HTML structure:
|
|
The block does not produce HTML — it calls column to register definitions which are then used to render both the headers and the rows in separate passes.
How t populates @columns — the key insight
t is not a proxy or configuration object. t is the Table instance itself. Phlex automatically upgrades yield to yield(self), so the block receives the component. Calling t.column(...) is simply calling the column instance method on that component:
|
|
Each call pushes directly onto @columns on that same instance. By the time vanish returns, @columns is fully populated — not by magic, but by direct method calls on a live Ruby object.
The block is not configuration data being parsed — it is Ruby code executing methods on a live component instance. This is true of the Card slots too: card.header { ... } calls the header method on the Card instance. t.column(...) calls the column method on the Table instance. The pattern is identical — the block argument is always the component itself.
Why column returns nil
Unlike named slots where content is captured once for later output, column definitions are used twice — once for <thead> headers and once per row in <tbody>. Returning nil ensures nothing reaches the buffer during the vanish phase.
The full Table component
Pico styles <table> cleanly with no classes needed:
|
|
Adding Table to the demo
|
|
Exercise
Extend show_tables to render a second table listing your Phlex::UI components, with “Component” and “Status” columns. Use a Badge inside the status column.
Solution
|
|
The completed component library and demo page can be downloaded here: phlex-sandbox.