 |
VOOZH | about |
|
VOOZH | about |
This document explains how Telescope integrates with both the Hyperf and Hypervel frameworks through a dual-provider architecture. Telescope employs two distinct integration mechanisms: the ConfigProvider for low-level Hyperf dependency injection container integration, and the TelescopeServiceProvider for high-level Hypervel service registration and bootstrapping.
For information about package structure and dependencies, see Package Structure and Dependencies. For configuration options that control Telescope's behavior, see Configuration.
Telescope uses two separate service providers to integrate with the framework stack:
| Provider | Framework | Purpose | Registration Method |
|---|---|---|---|
ConfigProvider | Hyperf | DI container bindings, aspect registration | extra.hyperf.config in composer.json |
TelescopeServiceProvider | Hypervel | Service bootstrapping, route/command registration | extra.hypervel.providers in composer.json |
This dual-provider pattern enables Telescope to leverage both Hyperf's infrastructure (dependency resolution, aspect-oriented programming) and Hypervel's higher-level abstractions (routing, console commands, service registration).
The composer.json36-47 file declares both providers in the extra section:
Sources: composer.json36-47
The ConfigProvider class integrates Telescope with Hyperf's dependency injection container and aspect-oriented programming system. This provider is automatically discovered and loaded by Hyperf's configuration scanner during application bootstrap.
The ConfigProvider is responsible for:
Sources: composer.json22-29
The TelescopeServiceProvider extends Hypervel's ServiceProvider base class and orchestrates Telescope's high-level initialization within the Hypervel framework. This provider executes during Hypervel's service provider boot sequence.
The src/TelescopeServiceProvider.php18-180 class performs the following initialization tasks:
register() method)The register() method executes first and configures Telescope's foundation:
| Task | Line Reference | Description |
|---|---|---|
| Configuration Merging | src/TelescopeServiceProvider.php114-117 | Merges config/telescope.php into application config |
| Storage Driver Registration | src/TelescopeServiceProvider.php119 | Binds repository contracts to implementations |
| Redis Events | src/TelescopeServiceProvider.php120 | Enables Redis command tracking if RedisWatcher is active |
| Cache Events | src/TelescopeServiceProvider.php121 | Enables cache operation tracking if CacheWatcher is active |
boot() method)The boot() method executes after all providers are registered and performs system activation:
| Task | Line Reference | Description |
|---|---|---|
| Command Registration | src/TelescopeServiceProvider.php25 | Registers console commands (clear, pause, prune, publish, resume) |
| Publishing Configuration | src/TelescopeServiceProvider.php26 | Declares publishable assets and migrations |
| Enabled Check | src/TelescopeServiceProvider.php28-30 | Exits early if telescope.enabled is false |
| Route Registration | src/TelescopeServiceProvider.php32 | Registers Telescope UI routes |
| Resource Registration | src/TelescopeServiceProvider.php33 | Loads view templates |
| System Start | src/TelescopeServiceProvider.php35 | Calls Telescope::start() to initialize watchers |
| Storage Listeners | src/TelescopeServiceProvider.php36 | Registers storage opportunity listeners |
| Coroutine Context Setup | src/TelescopeServiceProvider.php38-47 | Configures context propagation for child coroutines |
Sources: src/TelescopeServiceProvider.php18-180
The following diagram illustrates the complete initialization sequence when Telescope boots within a Hypervel application:
Sources: src/TelescopeServiceProvider.php22-48 src/TelescopeServiceProvider.php112-122
Telescope uses a dynamic driver registration pattern to bind repository contracts to concrete implementations. The src/TelescopeServiceProvider.php151-158 method determines which storage driver to register based on configuration.
The default database driver binds three repository contracts to DatabaseEntriesRepository:
The src/TelescopeServiceProvider.php163-179 method registers these bindings:
| Contract | Implementation | Purpose |
|---|---|---|
EntriesRepository | DatabaseEntriesRepository | Core storage operations (store, find, get) |
ClearableRepository | DatabaseEntriesRepository | Clear operation support |
PrunableRepository | DatabaseEntriesRepository | Prune operation support |
Sources: src/TelescopeServiceProvider.php151-179
Telescope registers its web interface routes through Hypervel's Route facade. The src/TelescopeServiceProvider.php53-63 method configures the route group:
The route registration reads configuration from config/telescope.php:
telescope.path: Base path for the UI (default: telescope)telescope.middleware: Array of middleware to apply (typically includes authorization)Sources: src/TelescopeServiceProvider.php53-63
Telescope conditionally enables Redis and Cache event tracking based on watcher configuration. This prevents unnecessary overhead when watchers are disabled.
The src/TelescopeServiceProvider.php127-134 method checks if RedisWatcher is enabled:
The src/TelescopeServiceProvider.php139-146 method checks if CacheWatcher is enabled:
This pattern ensures that event listeners are only registered when their corresponding watchers are active, minimizing performance impact.
Sources: src/TelescopeServiceProvider.php127-146
A critical aspect of Telescope's Hyperf integration is proper context management across coroutines. Swoole's coroutine model creates child coroutines for asynchronous operations, and Telescope must ensure recording state propagates correctly.
The src/TelescopeServiceProvider.php38-47 method registers a coroutine lifecycle hook:
| Key | Default Value | Purpose |
|---|---|---|
Telescope::SHOULD_RECORD | false | Whether recording is enabled for current request |
Telescope::IS_RECORDING | false | Re-entrancy guard to prevent infinite loops |
Telescope::BATCH_ID | null | UUID grouping entries from same request |
The hook reads each key from the parent coroutine's context using Coroutine::parentId() and writes it to the child's context. This ensures that child coroutines inherit the recording state, allowing Telescope to track operations across asynchronous boundaries.
Sources: src/TelescopeServiceProvider.php38-47
Telescope leverages multiple Hyperf components as declared in composer.json22-29:
| Component | Version | Usage |
|---|---|---|
hyperf/context | ~3.1.0 | Request-scoped state management, coroutine-safe storage |
hyperf/support | ~3.1.0 | Utility functions, string helpers, array manipulation |
hyperf/stringable | ~3.1.0 | Fluent string manipulation for data formatting |
hyperf/tappable | ~3.1.0 | Fluent interface pattern support |
hyperf/collection | ~3.1.0 | Data collection operations, filtering, mapping |
| Component | Version | Usage |
|---|---|---|
hypervel/core | ^0.3 | Service provider base class, routing facade, console framework |
Sources: composer.json22-29
The dual-provider architecture ensures Telescope integrates seamlessly with both Hyperf's infrastructure layer (DI container, AOP) and Hypervel's application layer (routing, commands, views). This separation of concerns enables Telescope to leverage low-level framework capabilities while maintaining high-level developer ergonomics.
Sources: composer.json36-47 src/TelescopeServiceProvider.php18-180
Refresh this wiki