Documentation
¶
Overview ¶
Package layoutfunc flags route-state reads that are lexically inside a layout build (an app.LayoutFunc body) and outside a RouteArea closure (docs/DESIGN-layout-outlets.md, "The lint").
Why: a tree layout's build markup is the STATIC chrome of its layer. On a subtree partial the KEPT layers' builds run in collect mode and their markup is discarded — only RouteArea fns travel, as fills. A build that reads the route match (app.MatchFromContext, Match.Param, Match.Path, route.From) or the request (app.RequestFromContext) therefore bakes request-derived chrome into the DOM that no later navigation refreshes: after the first click the shell shows the previous route's state. The correct tools are l.RouteArea (the state arrives as the fn's Match parameter and re-renders per navigation) and the route.* signal bindings, which follow every applied seed.
Reads lexically inside a RouteArea closure are the allowed case — including nested closures, and a closure passed by identifier — and everything outside a LayoutFunc body (a resolver, a screen Load, a helper) is silent: the lint is about where the read lives, not whether route state is readable.
Born with the 404-outlet work a shell that derived its nav from MatchFromContext went stale on every partial.
Index ¶
Constants ¶
This section is empty.
Variables ¶
var Analyzer = &analysis.Analyzer{
Name: "layoutfunc",
Doc: "flags app.MatchFromContext / Match.Param / Match.Path / route.From / app.RequestFromContext read inside a LayoutFunc body and outside a RouteArea closure: the build's markup is static chrome a partial never refreshes, so request-derived chrome goes stale after the first navigation",
Run: run,
}
Functions ¶
This section is empty.
Types ¶
This section is empty.
Source Files