ma
marcoroth
GitHub
herb
Workspace
GitHub
CI Pipeline Executions
Filtered
Runs
Demo
Insights
Compare tasks
Analytics
Sign in
Toggle sidebar
Overview
⌘K
herb
Loading workspace stats
Loading workspace insights...
Statistics interval
7 days
30 days
Latest CI Pipeline Executions
Status
Fix filter
Filter
Fuzzy
Filter range
Sort by
Sort by
Start time
Sort ascending
Sort descending
Succeeded
slots/propagation
3b34301e Analysis: Carry a page's state into the partials that render it
by Marco Roth
M
Succeeded
slots/propagation
60e3e905 Analysis: Carry a page's state into the partials that render it
by Marco Roth
M
Succeeded
slots/propagation
6701ea62 Analysis: Leave a collection's item template to the server A page names its state once. A template rendered for each of a collection's items renders once per item, so that name says nothing about which of them is meant, and a client writing the slot from the page would put the same value into every one of them. `render partial:, collection: @posts` reported the item template's slots as an identity, which is the one reading that is unsafe. Crossing a collection now downgrades an identity to derived, for that template and everything it renders in turn, so those slots are answered by the server that knows which item each one is. Rendering a partial inside an `each` block is the other shape this takes, and it needs nothing here: the trace does not follow a block parameter across a render call, so the item template is never reached and its slots subscribe to nothing. That is a missing subscription rather than a wrong write, and a slot nobody wrote asks the server like any other. Matching a render call to the template it reached is by name, so two partials that share one under different directories both count as a collection's. That errs towards the server, which is the direction that cannot be wrong.
by Marco Roth
M
Previous
Next