In Laravel, when would you use View::share, a view composer or a view creator to give every university page its department navigation?

## The problem: data every layout needs A university site's layout shows a department menu, the campus name, and maybe the signed-in student's name. Passing those from every controller is repetitive and easy to forget. Laravel's view factory offers three hooks for supplying such data centrally: **shared data**, **view composers** and **view creators**. They differ in *when* they run, and that timing decides which one fits. ## View::share: one value for every view `View::share('campusName', config('app.name'))`, usually placed in `App\Providers\AppServiceProvider::boot()`, stores a key on the view factory. Every view rendered afterwards receives it, because the factory merges shared data into each view's data at render time. - It is **eager**: the value is computed when the provider boots, on every request, including API requests that never render a view. A database query here costs every request. - It runs **before middleware**. Providers boot before the HTTP middleware pipeline, so the session has not been started and the authenticated user is not known yet. Request-specific values do not belong here. - It has the **lowest precedence**: shared data is merged first, so any key a controller passes with the same name wins. It suits cheap, request-independent values such as a campus name or a support email address. ## View composers: data at render time A **view composer** is a closure or class registered for one or more view names: 1. Register it in a provider's `boot()`: `View::composer('partials.nav', DepartmentNavComposer::class)`. An array of names or a `'*'` wildcard also works. 2. For a class, Laravel resolves it from the **service container**, so its constructor can type-hint dependencies, and calls its `compose(View $view)` method. 3. The call happens right before that view renders, and the composer adds data with `$view->with('departments', ...)`. Because it is **lazy**, the department query runs only when the navigation partial is actually rendered, and by then middleware has run, so the session and the user are available. It also keeps data next to the view that needs it instead of in every controller. The costs are worth knowing in production: - The composer runs **every time** that view renders. A partial included three times per page runs its composer three times; memoize the result, for example with `Cache::remember`, or bind the composer class as a singleton and keep the loaded result in a property. - A `'*'` composer runs for **every view**, including each component and partial, which on a busy page is hundreds of calls. - Because it runs last, a composer's `with()` **overrides** a key the controller passed under the same name. ## Organising composers Laravel ships no default directory for composer classes; `app/View/Composers` is a common convention. Some practical rules: - register composers in a service provider's `boot()` method, next to other view setup; - prefer a **class** once the composer has dependencies, so they are injected through the constructor and the class can be unit tested; - attach a composer to the **smallest view** that needs the data, such as `partials.nav`, not to the whole layout or to `'*'`; - keep the registration next to the view name it targets, since renaming the partial without updating it leaves the menu's variable undefined and the render fails. ## View creators: data at creation time `View::creator('partials.nav', DepartmentNavCreator::class)` looks the same but fires **as soon as the view object is created**, when `view()` or `View::make()` builds it, before rendering. A class creator's method is `create(View $view)`. The practical difference is precedence: data attached after creation, such as `view('courses.index')->with('departments', $filtered)`, overrides what the creator set, while a composer would have overridden the controller. Use a creator for defaults a controller is allowed to replace. ## Choosing | Need | Hook | Why | |---|---|---| | cheap constant for every view | `View::share` | set once at boot, lowest precedence | | data for one partial, fetched only when shown | `View::composer` | lazy, runs after middleware, container-resolved | | a default that controllers may override | `View::creator` | runs at creation, later `with()` wins | | request-specific values like the current user | a composer, or data passed by the controller | boot-time sharing runs before the session exists | For the department menu, a class-based composer on `partials.nav` with a cached query is the usual answer: the data is fetched only where the menu appears, it sees the current request, and its cost is paid once per request rather than once per include.