feat(kernel): Implement transport layer + field filtering (A3 + A5)#20
feat(kernel): Implement transport layer + field filtering (A3 + A5)#20
Conversation
… + A5)
- Add transport layer wrapping @wordpress/api-fetch
- Request correlation with auto-generated IDs (req_{timestamp}_{random})
- Event emission for wpk.resource.request/response/error
- Error normalization to KernelError types
- Query parameter handling with URL builder
- Field filtering support via _fields parameter (A5)
- Wire up resource client methods
- Implement list() method with query params and _fields support
- Implement get() method with path interpolation
- Both methods now call transport instead of throwing NotImplementedError
- Add comprehensive transport tests
- 21 tests covering request/response flow
- Event emission verification
- Query parameter and _fields handling
- Error normalization scenarios
- Environment handling (missing window/hooks)
- Standardize import patterns across test files
- Update all test files to use @kernel/ aliases
- Remove relative imports (../) for consistency
- Add @wordpress/api-fetch as peer dependency (>=7.0.0)
This completes Sprint 1 tasks A3 (Transport Layer) and A5 (Field Filtering).
All 254 tests passing, 94.94% coverage.
There was a problem hiding this comment.
Pull Request Overview
This PR implements the transport layer and field filtering functionality for the WP Kernel framework, providing a production-ready REST client wrapper around @wordpress/api-fetch. The implementation includes request correlation, event emission, error normalization, and optimized field selection via the _fields parameter.
- Adds comprehensive transport layer with request/response lifecycle management
- Implements field filtering support for REST API optimization
- Wires up resource client methods (
list()andget()) to use the transport layer
Reviewed Changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
packages/kernel/src/transport/types.ts |
Defines TypeScript interfaces for transport requests, responses, and event payloads |
packages/kernel/src/transport/fetch.ts |
Core transport implementation with request correlation, event emission, and error handling |
packages/kernel/src/transport/__tests__/fetch.test.ts |
Comprehensive test suite covering all transport functionality scenarios |
packages/kernel/src/resource/defineResource.ts |
Updates resource client methods to use transport layer instead of throwing NotImplementedError |
packages/kernel/src/index.ts |
Exports transport types and functions, removes duplicate HttpMethod export |
packages/kernel/package.json |
Adds @wordpress/api-fetch peer dependency |
| Multiple test files | Standardizes imports to use @kernel/ aliases |
| type ApiFetchOptions = { | ||
| path?: string; | ||
| url?: string; | ||
| method?: string; | ||
| data?: unknown; | ||
| parse?: boolean; | ||
| }; |
There was a problem hiding this comment.
The ApiFetchOptions type is defined inline within the function. Consider moving this to the types.ts file for reusability and better organization, or import it from @wordpress/api-fetch if available.
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| const globalWp = (window as any).wp; |
There was a problem hiding this comment.
The same window.wp type casting pattern is used multiple times in this file. Consider extracting this into a reusable type definition or helper function to reduce duplication and improve maintainability.
| status: 200, // @wordpress/api-fetch doesn't expose status, assume 200 on success | ||
| headers: {}, // @wordpress/api-fetch doesn't expose headers |
There was a problem hiding this comment.
These hardcoded values and comments indicate a limitation of the underlying @wordpress/api-fetch library. Consider documenting this limitation in the function's JSDoc or the transport module documentation to make it clear to API consumers.
| const response = await transportFetch<{ | ||
| items?: T[]; | ||
| total?: number; | ||
| hasMore?: boolean; | ||
| nextCursor?: string; | ||
| }>({ |
There was a problem hiding this comment.
The response type is defined inline. Consider extracting this to a named interface (e.g., ListResponseData<T>) in the types file for better reusability and maintainability.
| const response = await transportFetch<{ | |
| items?: T[]; | |
| total?: number; | |
| hasMore?: boolean; | |
| nextCursor?: string; | |
| }>({ | |
| const response = await transportFetch<ListResponse<T>>({ |
feat(kernel): Implement transport layer + field filtering (A3 + A5)
Overview
This PR completes Sprint 1 Task A3 (Transport Layer) and Sprint 1 Task A5 (Field Filtering), building on the cache invalidation work from PR #19.
What's New
🚀 Transport Layer (A3)
Added a production-ready transport wrapper around
@wordpress/api-fetch:req_{timestamp}_{random})wpk.resource.request,wpk.resource.response,wpk.resource.errorKernelErrorsanytypes📋 Field Filtering (A5)
Implemented
_fieldsparameter support for REST API optimization:🔌 Resource Client Methods
Wired up the resource client methods to use the transport layer:
list(): Fetches collections with query params and field filteringget(): Fetches single items with path interpolationNotImplementedError🧪 Comprehensive Testing
Added 21 transport tests covering:
_fieldshandling📦 Import Standardization
Updated all test files to use
@kernel/aliases instead of relative imports for consistency.Test Results
✅ All 254 tests passing
✅ 94.94% code coverage (target: >60%)
✅ TypeScript compilation clean
✅ ESLint passes with no errors
Files Changed
New Files
packages/kernel/src/transport/types.ts- Transport interfaces and typespackages/kernel/src/transport/fetch.ts- Transport implementationpackages/kernel/src/transport/__tests__/fetch.test.ts- Transport testsModified Files
packages/kernel/package.json- Added@wordpress/api-fetchpeer dependencypackages/kernel/src/index.ts- Exported transport types and functionspackages/kernel/src/resource/defineResource.ts- Wired uplist()andget()@kernel/aliasesDependencies
Added peer dependency:
@wordpress/api-fetch(>=7.0.0)Breaking Changes
None. This is purely additive functionality.
Next Steps
With A3 and A5 complete, the next priorities are:
Related