@evanion/react-feature 0.1.0 → 0.1.2

package/CHANGELOG.md

@@ -1,3 +1,48 @@
+## 0.1.2 (2026-11-07)
+
+### 🚀 Features
+
+- ⚠️  **react-feature:** re-export the 0.2 condition types ([ac261cfa](https://github.com/Evanion/libraries/commit/ac261cfa))
+
+### ⚠️  Breaking Changes
+
+- **react-feature:** re-export the 0.2 condition types  ([ac261cfa](https://github.com/Evanion/libraries/commit/ac261cfa))
+  the re-exported `Condition` gains the `exists` and
+  `not-exists` ops, so an exhaustive switch over `Condition['op']` stops
+  compiling, and `AttributeCondition` and `SerializedAttributeCondition`
+  are unions, so code reading `value` narrows on `op` first.
+  `ContextSchema.fields` keys are paths, and `RuleOutcome.failed.value` is
+  optional.
+
+### 🧱 Updated Dependencies
+
+- Updated @evanion/feature to 0.2.0
+
+### ❤️ Thank You
+
+- Mikael Pettersson @Evanion
+
+## 0.1.1 (2026-11-05)
+
+### 🚀 Features
+
+- **docs:** show a short sample from its own tested region ([68fa945c](https://github.com/Evanion/libraries/commit/68fa945c))
+
+### 📖 Documentation
+
+- **react-feature:** open on the flags living in your repo ([46ee7f90](https://github.com/Evanion/libraries/commit/46ee7f90))
+- **repo:** link the documentation at libs.evanion.com/docs ([dc18dbb2](https://github.com/Evanion/libraries/commit/dc18dbb2))
+- **react-feature:** open the readme on its family's promise ([66d2eefd](https://github.com/Evanion/libraries/commit/66d2eefd))
+- **react-feature:** give the readme gemma's npm landing-page shape ([c7872824](https://github.com/Evanion/libraries/commit/c7872824))
+
+### 🧱 Updated Dependencies
+
+- Updated @evanion/feature to 0.1.1
+
+### ❤️ Thank You
+
+- Mikael Pettersson @Evanion
+
 ## 0.1.0 (2026-10-17)
 
 ### 🚀 Features

package/README.md

@@ -1,31 +1,8 @@
 # @evanion/react-feature
 
-**Feature decisions for your React component tree, resolved once and read anywhere.**
+**Feature flags that live in your repo. Your own code decides if a feature is on—in your API, your build, and the browser—with no network call per check.**
 
-To switch a single banner in a complex UI, you often have to prop-drill a flags object through ten layers of components. `@evanion/react-feature` solves this by publishing the decisions `@evanion/feature` has already resolved. Any component in the tree can ask "is this on, and which variant am I in?" without needing to know where the store or the evaluation context lives.
-
-## The Problem: The "Flags Prop-Drill"
-
-When a server resolves flags for a request, the component that actually needs a specific flag is often buried deep in the hierarchy. This creates two primary frictions:
-
-1. **Prop-Drilling**: Components that do not use any flags are forced to carry the flags object simply because a distant child requires it.
-2. **Two Answers Per Request**: If a component resolves a flag for itself, it reads its own clock. This means two components in a single render could land on opposite sides of a time window, causing the page to contradict itself.
-
-## The Solution: One Resolution, Published
-
-`@evanion/feature` resolves every configured feature in one call, and `features.snapshot` states that result as a `DecisionSet` containing the instant of resolution, one decision per key, and the config version wherever the store was built from a document that carries one.
-
-`FeatureProvider` publishes that set to the React tree, allowing `useFeature`, `useFeatureEnabled`, `useVariant`, and `useFeatures` to read it. Because the decisions are already made, no hook evaluates anything during the render.
-
-### Core Concept: The Server Resolves, The Tree Reads
-
-To avoid duplicating complex logic in the UI, `@evanion/react-feature` separates the act of deciding which feature to show from the act of reading that decision.
-
-Consider a game shop that splits shoppers between two different shelf-sorting methods. Instead of the UI calculating the split, the server resolves it for a specific shopper via `features.snapshot`, and `FeatureProvider` publishes that set. The `Shelf` component then simply reads its assigned variant. If Sam buckets into `popular` and Mika into `newest`, neither component has to perform the resolution logic themselves.
-
-To ensure consistency, the provider takes the shopper's targeting context alongside the set. It publishes the shipped decisions either way, and it re-resolves them against that context to check them; consequently, a provider handed no `targetingKey` reports every weighted assignment as one it cannot reproduce. The context the server resolved with is the context the provider needs.
-
-The following block runs in the package's test suite, where each `// ->` comment denotes the expression's value.
+`@evanion/react-feature` is the React adapter for this ecosystem. It allows you to publish the decisions `@evanion/feature` has already resolved to your component tree, enabling any component to ask "is this on, and which variant am I in?" without prop-drilling a flags object through multiple layers of UI.
 
 <!-- #region server-render -->
 
@@ -118,16 +95,16 @@ shelfFor('mika'); // -> '<p>Newest first</p>'
 
 <!-- #endregion server-render -->
 
-## Key Features
+## Capabilities
 
 `@evanion/react-feature` provides the following capabilities:
 
-- 🧩 **Zero Prop-Drilling**: Components name the key they care about and read the decision from the provider above them.
-- 🕓 **One Instant Per Render**: A set a render resolved states the instant it was created. The provider reads that instant as the default for anything it resolves itself, ensuring no two components in one tree straddle a time window.
-- ⚡ **Local Reads**: Hooks read decisions already held by the provider, so variant switches never wait on network requests.
-- 🛠️ **Type-Safety**: `createFeatureContext(features)` returns a provider and hooks bound to one store's schema. Misspelled keys trigger compile errors, and variants are constrained to the union declared by the store.
-- 🧬 **Divergence Reports**: When handed a shipped set, a provider compares the config version against the store. It names decisions it cannot reproduce via `onDivergence`. Where the set and the store each carry a config version and the two differ, `onVersionMismatch` decides whether the tree renders the shipped set or a local re-resolution. A store built from a bare definitions array carries no version, so a provider over one reports `unversioned` and keeps the shipped set whatever `onVersionMismatch` asks for. Build both sides from a document that carries a version to make the choice available.
-- 📦 **Lightweight Footprint**: The package is ESM only and requires Node 20 or newer. Its only peer dependency is React 18 or 19, with `@evanion/feature` pinned as a dependency.
+- **Zero Prop-Drilling**: Components name the key they care about and read the decision from the provider above them.
+- **One Instant Per Render**: A set a render resolved states the instant it was created. The provider reads that instant as the default for anything it resolves itself, ensuring no two components in one tree straddle a time window.
+- **Local Reads**: Hooks read decisions already held by the provider, so variant switches never wait on network requests.
+- **Type-Safety**: `createFeatureContext(features)` returns a provider and hooks bound to one store's schema. Misspelled keys trigger compile errors, and variants are constrained to the union declared by the store.
+- **Divergence Reports**: When handed a shipped set, a provider compares the config version against the store. It names decisions it cannot reproduce via `onDivergence`. Where the set and the store each carry a config version and the two differ, `onVersionMismatch` decides whether the tree renders the shipped set or a local re-resolution. A store built from a bare definitions array carries no version, so a provider over one reports `unversioned` and keeps the shipped set whatever `onVersionMismatch` asks for. Build both sides from a document that carries a version to make the choice available.
+- **Lightweight Footprint**: The package is ESM only and requires Node 20 or newer. Its only peer dependency is React 18 or 19, with `@evanion/feature` pinned as a dependency.
 
 ## Installation
 
@@ -141,11 +118,11 @@ npm install @evanion/react-feature @evanion/feature
 
 To master the implementation and explore worked examples, visit the full documentation site:
 
-👉 **[docs.evanion.com/react-feature](https://docs.evanion.com/react-feature/)**
+👉 **[libs.evanion.com/docs/react-feature](https://libs.evanion.com/docs/react-feature/)**
 
 The `@evanion/react-feature` hooks operate by reading a shared model of features, rules, variants, and decision sets. Because this model is defined in the core package, its detailed documentation is located here:
 
-👉 **[docs.evanion.com/feature](https://docs.evanion.com/feature/)**
+👉 **[libs.evanion.com/docs/feature](https://libs.evanion.com/docs/feature/)**
 
 ## License
 

package/dist/index.js

@@ -2,7 +2,7 @@
 import { createContext as e, useContext as t, useMemo as n, useState as r } from "react";
 import { adoptDecisions as i, reportDivergence as a } from "@evanion/feature";
 import { jsx as o } from "react/jsx-runtime";
-//#region src/hydrate.ts
+// src/hydrate.ts
 function s() {
 	try {
 		return process.env.NODE_ENV === "production";
@@ -10,8 +10,7 @@ function s() {
 		return !0;
 	}
 }
-//#endregion
-//#region src/index.tsx
+// src/index.tsx
 function c(e) {
 	return e;
 }
@@ -114,5 +113,4 @@ function S(t) {
 		}
 	};
 }
-//#endregion
 export { h as FeatureProvider, S as createFeatureContext, _ as useFeature, v as useFeatureEnabled, g as useFeatures, y as useVariant };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evanion/react-feature",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "description": "The React binding for @evanion/feature: a provider and hooks over an already-built feature store.",
   "keywords": [
     "react",
@@ -54,7 +54,7 @@
     "provenance": true
   },
   "dependencies": {
-    "@evanion/feature": "0.1.0"
+    "@evanion/feature": "0.2.0"
   },
   "peerDependencies": {
     "react": "^18.0.0 || ^19.0.0"