Google Tag Manager - v1.0.0

Two fetcher classes compose multiple TagManagerClient calls into the shape the Livewire and HTTP surfaces render. They exist so both surfaces share one code path — bugs are caught once, not per-flavor.

ContainerOverviewFetcher

ArtisanPackUI\GoogleTagManager\Api\ContainerOverviewFetcher

fetch( GoogleConnection $connection, string $accountId, string $containerId, ?string $workspaceId = null ): ContainerOverviewData

Composes the container overview payload from four API calls:

1. listContainers — resolve the container by ID for name / public ID
2. listWorkspaces — resolve the workspace (default when $workspaceId is null; validated when supplied)
3. listTags, listTriggers, listVariables — counts for the workspace
4. latestVersionHeader — nullable

Throws:

• ApiException when the caller-supplied workspace ID is not in the container
• ApiException (bubbled from TagManagerClient) for any upstream failure

TagListFetcher

ArtisanPackUI\GoogleTagManager\Api\TagListFetcher

fetch( GoogleConnection $connection, string $accountId, string $containerId, string $workspaceId ): TagListData

Composes the tag list with firing/blocking triggers joined by name:

1. listTags — the raw tag list
2. listTriggers — needed to translate trigger IDs to trigger names in the tag rows

Falls back to the trigger ID when a name lookup misses (e.g. a stale trigger reference).

Throws ApiException for any upstream failure.

Why fetchers exist separately from the client

TagManagerClient mirrors the API surface — one method per endpoint, one call per method. That's the right layer for testing and for callers that want raw access.

Fetchers are the composition layer — the answer to "what does the overview panel need?" Livewire components, the HTTP controllers, and the React/Vue fetchers all hit the fetchers, so the payload shape is guaranteed identical across every surface.