In Blade, how do @push, @prepend, @stack and @pushOnce let each university course page add its own scripts to a shared layout?

## What a stack is A **stack** in Blade is a named bucket of HTML held by the view factory while a response renders. Any view taking part in the render can add to it, and a layout prints it wherever it wants. The classic use is per-page assets: a university site's shared layout should not load the campus-map script on every page, but the pages that show a map need it. - `@push('scripts') ... @endpush` appends a block to the `scripts` stack. - `@prepend('scripts') ... @endprepend` adds a block that comes out **ahead of** all pushed blocks. - `@stack('scripts')` prints the stack's collected content at that spot. - `@pushIf($condition, 'scripts') ... @endPushIf` pushes only when the condition is true. - `@hasstack('scripts') ... @endif` wraps markup that should appear only when the stack is not empty. `@push` itself prints nothing where it is written; the block only appears where `@stack` prints it. ## Why pushes reach the layout A stack is printed exactly once, at the moment `@stack` executes, and it contains whatever has been collected by then. Pages reach the layout's stack because of render order: 1. With template inheritance, the child's code runs first and the layout is rendered from the child's compiled footer. 2. With a layout component, the markup between `<x-layout>` tags is captured into the slot before the component's own template renders. Either way, the page's `@push` blocks execute before the layout reaches `@stack`. ## The timing trap The same rule bites inside the layout itself. Suppose the layout prints `@stack('scripts')` in `<head>` and later, in `<body>`, includes a footer partial that pushes a cookie-banner script. The stack has already been printed when the footer runs, so the banner script **never appears**, and no error is raised. The fixes: - print `@stack('scripts')` near the end of `<body>`, after the includes that push to it; - or keep head-bound assets in a separate stack (for example `styles`) that only pages and slot content push to. ## Ordering | Source | Where it lands in `@stack` output | |---|---| | `@prepend` blocks | first, ahead of every pushed block | | `@push` blocks | after the prepended blocks, concatenated in collection order | | nothing pushed | `@stack` prints nothing; `@hasstack` is false | If script order matters, for example a library before the code that uses it, `@prepend` the library or push it from a place that is guaranteed to run first. ## @pushOnce and @prependOnce Components are where duplicate pushes happen. A `course-card` component that shows a small map and pushes the map script would push it once per card, so a listing of thirty courses loads the script thirty times. `@pushOnce('scripts') ... @endPushOnce` fixes that: - Without a second argument, the compiler generates a **UUID for that directive at compile time**, so the block is pushed once per render no matter how many times that template renders. - That identity is per directive, not per content. If `course-card` and `event-card` both push the same map library, each directive has its own UUID and the library is pushed twice. Give both the same explicit id: `@pushOnce('scripts', 'campus-map')`. - `@prependOnce` is the same thing for prepends. ## A worked university example A course page for Marine Biology shows a campus map and a timetable widget: 1. The page wraps itself in `<x-layout>` and, inside the slot, does `@push('scripts')` for the timetable script only it needs. 2. It renders a `course-card` component for each related course; each card uses `@pushOnce('scripts', 'campus-map')` for the map library. 3. The layout prints the slot, then includes the footer partial, and prints `@stack('scripts')` last, just before `</body>`. The response contains the timetable script once, the map library once, and any script the footer pushed, and pages without maps load neither library. ## Lifetime Stacks, sections and the "rendered once" markers live on the view factory only for the current top-level render. When the outermost view finishes rendering, or throws, the factory flushes that state, so pushes never leak into the next response or into a view rendered after that one finishes.