↑ Usage Guide Index | ← Core API OVERVIEW
m7Fetch is designed to be extended — both through subclassing core classes and by injecting or replacing modules at runtime. The architecture avoids locking behavior behind private symbols, so developers can adjust defaults, add methods, or override core logic as needed.
-
HTTP
- Override
FETCH_DEFAULTSto set organization-wide fetch options. - Override methods like
parseOpts,buildDefaultFetchOpts, orbuildBasefor URL resolution rules.
- Override
-
SpecManager
- Extend to support new spec formats or alternate
call()dispatch logic.
- Extend to support new spec formats or alternate
-
BatchLoader / SyncLoader
- Subclass to add instrumentation, telemetry hooks, or alternate handler policies.
Example:
import HTTP from 'm7fetch/core/HTTP.js';
class MyHTTP extends HTTP {
static FETCH_DEFAULTS = {
mode: 'same-origin',
credentials: 'include'
};
}BatchLoader accepts batch in constructor opts:
- Pass your own
(obj, id, handler, ...extra)to change success/failure marking or result storage. - Built-in:
batchStatus,batchStore,batchNone.
- AutoLoader + Modules system allows new loader types — e.g., remote ES modules, WASM packages.
- Register your own loader or resolver via subclassed
Modulesmanager.
- All core calls accept
optsobjects merged with defaults. - This makes it easy to add flags like
trace: trueorretry: 3and consume them in an overridden method.
- Decorator Pattern: Wrap existing class instances to intercept calls without subclassing.
- Adapter Pattern: Provide alternate implementations of HTTP or SpecManager with the same method signatures.
- Plugin Approach: Supply loader functions, batch handlers, or spec parsers at runtime.
- Avoid mutating shared singletons in long-running apps — prefer instance-specific overrides.
- If overriding network behavior, validate against
FETCH_CONSTANTSto maintain compatibility. - Extending beyond documented APIs may require revisiting after major version updates.