createFeature
Packs providers into a named bag that any module can take as a single entry. What a feature is for is on Providers & Resolution; this page is the API surface.
Signature
createFeature(input: { name?: string; providers: readonly ProviderInput[] }): Feature
declare const FEATURE: unique symbol
type Feature = {
readonly [FEATURE]: true
readonly name?: string
readonly providers: readonly ProviderInput[]
}ProviderInput is a provider or another feature. The FEATURE brand is how a providers array tells the two apart; you never write it, and createFeature is the only way to make one.
import { createFeature, createModuleComponent } from "@remodulo/react"
const ordersDataFeature = createFeature({
name: "orders-data",
providers: [OrdersApi, OrdersStore],
})
const ordersFeature = createFeature({
name: "orders",
providers: [ordersDataFeature, OrdersPresenter],
})
const OrdersModule = createModuleComponent({ providers: [ordersDataFeature, ordersFeature] })OrdersModule registers three providers, not five: ordersDataFeature is included directly and again through ordersFeature, and the two occurrences flatten to one.
name
Optional, and a label only - nothing resolves by it. Leaving it off omits the key entirely rather than setting it to undefined.
providers
Copied and frozen, as is the feature itself. Mutating the array you passed in afterwards changes nothing.
Flattening
Features are flattened where the module is constructed. The container is handed the contents, never the bag, so a feature is never a scope and costs nothing at resolution.
The same feature twice flattens to one copy. Deduplication is by instance: the exact object createFeature returned. Two features built from an identical providers array are two instances, so both register - and a token registered twice in single mode throws:
Token OrdersApi is already registered on this container. One token, one registration - mark every provider for it `multi: true` to make it a collection, or give each provider its own token.A feature owns nothing. The module its providers land in is the owner, so the same feature dropped into two modules gives two independent sets of instances, each disposed by its own module.
Order is depth-first, in declaration order. Registration order is the order the flattened list came out in, which is what decides eager construction order at init.