weft 0.1.0 → 0.2.0

data/docs/examples/edit-row.md

@@ -16,7 +16,8 @@ PEOPLE = {
 class PersonRow < Weft::Component
   builder_method :person_row
 
-  attribute :person_id
+  param :person_id
+  receives :person_id
 
   def tag_name
     "tr"
@@ -24,11 +25,11 @@ class PersonRow < Weft::Component
 
   def build(attributes = {})
     super
-    person = PEOPLE.fetch(attrs.person_id)
+    person = PEOPLE.fetch(params.person_id)
     td person[:name]
     td person[:email]
     td do
-      button "Edit", loads: PersonRowEditor, with: { person_id: attrs.person_id },
+      button "Edit", loads: PersonRowEditor, with: { person_id: params.person_id },
                      swap: :replace, target: self
     end
   end
@@ -37,12 +38,12 @@ end
 class PersonRowEditor < Weft::Component
   builder_method :person_row_editor
 
-  attribute :person_id
-  attribute :name
-  attribute :email
+  param :person_id
+  param :name
+  param :email
 
-  transfers :save, to: PersonRow do |attrs|
-    PEOPLE.fetch(attrs.person_id).merge!(name: attrs.name, email: attrs.email)
+  transfers :save, to: PersonRow do |params|
+    PEOPLE.fetch(params.person_id).merge!(name: params.name, email: params.email)
     nil
   end
 
@@ -52,16 +53,16 @@ class PersonRowEditor < Weft::Component
 
   def build(attributes = {})
     super
-    person = PEOPLE.fetch(attrs.person_id)
-    save_form = "save-person-#{attrs.person_id}"
+    person = PEOPLE.fetch(params.person_id)
+    save_form = "save-person-#{params.person_id}"
     td { input type: "text", name: "name", value: person[:name], form: save_form }
     td { input type: "text", name: "email", value: person[:email], form: save_form }
     td do
       form(action: :save, id: save_form) do
-        input type: "hidden", name: "person_id", value: attrs.person_id
+        input type: "hidden", name: "person_id", value: params.person_id
         input type: "submit", value: "Save"
         button "Cancel", type: "button",
-               loads: PersonRow, with: { person_id: attrs.person_id },
+               loads: PersonRow, with: { person_id: params.person_id },
                swap: :replace, target: self
       end
     end
@@ -87,7 +88,9 @@ end
 
 ## How it works
 
-**It's click-to-edit, once per row.** Both components render as `<tr>` (the `tag_name` override), with the identifying attribute declared first so each carries a usable DOM id. Entering edit mode changes nothing on the server, so Edit is a [`loads:`](../dsl.md#loads) — a GET that fetches the editor row and replaces the display row (`swap: :replace, target: self`). Saving is a [`transfers`](../dsl.md#transfers--actions-that-render-something-else): the write runs, then the *display* row renders in the editor's place. Cancel is the Edit button's mirror image, pointed back at `PersonRow`. As in click-to-edit, defining the display component first lets `transfers :save, to: PersonRow` resolve in the editor's class body, while `loads: PersonRowEditor` waits until render.
+**It's click-to-edit, once per row.** Both components render as `<tr>` (the `tag_name` override), with the identifying param declared first so each carries a usable DOM id. Entering edit mode changes nothing on the server, so Edit is a [`loads:`](../dsl.md#loads) — a GET that fetches the editor row and replaces the display row (`swap: :replace, target: self`). Saving is a [`transfers`](../dsl.md#transfers--actions-that-render-something-else): the write runs, then the *display* row renders in the editor's place. Cancel is the Edit button's mirror image, pointed back at `PersonRow`. As in click-to-edit, defining the display component first lets `transfers :save, to: PersonRow` resolve in the editor's class body, while `loads: PersonRowEditor` waits until render.
+
+**Where `person_id` comes from differs by component.** The table hands each display row its `person_id` (`person_row(person_id: id)`) — a [`receives`](../dsl.md#receives--caller-hand-offs) hand-off, since per-row values can't inherit down the render tree — and `PersonRow` declares it as a `param` too, so the same id serializes into the row's own route and DOM id. The editor is different: it's always *fetched* by URL (Edit and Cancel both `loads:` it with `with: { person_id: … }`), so it reads `person_id` straight from the wire — `param` alone, no hand-off.
 
 **A form can't wrap table cells — so the cells point at the form.** HTML won't allow a `<form>` to span `<td>`s inside a row, which is the structural puzzle of this pattern. htmx's original solves it with `hx-include="closest tr"`; here plain HTML does the same job: the form lives in the last cell, and the name and email inputs associate with it from their own cells via the standard [`form` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#form). Form-associated elements are part of the form's submission set, so both htmx's payload *and* the no-JavaScript fallback submission include all three fields — nothing about the association needs scripting.
 
@@ -137,7 +140,7 @@ Submitting `POST /_components/person_row_editor/save` with the edited fields ret
 </tr>
 ```
 
-Only the attributes `PersonRow` itself declares travel into that render — the editor's `name` and `email` were consumed by the save and play no part in the row's element.
+Only the params `PersonRow` itself declares travel into that render — the editor's `name` and `email` were consumed by the save and play no part in the row's element.
 
 ## Related
 

data/docs/examples/file-upload.md

@@ -12,10 +12,10 @@ UPLOADED_REPORTS = []
 class ReportUploader < Weft::Component
   builder_method :report_uploader
 
-  attribute :document
+  param :document
 
-  performs :upload do |attrs|
-    file = attrs.document
+  performs :upload do |params|
+    file = params.document
     if file.is_a?(Hash) && file[:tempfile]
       UPLOADED_REPORTS << { name: file[:filename], size: file[:tempfile].size }
     end
@@ -44,9 +44,9 @@ end
 
 **One HTML attribute makes it multipart.** `enctype: "multipart/form-data"` isn't Weft vocabulary — it passes through to the `<form>` untouched, and it does double duty there: htmx honors a form's native enctype when it builds the request, and the no-JS fallback submit needs the same attribute anyway. Leave it off and the request still fires, but as an ordinary urlencoded POST whose file field has collapsed to the string `"[object File]"` — nothing a server can use. (htmx also has an `hx-encoding` attribute; it's only needed to force multipart from something other than a form.)
 
-**The file arrives through a declared attribute.** The `document` attribute receives whatever the server's multipart parsing produces — under Sinatra, a hash carrying `:filename`, `:type`, and a `:tempfile` ready to read. The callable checks for that shape before storing, which quietly covers the other case too: submitting with no file chosen sends `document=` (an empty string), the `is_a?(Hash)` guard skips it, and the re-render is a no-op.
+**The file arrives through a declared param.** The `document` param receives whatever the server's multipart parsing produces — under Sinatra, a hash carrying `:filename`, `:type`, and a `:tempfile` ready to read. The callable checks for that shape before storing, which quietly covers the other case too: submitting with no file chosen sends `document=` (an empty string), the `is_a?(Hash)` guard skips it, and the re-render is a no-op.
 
-**Returning `{ document: nil }` is load-bearing.** A callable's returned hash merges into the attrs for the re-render ([the callable contract](../dsl.md#the-callable-contract)) — and this one uses that to *clear* the file param rather than add anything. Weft derives a component's DOM id from its first declared attribute, and a tempfile-toting multipart hash in that slot would smear itself across the wrapper's id and every piece of htmx wiring derived from it. Cleared, the component comes back as plain `#report-uploader`: same id, same wiring, fresh empty file input.
+**Returning `{ document: nil }` is load-bearing.** A callable's returned hash merges into the params for the re-render ([the callable contract](../dsl.md#the-callable-contract)) — and this one uses that to *clear* the file param rather than add anything. Weft derives a component's DOM id from its first declared param, and a tempfile-toting multipart hash in that slot would smear itself across the wrapper's id and every piece of htmx wiring derived from it. Cleared, the component comes back as plain `#report-uploader`: same id, same wiring, fresh empty file input.
 
 ## On the wire
 

data/docs/examples/infinite-scroll.md

@@ -14,7 +14,7 @@ class ContactRows < Weft::Component
 
   PER_PAGE = 10
 
-  attribute :page, default: 1
+  param :page, default: 1, type: :integer
 
   def tag_name
     "tbody"
@@ -22,10 +22,10 @@ class ContactRows < Weft::Component
 
   def build(attributes = {})
     super
-    rows = DIRECTORY[(attrs.page - 1) * PER_PAGE, PER_PAGE]
+    rows = DIRECTORY[(params.page - 1) * PER_PAGE, PER_PAGE]
     rows.each_with_index do |contact, index|
       if index == rows.size - 1 && more_pages?
-        tr(infinite_scroll: ContactRows, with: { page: attrs.page + 1 }, target: "closest tbody") do
+        tr(infinite_scroll: ContactRows, with: { page: params.page + 1 }, target: "closest tbody") do
           td contact[:name]; td contact[:email]
         end
       else
@@ -37,7 +37,7 @@ class ContactRows < Weft::Component
   private
 
   def more_pages?
-    attrs.page * PER_PAGE < DIRECTORY.size
+    params.page * PER_PAGE < DIRECTORY.size
   end
 end
 
@@ -49,7 +49,7 @@ class ContactDirectory < Weft::Component
     h3 "Contact directory"
     table do
       thead { tr { th "Name"; th "Email" } }
-      contact_rows(page: 1)
+      contact_rows
     end
   end
 end
@@ -59,13 +59,13 @@ end
 
 ## How it works
 
-**The last row is the sentinel.** [`infinite_scroll:`](../dsl.md#shorthands) presets trigger `:visible` and swap `:after`; the call site adds the target. Placed on the final `tr` of a batch, it means: when this row scrolls into view, fetch the next batch and insert it after the closest `tbody`. The trigger expands to htmx's `revealed`, which fires once per element — each sentinel row does its job exactly one time.
+**The last row is the sentinel.** [`infinite_scroll:`](../dsl.md#presets) presets trigger `:visible` and swap `:after`; the call site adds the target. Placed on the final `tr` of a batch, it means: when this row scrolls into view, fetch the next batch and insert it after the closest `tbody`. The trigger expands to htmx's `revealed`, which fires once per element — each sentinel row does its job exactly one time.
 
 **`target: "closest tbody"` keeps the table valid.** The fetched component is a whole `<tbody>` (that's the `tag_name` override), and swapping it `afterend` of the *row* would nest table sections illegally. Aiming the swap at the closest `tbody` instead makes each batch a sibling section — the shape HTML already sanctions for row grouping. This is why the preset leaves the target to you: only the call site knows what the insertion point should be.
 
 **The chain stops itself.** The sentinel wiring is only rendered while `more_pages?` holds. The final batch is just rows — nothing left to trigger, nothing fetched past the end of the data.
 
-**`page` travels as wire state.** `attribute :page, default: 1` makes each batch independently addressable (`/_components/contact_rows?page=3`) and coerces the URL string to an Integer, since the default is one. The `ContactDirectory` wrapper, by contrast, declares nothing — it's plain composition and renders only as part of a page.
+**`page` travels as wire state.** `param :page, default: 1, type: :integer` makes each batch independently addressable (`/_components/contact_rows?page=3`), coercing the URL string to an Integer on the way in. The `ContactDirectory` wrapper, by contrast, declares nothing — it's plain composition and renders only as part of a page.
 
 ## On the wire
 
@@ -95,4 +95,4 @@ Scrolling that row into view issues `GET /_components/contact_rows?page=2`, whos
 
 - [Click to Load](click-to-load.md) — the same batch-by-batch growth, but on the reader's explicit request.
 - [Lazy Loading](lazy-loading.md) — the `:visible` trigger deferring a single section instead of paginating many.
-- The [shorthands table](../dsl.md#shorthands) and [targets](../dsl.md#targets) in the DSL reference.
+- The [presets table](../dsl.md#presets) and [targets](../dsl.md#targets) in the DSL reference.

data/docs/examples/inline-expansion.md

@@ -2,7 +2,7 @@
 
 A compact row with a disclosure control. Clicking it fetches the row's detail from the server and inserts it directly beneath — the list stays a list, and depth appears exactly where the reader asked for it.
 
-There's no counterpart for this in the htmx examples catalog; `inline_expand:` is Weft-native sugar over the same [`loads:`](../dsl.md#loads) machinery as the other shorthands. It's the pattern for master-detail tables where the detail is cheap to want and expensive to preload for every row.
+There's no counterpart for this in the htmx examples catalog; `inline_expand:` is Weft-native sugar over the same [`loads:`](../dsl.md#loads) machinery as the other presets. It's the pattern for master-detail tables where the detail is cheap to want and expensive to preload for every row.
 
 ## The components
 
@@ -16,7 +16,7 @@ ORDERS = {
 class OrderItemsRow < Weft::Component
   builder_method :order_items_row
 
-  attribute :order_id
+  param :order_id
 
   def tag_name
     "tr"
@@ -24,7 +24,7 @@ class OrderItemsRow < Weft::Component
 
   def build(attributes = {})
     super
-    order = ORDERS.fetch(attrs.order_id)
+    order = ORDERS.fetch(params.order_id)
     td colspan: 4 do
       strong "Items: "
       text_node order[:items].join(", ")
@@ -44,7 +44,7 @@ class OrdersTable < Weft::Component
           tr do
             td do
               button "▸", inline_expand: OrderItemsRow, with: { order_id: id },
-                          target: "closest tr", trigger: "click once"
+                          target: "closest tr"
             end
             td id
             td order[:customer]
@@ -61,9 +61,9 @@ end
 
 ## How it works
 
-**The detail arrives *after* the trigger's row.** [`inline_expand:`](../dsl.md#shorthands) presets trigger `:click` and swap `:after` (htmx's `afterend`); the call site supplies the target. `target: "closest tr"` walks up from the button to its row, so the fetched component is inserted as the next sibling row — which is why `OrderItemsRow` overrides `tag_name` to render as a `<tr>`. A `colspan` spanning the table's columns lets the detail breathe across the full width.
+**The detail arrives *after* the trigger's row.** [`inline_expand:`](../dsl.md#presets) presets trigger `:click_once` and swap `:after` (htmx's `afterend`); the call site supplies the target. `target: "closest tr"` walks up from the button to its row, so the fetched component is inserted as the next sibling row — which is why `OrderItemsRow` overrides `tag_name` to render as a `<tr>`. A `colspan` spanning the table's columns lets the detail breathe across the full width.
 
-**`trigger: "click once"` guards against double insertion.** The preset's `:click` fires on *every* click — left alone, a second click would insert a second copy of the detail row. The `trigger:` kwarg overrides the preset with htmx's raw trigger grammar, and `once` caps the interaction at a single firing. (There's currently no semantic symbol for "click once" the way `:hover` bakes in `mouseenter once`, so the raw string is the honest spelling.)
+**One click, one insertion.** The preset's `:click_once` bakes in htmx's `once` modifier, capping the interaction at a single firing — because the detail lands *after* the button's row rather than replacing anything, a repeat click would otherwise insert a second copy. If your detail row removes itself on close and the button should work again, override with `trigger: :click`.
 
 **Expansion, not a toggle.** Once expanded, the row stays expanded — this preset opens, it doesn't close. When you need collapse, give the detail component the behavior: a [`dismisses`](../dsl.md#dismisses--remove-from-the-dom) verb and a "Hide" button inside `OrderItemsRow` remove it from the DOM server-consistently. (The one-shot button does remain spent after that; a fully re-armable open/close control is a two-state component pair, as in [Click to Edit](click-to-edit.md).)
 
@@ -93,6 +93,6 @@ Clicking issues `GET /_components/order_items_row?order_id=1001`, and the respon
 
 ## Related
 
-- [Tooltip](tooltip.md) — the other Weft-native shorthand: hover-driven detail loaded into a bubble instead of a row.
+- [Tooltip](tooltip.md) — the other Weft-native preset: hover-driven detail loaded into a bubble instead of a row.
 - [Click to Edit](click-to-edit.md) — two-state rows that swap in place rather than expanding.
-- The [shorthands table](../dsl.md#shorthands) and [trigger values](../dsl.md#trigger-values) in the DSL reference.
+- The [presets table](../dsl.md#presets) and [trigger values](../dsl.md#trigger-values) in the DSL reference.

data/docs/examples/inline-validation.md

@@ -12,11 +12,11 @@ TAKEN_EMAILS = ["taken@example.com"].freeze
 class SignupEmailField < Weft::Component
   builder_method :signup_email_field
 
-  attribute :email
-  attribute :error_message
+  param :email
+  param :error_message
 
-  performs :validate, target: "#signup-email-field" do |attrs|
-    email = attrs.email.to_s.strip
+  performs :validate, target: "#signup-email-field" do |params|
+    email = params.email.to_s.strip
     unless email.match?(URI::MailTo::EMAIL_REGEXP)
       raise Weft::Unprocessable, "That doesn't look like an email address."
     end
@@ -25,21 +25,21 @@ class SignupEmailField < Weft::Component
     nil
   end
 
-  recovers from: Weft::Unprocessable do |_attrs, error|
+  recovers from: Weft::Unprocessable do |_params, error|
     { error_message: error.message }
   end
 
   def build(attributes = {})
     super
     set_attribute :id, "signup-email-field"
-    form(action: :validate, trigger: "change") do
+    form(action: :validate, trigger: :change) do
       label "Email Address ", for: "email"
-      input type: "email", name: "email", id: "email", value: attrs.email
+      input type: "email", name: "email", id: "email", value: params.email
     end
-    if attrs.error_message
-      para attrs.error_message, style: "color:#b91c1c"
-    elsif attrs.email
-      para "#{attrs.email} looks good.", style: "color:#15803d"
+    if params.error_message
+      para params.error_message, style: "color:#b91c1c"
+    elsif params.email
+      para "#{params.email} looks good.", style: "color:#15803d"
     end
   end
 end
@@ -49,15 +49,15 @@ end
 
 ## How it works
 
-**The field is a component, and the form belongs to the field.** `form(action: :validate, trigger: "change")` wires the POST like any action form, but `trigger:` swaps the form's natural submit trigger for `change` events — which bubble up from the input, so the request fires the moment the user leaves the field. A form's fields are its payload: the typed email reaches the callable as `attrs.email`, exactly as it would on a full submit.
+**The field is a component, and the form belongs to the field.** `form(action: :validate, trigger: :change)` wires the POST like any action form, but `trigger:` swaps the form's natural submit trigger for `change` events — which bubble up from the input, so the request fires the moment the user leaves the field. A form's fields are its payload: the typed email reaches the callable as `params.email`, exactly as it would on a full submit.
 
-**Put the action on the form, not the input.** It's tempting to skip the form and hang `action: :validate, trigger: "change"` on the input itself. Don't: on a non-form element, `action:` carries the component's declared attributes along as `hx-vals`, and htmx gives those precedence over the triggering element's own value — so the request goes out with the *component's* stale idea of the email, never the fresh keystrokes. A one-field form is the honest wiring: what's in the field is what gets sent.
+**Put the action on the form, not the input.** It's tempting to skip the form and hang `action: :validate, trigger: :change` on the input itself. Don't: on a non-form element, `action:` carries the component's declared params along as `hx-vals`, and htmx gives those precedence over the triggering element's own value — so the request goes out with the *component's* stale idea of the email, never the fresh keystrokes. A one-field form is the honest wiring: what's in the field is what gets sent.
 
-**Validation failures are still renders.** Bad input raises `Weft::Unprocessable`; the `recovers from:` block catches it and returns `{ error_message: error.message }`, which merges into the attrs for the re-render. The response goes out as a semantic `422 Unprocessable Content` whose body is this same component wearing its error paragraph. Valid input sails through to the `nil` return and renders the success line at a plain `200`. (The machinery is [the `recovers` chain](../error-handling.md#the-recovers-chain); the merge is [the callable contract](../dsl.md#the-callable-contract).)
+**Validation failures are still renders.** Bad input raises `Weft::Unprocessable`; the `recovers from:` block catches it and returns `{ error_message: error.message }`, which merges into the params for the re-render. The response goes out as a semantic `422 Unprocessable Content` whose body is this same component wearing its error paragraph. Valid input sails through to the `nil` return and renders the success line at a plain `200`. (The machinery is [the `recovers` chain](../error-handling.md#the-recovers-chain); the merge is [the callable contract](../dsl.md#the-callable-contract).)
 
-**A value that changes can't anchor the DOM id.** Weft derives a component's DOM id from its first declared attribute — here that's the email itself, which would give the wrapper a different id on every render. So the component pins its own slot: `set_attribute :id, "signup-email-field"` fixes the wrapper's id, and `performs :validate, target: "#signup-email-field"` points the swap at that same anchor. (The same stable-slot idiom as [Bulk Update](bulk-update.md), for the same reason.)
+**A value that changes can't anchor the DOM id.** Weft derives a component's DOM id from its first declared param — here that's the email itself, which would give the wrapper a different id on every render. So the component pins its own slot: `set_attribute :id, "signup-email-field"` fixes the wrapper's id, and `performs :validate, target: "#signup-email-field"` points the swap at that same anchor. (The same stable-slot idiom as [Bulk Update](bulk-update.md), for the same reason.)
 
-**The field echoes what the user typed.** The swap replaces the whole component, input included, so `value: attrs.email` writes the submitted text back into the fresh input — without it, every complaint would also blank the field.
+**The field echoes what the user typed.** The swap replaces the whole component, input included, so `value: params.email` writes the submitted text back into the fresh input — without it, every complaint would also blank the field.
 
 ## On the wire
 
@@ -97,5 +97,5 @@ And the part that makes it *inline*: a browser's `change` event on the input bub
 ## Related
 
 - [Bulk Update](bulk-update.md) — the stable-slot idiom this page borrows, and reporting back through the returned hash.
-- [Click to Edit](click-to-edit.md) — the basics of pairing form fields with declared attributes.
+- [Click to Edit](click-to-edit.md) — the basics of pairing form fields with declared params.
 - [`performs`](../dsl.md#performs--user-initiated-actions), [`recovers`](../dsl.md#recovers--declare-error-behavior), and [`trigger:`](../dsl.md#trigger) in the DSL reference; [Error handling](../error-handling.md#the-recovers-chain) for the full recovery story.

data/docs/examples/lazy-loading.md

@@ -14,14 +14,14 @@ QUARTERLY_REVENUE = {
 class RevenueTable < Weft::Component
   builder_method :revenue_table
 
-  attribute :year, default: 2025
+  param :year, default: 2025, type: :integer
 
   def build(attributes = {})
     super
     table do
       thead { tr { th "Quarter"; th "Revenue" } }
       tbody do
-        QUARTERLY_REVENUE.fetch(attrs.year).each do |quarter, amount|
+        QUARTERLY_REVENUE.fetch(params.year).each do |quarter, amount|
           tr { td quarter; td amount }
         end
       end
@@ -32,15 +32,15 @@ end
 class AnnualReport < Weft::Component
   builder_method :annual_report
 
-  attribute :year, default: 2025
+  param :year, default: 2025, type: :integer
 
   def build(attributes = {})
     super
-    h2 "#{attrs.year} annual report"
+    h2 "#{params.year} annual report"
     para "Commentary, highlights, and everything else the reader scrolls through " \
          "before the numbers. The revenue table below is expensive to produce, " \
          "so it loads only when it comes into view."
-    div lazy: RevenueTable, with: { year: attrs.year } do
+    div lazy: RevenueTable, with: { year: params.year } do
       para "Loading revenue…"
     end
   end
@@ -51,13 +51,13 @@ end
 
 ## How it works
 
-**The placeholder is an ordinary element with one extra kwarg.** [`lazy:`](../dsl.md#shorthands) is a preset over the [`loads:`](../dsl.md#loads) machinery: trigger `:visible`, swap `:fill`, target `:self`. When the div scrolls into view, fetch `RevenueTable` and swap it into the div's interior. Because trigger, swap, *and* target all have an obvious right answer here, the call site needs nothing beyond the component class and its attrs.
+**The placeholder is an ordinary element with one extra kwarg.** [`lazy:`](../dsl.md#presets) is a preset over the [`loads:`](../dsl.md#loads) machinery: trigger `:visible`, swap `:fill`, target `:self`. When the div scrolls into view, fetch `RevenueTable` and swap it into the div's interior. Because trigger, swap, *and* target all have an obvious right answer here, the call site needs nothing beyond the component class and its params.
 
 **The div's children are the loading state.** Because the swap is `:fill` (`innerHTML`), the placeholder element itself survives; only its contents — the "Loading revenue…" paragraph — are replaced by the fetched component. Whatever you put in the block is what users see until the content arrives.
 
 **`:visible` means once.** The semantic trigger expands to htmx's `revealed`, which fires a single time when the element first enters the viewport. The wrapper keeps its wiring after the swap, but no re-fetch loop follows.
 
-**`with:` passes the wire state along.** The placeholder hands its own `year` down to the loaded component (`with: { year: attrs.year }`), and the value travels in the URL — visible below. If you omit `with:`, the enclosing component's attrs are passed by default.
+**`with:` passes the wire state along.** The placeholder hands its own `year` down to the loaded component (`with: { year: params.year }`), and the value travels in the URL — visible below. If you omit `with:`, the enclosing component's params are passed by default.
 
 ## On the wire
 
@@ -93,4 +93,4 @@ Scrolling it into view issues `GET /_components/revenue_table?year=2025`, and th
 
 - [Infinite Scroll](infinite-scroll.md) — the same `:visible` trigger, used repeatedly to grow a table page by page.
 - [Click to Load](click-to-load.md) — deferred loading where the user asks for more, instead of scrolling to it.
-- The [shorthands table](../dsl.md#shorthands) and the [trigger values](../dsl.md#trigger-values) in the DSL reference.
+- The [presets table](../dsl.md#presets) and the [trigger values](../dsl.md#trigger-values) in the DSL reference.

data/docs/examples/live-ticker.md

@@ -88,4 +88,4 @@ Each multi-line rendering becomes consecutive `data:` lines in one event, per th
 
 - [Progress Bar](progress-bar.md) — the polling counterpart: the client re-fetches on a timer instead of holding a connection.
 - [`pushes`](../dsl.md#pushes--the-server-sends-updates) in the DSL reference; [`stream_suffix`](../configuration.md#stream_suffix) and [`include_sse_ext`](../configuration.md#include_sse_ext) in configuration.
-- A component with attributes streams too — its wire state rides the `sse-connect` URL as query parameters, so each subscriber gets frames for *its* instance.
+- A component with params streams too — its wire state rides the `sse-connect` URL as query parameters, so each subscriber gets frames for *its* instance.

data/docs/examples/modal-dialog.md

@@ -42,9 +42,9 @@ end
 
 ## How it works
 
-**Opening is a load into a stable slot.** [`modal:`](../dsl.md#shorthands) presets trigger `:click` and swap `:fill`; the call site supplies the target. Clicking the button fetches `TourDialog` and fills the empty `#modal-slot` div with it. The slot is permanent page structure — it outlives any dialog placed in it, so the modal can be opened again after closing.
+**Opening is a load into a stable slot.** [`modal:`](../dsl.md#presets) presets trigger `:click` and swap `:fill`; the call site supplies the target. Clicking the button fetches `TourDialog` and fills the empty `#modal-slot` div with it. The slot is permanent page structure — it outlives any dialog placed in it, so the modal can be opened again after closing.
 
-**Closing is a dismissal.** `dismisses :close` declares a DELETE action whose swap removes the component from the page entirely — and for a modal, removed from the DOM *is* closed. The dialog vanishes, the slot div stays, and the page underneath was never touched. Give the dismissal a block (`dismisses :close do |attrs| ... end`) if closing should also do something server-side, like recording that the tour offer was seen.
+**Closing is a dismissal.** `dismisses :close` declares a DELETE action whose swap removes the component from the page entirely — and for a modal, removed from the DOM *is* closed. The dialog vanishes, the slot div stays, and the page underneath was never touched. Give the dismissal a block (`dismisses :close do |params| ... end`) if closing should also do something server-side, like recording that the tour offer was seen.
 
 **The underlay closes too — same action, different element.** [`action:`](../dsl.md#action) isn't just for buttons: on the underlay div it expands to exactly the same wiring as the Close button, and htmx's default trigger for a div is a click. Because the underlay and the content panel are *siblings* — the underlay covers the viewport, the panel floats above it — a click on the panel never bubbles to the underlay, so only clicks on the dimmed backdrop dismiss.
 
@@ -85,4 +85,4 @@ Clicking either one issues `DELETE /_components/tour_dialog/close`. The response
 
 - [Browser Dialogs](browser-dialogs.md) — when a native `confirm()` box is dialog enough.
 - [Keyboard Shortcuts](keyboard-shortcuts.md) — the [`trigger:`](../dsl.md#trigger) grammar that could add Escape-to-close to this dialog.
-- [`dismisses`](../dsl.md#dismisses--remove-from-the-dom) and the [shorthands table](../dsl.md#shorthands) in the DSL reference.
+- [`dismisses`](../dsl.md#dismisses--remove-from-the-dom) and the [presets table](../dsl.md#presets) in the DSL reference.

data/docs/examples/progress-bar.md

@@ -42,7 +42,7 @@ class JobMonitor < Weft::Component
 
   refreshes every: 1
 
-  performs :start do |_attrs|
+  performs :start do |_params|
     FakeJob.start!
     nil
   end

data/docs/examples/reset-user-input.md

@@ -14,12 +14,12 @@ GUEST_COMMENTS = [
 class CommentSection < Weft::Component
   builder_method :comment_section
 
-  attribute :author
-  attribute :body
+  param :author
+  param :body
 
-  performs :post do |attrs|
-    author = attrs.author.to_s.strip
-    body = attrs.body.to_s.strip
+  performs :post do |params|
+    author = params.author.to_s.strip
+    body = params.body.to_s.strip
     GUEST_COMMENTS << { author: author, body: body } unless author.empty? || body.empty?
     { author: nil, body: nil }
   end
@@ -52,7 +52,7 @@ end
 
 **The response replaces the form, typed text and all.** `build` renders the list from the store and the inputs with no `value:` at all — so every render of this component has empty fields. The action's `outerHTML` swap replaces the old elements wholesale: the inputs holding the typed text leave the DOM, and fresh, empty ones arrive in the same response that shows the new comment in the list. What htmx solves with an after-request reset handler, the render model here dissolves.
 
-**Clearing the params in the return keeps the identity stable.** The callable ends with `{ author: nil, body: nil }` — a returned hash merges into the attrs for the re-render ([the callable contract](../dsl.md#the-callable-contract)), and Weft derives a component's DOM id from its first declared attribute. Cleared, the wrapper comes back as the same `#comment-section` the htmx wiring points at; left populated, the submitted name would leak into the re-rendered component's identity.
+**Clearing the params in the return keeps the identity stable.** The callable ends with `{ author: nil, body: nil }` — a returned hash merges into the params for the re-render ([the callable contract](../dsl.md#the-callable-contract)), and Weft derives a component's DOM id from its first declared param. Cleared, the wrapper comes back as the same `#comment-section` the htmx wiring points at; left populated, the submitted name would leak into the re-rendered component's identity.
 
 **Blank submits are the callable's problem, and it handles them.** The browser happily posts `author=&body=`; the strip-and-check guard appends nothing, and the response is simply the current state re-rendered. Client-side `required` attributes would be a fine courtesy on top, but the server-side guard is the one that holds.
 
@@ -97,5 +97,5 @@ In a real browser the captured round trip reads the same: the POST body carries
 ## Related
 
 - [File Upload](file-upload.md) — clearing a param in the return for a different reason.
-- [Click to Edit](click-to-edit.md) — when you *do* want fields pre-filled, pair them with declared attributes.
+- [Click to Edit](click-to-edit.md) — when you *do* want fields pre-filled, pair them with declared params.
 - [`performs`](../dsl.md#performs--user-initiated-actions) and [the callable contract](../dsl.md#the-callable-contract) in the DSL reference.

data/docs/examples/tabs.md

@@ -59,11 +59,11 @@ end
 
 ## How it works
 
-**Every button aims at the same panel.** [`tabs:`](../dsl.md#shorthands) presets trigger `:click` and swap `:fill`; the call site supplies the shared target. Clicking a tab fetches its component and replaces the panel's contents. The default tab is simply pre-rendered into the panel — the initial state is the same component a click would fetch.
+**Every button aims at the same panel.** [`tabs:`](../dsl.md#presets) presets trigger `:click` and swap `:fill`; the call site supplies the shared target. Clicking a tab fetches its component and replaces the panel's contents. The default tab is simply pre-rendered into the panel — the initial state is the same component a click would fetch.
 
-**`routable!` makes contentful-but-stateless tabs fetchable.** A component normally earns its route by declaring attributes or verbs ([Routing](../routing.md)); these tabs declare neither, so without help they would render fine *and* be unreachable over the wire — the buttons would point at URLs that 404. `routable!` opts them in explicitly. (Tabs that take wire state — an `order_id`, say — get their routes the ordinary way and don't need it.)
+**`routable!` makes contentful-but-stateless tabs fetchable.** A component normally earns its route by declaring params or verbs ([Routing](../routing.md)); these tabs declare neither, so without help they would render fine *and* be unreachable over the wire — the buttons would point at URLs that 404. `routable!` opts them in explicitly. (Tabs that take wire state — an `order_id`, say — get their routes the ordinary way and don't need it.)
 
-**The selected tab isn't highlighted — yet.** Only the panel is swapped; the buttons themselves never re-render, so nothing moves a "selected" class around. htmx's example re-renders the whole tab bar with each click for exactly this reason. The Weft equivalent of that move is to give the wrapping component the state and re-render it whole — `attribute :tab` plus [`navigate: { tab: "shipping" }`](../dsl.md#navigate) on each button replaces the entire `ProductTabs` component, selected styling included, at the cost of re-sending the bar with every switch. Start with the version above; reach for `navigate:` when the highlight matters.
+**The selected tab isn't highlighted — yet.** Only the panel is swapped; the buttons themselves never re-render, so nothing moves a "selected" class around. htmx's example re-renders the whole tab bar with each click for exactly this reason. The Weft equivalent of that move is to give the wrapping component the state and re-render it whole — `param :tab` plus [`navigate: { tab: "shipping" }`](../dsl.md#navigate) on each button replaces the entire `ProductTabs` component, selected styling included, at the cost of re-sending the bar with every switch. Start with the version above; reach for `navigate:` when the highlight matters.
 
 ## On the wire
 
@@ -99,4 +99,4 @@ Clicking Shipping issues `GET /_components/shipping_tab`, and the response fills
 
 - [Active Search](active-search.md) — the same fill-a-stable-container shape, driven by typing instead of clicks.
 - [`abstract!` and `routable!`](../routing.md#abstract-and-routable) in the routing reference.
-- The [shorthands table](../dsl.md#shorthands) in the DSL reference.
+- The [presets table](../dsl.md#presets) in the DSL reference.

data/docs/examples/tooltip.md

@@ -2,7 +2,7 @@
 
 Hovering over an element fetches a small piece of server-rendered detail — a profile card, a definition, a status readout — and places it in a bubble beside the trigger. The detail is rendered fresh from the server on first hover, then stays put.
 
-There's no counterpart for this in the htmx examples catalog; `tooltip:` is Weft-native sugar over the same [`loads:`](../dsl.md#loads) machinery as the other shorthands. It earns its keep when the tooltip content is worth a server round-trip — live data, per-record queries — rather than static text a `title=` attribute could carry.
+There's no counterpart for this in the htmx examples catalog; `tooltip:` is Weft-native sugar over the same [`loads:`](../dsl.md#loads) machinery as the other presets. It earns its keep when the tooltip content is worth a server round-trip — live data, per-record queries — rather than static text a `title=` attribute could carry.
 
 ## The components
 
@@ -16,12 +16,12 @@ TEAM = {
 class MemberPeek < Weft::Component
   builder_method :member_peek
 
-  attribute :handle
+  param :handle
 
   def build(attributes = {})
     super
-    member = TEAM.fetch(attrs.handle)
-    strong attrs.handle.capitalize
+    member = TEAM.fetch(params.handle)
+    strong params.handle.capitalize
     para "#{member[:role]} — #{member[:timezone]}"
     para "Focus: #{member[:focus]}"
   end
@@ -51,11 +51,11 @@ end
 
 ## How it works
 
-**Hover fetches; the bubble receives.** [`tooltip:`](../dsl.md#shorthands) presets trigger `:hover` and swap `:fill`; the call site says where the content lands. Each name targets its own empty bubble div (`target: "#peek-#{handle}"`), so every row has an independent tooltip slot. The bubbles start empty and cost nothing until hovered.
+**Hover fetches; the bubble receives.** [`tooltip:`](../dsl.md#presets) presets trigger `:hover` and swap `:fill`; the call site says where the content lands. Each name targets its own empty bubble div (`target: "#peek-#{handle}"`), so every row has an independent tooltip slot. The bubbles start empty and cost nothing until hovered.
 
 **`:hover` means *first* hover.** The semantic trigger expands to htmx's `mouseenter once` — the fetch happens the first time the pointer enters, and never again. Be clear about what that buys and what it doesn't: Weft delivers the *content*, once, lazily. It does not show and hide the bubble as the pointer comes and goes — that's presentation, and it belongs to CSS (a `.peek-bubble` hidden until `li:hover`, for instance). After the first hover, showing the tooltip again is free, because the content is already in the page.
 
-**Per-row wire attrs, one component.** Every trigger loads the same `MemberPeek` class with a different `with: { handle: ... }` — the component is written once and addressed per record, which is the same shape as every list-plus-detail pattern in this catalog.
+**Per-row wire params, one component.** Every trigger loads the same `MemberPeek` class with a different `with: { handle: ... }` — the component is written once and addressed per record, which is the same shape as every list-plus-detail pattern in this catalog.
 
 ## On the wire
 
@@ -83,6 +83,6 @@ The first hover over Priya issues `GET /_components/member_peek?handle=priya`, a
 
 ## Related
 
-- [Inline Expansion](inline-expansion.md) — the other Weft-native shorthand: click-driven detail that lands *after* its trigger instead of in a bubble.
+- [Inline Expansion](inline-expansion.md) — the other Weft-native preset: click-driven detail that lands *after* its trigger instead of in a bubble.
 - [Lazy Loading](lazy-loading.md) — the same load-once deferral, triggered by visibility instead of the pointer.
-- The [shorthands table](../dsl.md#shorthands) in the DSL reference.
+- The [presets table](../dsl.md#presets) in the DSL reference.

data/docs/examples/updating-other-content.md

@@ -28,13 +28,13 @@ end
 class NewContactForm < Weft::Component
   builder_method :new_contact_form
 
-  attribute :name
-  attribute :email
+  param :name
+  param :email
 
   includes ContactsTable
 
-  performs :add do |attrs|
-    ADDRESS_BOOK << { name: attrs.name, email: attrs.email }
+  performs :add do |params|
+    ADDRESS_BOOK << { name: params.name, email: params.email }
     { name: nil, email: nil }
   end
 
@@ -72,11 +72,11 @@ end
 
 **`includes` declares the relationship once, in the class body.** [`includes ContactsTable`](../dsl.md#includes--companions-in-the-same-response) means: whenever this form responds to an action, render the table too, marked out-of-band. htmx receives one response containing two fragments — the re-rendered form swaps into the form's place as usual, and the table fragment, carrying `hx-swap-oob="true"`, is routed to its own DOM slot by id (`#contacts-table`). One request, one response, two regions updated. This is htmx's out-of-band solution with the response construction, the OOB attribute, and the id bookkeeping all handled for you.
 
-**The included component needs no route.** In this variant `ContactsTable` declares no attributes and no verbs, so it isn't independently addressable — `GET /_components/contacts_table` answers 404 — and that's fine: it renders inside the page and travels inside the form's responses. Companions only need to *render* (see [routing](../routing.md#routable-vs-render-target)).
+**The included component needs no route.** In this variant `ContactsTable` declares no params and no verbs, so it isn't independently addressable — `GET /_components/contacts_table` answers 404 — and that's fine: it renders inside the page and travels inside the form's responses. Companions only need to *render* (see [routing](../routing.md#routable-vs-render-target)).
 
-**The callable resets the form.** An action callable's return value directs the re-render ([the callable contract](../dsl.md#the-callable-contract)): returning a hash merges it into the attrs. Returning `{ name: nil, email: nil }` clears the just-submitted values, so the form comes back empty after each add — htmx's reset-the-form problem solved server-side, with no `hx-on` handler. (It also keeps the component's derived DOM id, which is built from the first attribute's value, stable across renders.)
+**The callable resets the form.** An action callable's return value directs the re-render ([the callable contract](../dsl.md#the-callable-contract)): returning a hash merges it into the params. Returning `{ name: nil, email: nil }` clears the just-submitted values, so the form comes back empty after each add — htmx's reset-the-form problem solved server-side, with no `hx-on` handler. (It also keeps the component's derived DOM id, which is built from the first param's value, stable across renders.)
 
-**Form fields pair with declared attributes.** The form declares `name` and `email` so the submitted fields reach the callable as `attrs.name` and `attrs.email` — the same pairing as every Weft form (covered in depth in [the tutorial](../tutorial.md#7-taking-rsvps)). And since `form(action: :add)` also emits plain `action`/`method` attributes, the add still works without JavaScript; only the tableside update needs htmx.
+**Form fields pair with declared params.** The form declares `name` and `email` so the submitted fields reach the callable as `params.name` and `params.email` — the same pairing as every Weft form (covered in depth in [the tutorial](../tutorial.md#7-taking-rsvps)). And since `form(action: :add)` also emits plain `action`/`method` attributes, the add still works without JavaScript; only the tableside update needs htmx.
 
 ## The decoupled variant
 
@@ -164,6 +164,6 @@ hears the event and issues `GET /_components/contacts_table`, which returns the
 
 ## Related
 
-- [Click to Edit](click-to-edit.md) — the form-fields-pair-with-attributes pattern this example builds on.
+- [Click to Edit](click-to-edit.md) — the form-fields-pair-with-params pattern this example builds on.
 - [`includes`](../dsl.md#includes--companions-in-the-same-response), [`triggers`](../dsl.md#triggers--announce-to-the-rest-of-the-page), and [`refreshes`](../dsl.md#refreshes--the-client-re-fetches) in the DSL reference.
-- `includes` accepts `on: :action_name` to scope a companion to one action, and a block to map the primary component's attrs onto the companion's — see [the DSL reference](../dsl.md#includes--companions-in-the-same-response).
+- `includes` accepts `on: :action_name` to scope a companion to one action, and a block to map the primary component's params onto the companion's — see [the DSL reference](../dsl.md#includes--companions-in-the-same-response).