next.dj
Signals reference#
Module summary#
next.signals is an aggregator that re-exports every framework signal.
Importing a signal from next.signals is equivalent to importing it from its subpackage.
Signal catalog#
Every signal below is a Django Signal.
The sender column lists the value passed to Signal.send.
Receivers connected with a matching sender only fire for that sender.
The dispatch-time form signals (action_dispatched, form_validation_failed, wizard_step_submitted, wizard_completed, form_access_denied) share two keyword arguments.
uid is the registry identity of the action, the value the dispatch URL and the data-next-action markup attribute carry, or None when a custom backend stores no uid in its meta.
request is the live HttpRequest being dispatched and must not be retained past the receiver call.
Signal |
Sender |
Keyword arguments |
When it fires |
|---|---|---|---|
|
|
|
After an action handler runs and the response is coerced, and once per valid wizard step.
|
|
Form action backend class |
|
After the backend stores an action target for a name.
Exactly one of |
|
The |
|
After a file is registered with a backend and added to the collector. |
|
The static backend class |
|
After the static factory instantiates a backend. |
|
The static collector |
|
When the static manager begins injection, after template rendering completes.
|
|
The component backend class |
|
After a component backend is created from its configuration entry. |
|
|
|
After a single component is registered. Not fired from the bulk path. |
|
|
|
After a component is rendered to HTML. |
|
|
|
After a batch of components is registered. |
|
|
|
After a context callable is attached to a page module. |
|
The active partial protocol backend class |
|
After a validate-only blur pass runs, always behind the action guard so unauthenticated validate traffic never reaches telemetry.
|
|
|
|
When a dynamic permission hook denies a request, never on the static guard path.
|
|
|
|
When the bound form fails validation during dispatch. |
|
A |
|
After placeholder replacement completes. |
|
|
|
After |
|
|
|
After a custom patch verb is registered through |
|
The |
none |
When a |
|
|
|
After a URL pattern is created for a discovered page. |
|
The router manager class |
none |
After the router manager rebuilds its pattern set. |
|
|
none |
After |
|
|
|
When a patch event stream ends, its source exhausted or the client gone. |
|
|
|
When a patch event stream starts. |
|
|
|
After a template source is registered on a page. |
|
|
|
After the reloader resolves the full list of watch specs. |
|
The wizard class |
|
After the wizard |
|
The wizard class |
|
After a |
|
The compiled page template class |
|
Once per compiled composed template, when its named zones are first read. |
|
|
|
After a zone body renders for a partial request. |
Subpackage signals#
The aggregator next.signals forwards from the modules below.
Pages#
Signals emitted during template loading, context collection, and rendering.
These signals let external subscribers observe the page rendering pipeline without subclassing internal collaborators.
The template_loaded signal fires after a template source is registered on a page. The sender is Page. The keyword argument is file_path.
The context_registered signal fires after a context callable is attached to a page module. The sender is PageContextRegistry. The keyword arguments are file_path and key.
The page_rendered signal fires after Page.render finishes producing HTML and injecting static assets. The sender is Page. The keyword arguments are file_path, duration_ms, styles_count, scripts_count, and context_keys.
Components#
Django signals emitted by the components subsystem.
URLs#
Django signals emitted by the URL routing subsystem.
Forms#
Django signals emitted by the forms subsystem.
The action_registered signal fires after the backend stores an action target for a name. The sender is the backend class. The keyword arguments are action_name, uid, form_class, wizard_class, file_path, scope, and handler. Exactly one of handler, form_class, or wizard_class identifies the registered target, except the @action(form_class=…) path which supplies a handler and a form factory together. file_path is the module the form, wizard, or handler was declared in and scope is “page” or “shared”. Together they give receivers a real grouping key under the file-scoped model.
Every dispatch-time signal (action_dispatched, form_validation_failed, wizard_step_submitted, wizard_completed) carries uid and request. uid is the registry identity of the action, the same value the action URL and the data-next-action markup attribute carry, or None when a custom backend stores no uid in its meta. request is the live HttpRequest being dispatched and must not be retained past the receiver call.
The action_dispatched signal fires after a handler runs and the response has been coerced. It also fires once per valid wizard step, where a step advance runs no handler and reports duration_ms as 0.0. The sender is FormActionDispatch. The keyword arguments are action_name, uid, request, form, url_kwargs, duration_ms, response_status, and dep_cache. form is the bound form instance after successful validation, or None for handler-only actions registered without a form_class. url_kwargs is a copy of the URL kwargs the dispatcher resolved before invoking the handler. dep_cache is a snapshot of the dispatch DI cache so receivers can read named dependencies (Depends(“name”) values) resolved during this dispatch without re-running their providers.
The form_validation_failed signal fires when the bound form fails validation during dispatch. The sender is FormActionDispatch. The keyword arguments are action_name, uid, request, error_count, and field_names.
The wizard_step_submitted signal fires after a FormWizard step validates during dispatch. The sender is the wizard class, so receivers connected with sender=MyWizard fire for that wizard only. The keyword arguments are step, cleaned_data, uid, and request. cleaned_data is a copy of the validated cleaned data for that step.
The wizard_completed signal fires after the wizard done method runs for the final step and its response is below HTTP 400. An error response from done skips the signal and keeps the saved drafts for retry. The sender is the wizard class. The keyword arguments are cleaned_data, uid, and request. cleaned_data is the merged mapping passed to done.
The form_access_denied signal fires only when a dynamic permission hook denies a request, never on the static ActionGuard fast-path. The sender is FormActionDispatch. The keyword arguments are action_name, uid, request, layer, and reason. layer is “view” for a check_permissions denial or “object” for a has_object_permission denial. reason is “raised” when the hook raised PermissionDenied, “denied” when it returned False, or “response” when it returned an HttpResponse short-circuit.
Static#
Django signals emitted across the static pipeline.
Signals are the primary extension mechanism for hooking into asset lifecycle events without subclassing the collector, the backend, or the manager. Subscribe from AppConfig.ready and keep handlers synchronous. All four signals are dispatched in hot rendering paths.
The asset_registered signal fires after a file is registered with a backend and added to the collector. The sender is the asset instance and the keyword arguments are collector and backend.
The collector_finalized signal fires when the static manager begins injection, after template rendering has completed and the collector is sealed. The sender is the collector. The keyword arguments are page_path, the rendered page’s file path, and request, the active HttpRequest or None for renders outside a request lifecycle. A standalone zone render does not fire this signal, since it ships its assets through the patch envelope rather than through injection.
The html_injected signal fires after placeholder replacement completes. The sender is the static manager. The keyword arguments are html_before, html_after, collector, placeholders_replaced, injected_bytes, and request. The request argument carries the active HttpRequest or None.
The backend_loaded signal fires after the shared backend loader instantiates a static backend. The sender is the backend class. The keyword arguments are config and instance.
Partial rendering#
Django signals emitted by the partial-rendering subsystem.
Every signal name is past tense and the sender is the owning class. The hot-path idiom is to send only when the signal has receivers, so a quiet deployment pays nothing.
The zone_registered signal fires once per compiled composed template when its named zones are first read. The sender is the compiled template class. The keyword arguments are template, zone_name, lazy, and poll.
The zone_rendered signal fires after a zone body renders for a partial request. The sender is the ZoneRenderResult class. The keyword arguments are zone_name, page_path, request, and duration_ms.
The patch_op_registered signal fires after a custom patch verb is registered through register_patch_op. The sender is PatchOpRegistry. The keyword argument is name.
The field_validated signal fires after a validate-only pass runs, always behind the action guard so unauthenticated validate traffic never reaches telemetry. The sender is the backend class. The keyword arguments are action_name, uid, request, field_names, and error_count.
The sse_stream_opened signal fires when a patch event stream starts. The sender is PatchEventStream. The keyword argument is request.
The sse_stream_closed signal fires when a patch event stream ends. The sender is PatchEventStream. The keyword arguments are request, duration_ms, and envelopes_sent.
Dependencies#
Django signals emitted by the dependency-injection layer.
provider_registered fires whenever a RegisteredParameterProvider subclass is added to the auto-registry. External code may listen to the signal to observe provider wiring, typically in tests or diagnostics.
- next.deps.signals.provider_registered: Signal = <django.dispatch.dispatcher.Signal object>#
Emitted when a RegisteredParameterProvider subclass registers itself.
Server#
Signals emitted by the development server watch layer.
watch_specs_ready fires after the reloader resolves the full list of watch specs. Subscribers can inspect or augment the effective spec set without subclassing the reloader.
Configuration#
Django signals emitted by the configuration layer.
settings_reloaded fires after NextFrameworkSettings.reload drops its caches. Package-level managers subscribe to this signal and reset their own state when the merged settings change. The module also wires the Django setting_changed signal so that tests using override_settings trigger the reload path automatically.
- next.conf.signals.settings_reloaded: Signal = <django.dispatch.dispatcher.Signal object>#
Emitted when NextFrameworkSettings caches have been dropped.
See also#
See also
Signals for receiver patterns and testing helpers.