Lifecycle
Sprout does certain things at certain points during Laravel's lifecycle, but it also has its own lifecycle and functionality that allows you to work with it.
This section of the documentation is going to be one of the last pieces to be completed, as it directly reflects how the package works, which is subject to change.
Laravel Lifecycle
The first lifecycle we need to look at is Laravel's, so you can see what Sprout is doing at the relevant points.
Service Provider Registration
The service provider registration stage is the first part of Laravel's lifecycle where Sprout does anything, and it does the following, in the following order.
- Registers bindings for the core Sprout class
- Registers
Sprout\Sprout
as a singleton - Aliases
Sprout\Sprout
tosprout
- Binds
Sprout\Support\SettingsRepository
using theSprout\Sprout::settings()
method
- Registers
- Registers bindings for the managers
- Registers
Sprout\Managers\ProviderManager
as a singleton - Registers
Sprout\Managers\IdentityResolverManager
as a singleton - Registers
Sprout\Managers\TenancyManager
as a singleton - Aliases
Sprout\Managers\ProviderManager
assprout.providers
- Aliases
Sprout\Managers\IdentityResolverManager
assprout.resolvers
- Aliases
Sprout\Managers\TenancyManager
assprout.tenancies
- Registers
- Aliases the
Sprout\Http\Middleware\TenantRoutes
middleware assprout.tenanted
with the router - Adds the mixin
Sprout\Http\RouterMethods
toIlluminate\Routing\Router
- Registers a call to
Sprout\Sprout::bootOverrides()
to be called once the application has finished booting
Service Provider Booting
During the booting stage of Laravel's lifecycle, Sprout does the following, in the following order.
- Registers publishable config
- Registers the
sprout.php
config file for publishing - Registers the
multitenancy.php
config file for publishing - Registers both config files with the tags
config
andsprout-config
- Registers the
- Registers the configured service overrides
- Registers event listeners
- Registers the
Sprout\Listeners\IdentifyTenantOnRouting
listener to theIlluminate\Routing\Events\RouteMatched
event for the routing resolution hook
- Registers the
- Registers the configured tenancy bootstrappers
- Registers each bootstrapper as a listener for the
Sprout\Events\CurrentTenantChanged
event
- Registers each bootstrapper as a listener for the
After Booting
Once Laravel has fully booted, Sprout does the following, in the following order.
- Boots previously registered bootable overrides, in the
order they're configured
- This will include the following services if they're registered
-
Sprout\Overrides\AuthOverride
-
Sprout\Overrides\JobOverride
-
- This will also include the following services if they're registered, and the services they override have been
resolved
-
Sprout\Overrides\CacheOverride
-
Sprout\Overrides\SessionOverride
-
Sprout\Overrides\StorageOverride
-
- This will include the following services if they're registered
- This is where the booting resolution hook is ideally going to be
Routing
During the routing stage of Laravel's lifecycle, Sprout does the following, in the following order.
- Attempts to resolve a tenant when a route is matched, if the routing resolution hook is enabled
- Attempts to resolve a tenant during the middleware run, if the middleware resolution hook is enabled
Sprout Lifecycle
Sprout has its own lifecycle, or rather, a handful of lifecycles for each of the different things that it needs to do. These lifecycles are as follows.
Service Override Lifecycle
Service overrides have their own lifecycle that's not entirely unlike that of a service provider. The following is a breakdown of this lifecycle into its steps.
Registering a Service Override
When a service override is registered, the following happens in the following order.
- The service override class is validated as being a subclass of
Sprout\Contracts\ServiceOverride
- If the class is invalid, an
InvalidArgumentException
is thrown
- If the class is invalid, an
- The service override class is marked as registered
- A
Sprout\Events\ServiceOverrideRegistered
event is dispatched with the service override class - If the service override is deferrable, it goes through the deferrable process
- If the service override is not deferrable, it goes through processing
Processing a Service Override
Once a service override is registered, it needs to be processed. During this processing, the following happens, in the following order.
- A
Sprout\Events\ServiceOverrideProcessing
event is dispatched with the service override class - The service override class is resolved using Laravels container, and the resulting instance is stored
- If the service override is bootable, it goes through the bootable process
- A
Sprout\Events\ServiceOverrideProcessed
event is dispatched with the service override instance
Deferring a Service Override
If a registered service override is deferrable, the following happens, in the following order.
- Its processing is delayed until its service has been resolved within Laravels container
- If the service it watches has already been resolved, processing happens immediately
Booting a Service Override
If a registered service override is bootable, the following happens in the following order.
- It is registered as being bootable
- If the service overrides have already been booted, it is booted
Once a registered and bootable service override is actually booted, the following happens in the following order.
- The
ServiceOverride::boot()
method is called - The service override is flagged as having been booted
- A
Sprout\Events\ServiceOverrideBooted
event is dispatched with the service override instance