Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More →
@openfeature/web-sdk
Advanced tools
@openfeature/web-sdk - npm Package Compare versions
Comparing version 0.3.3-experimental to 0.3.4-experimental
| { | ||
| "name": "@openfeature/web-sdk", | ||
| "version": "0.3.3-experimental", | ||
| "version": "0.3.4-experimental", | ||
| "description": "OpenFeature SDK for Web", | ||
@@ -5,0 +5,0 @@ "main": "./dist/cjs/index.js", |
@@ -14,3 +14,3 @@ <!-- markdownlint-disable MD033 --> | ||
| [](https://www.npmjs.com/package/@openfeature/web-sdk) | ||
| [](https://github.com/open-feature/spec/tree/v0.5.2) | ||
| [](https://github.com/open-feature/spec/tree/v0.6.0) | ||
@@ -26,7 +26,10 @@ ## 🧪 This SDK is experimental | ||
| [OpenFeature][openfeature-website] is an open standard that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool. | ||
| [OpenFeature][openfeature-website] is an open standard that provides a vendor-agnostic, community-driven API for feature | ||
| flagging that works with your favorite feature flag management tool. | ||
| ### Why standardize feature flags? | ||
| Standardizing feature flags unifies tools and vendors behind a common interface which avoids vendor lock-in at the code level. Additionally, it offers a framework for building extensions and integrations and allows providers to focus on their unique value proposition. | ||
| Standardizing feature flags unifies tools and vendors behind a common interface which avoids vendor lock-in at the code | ||
| level. Additionally, it offers a framework for building extensions and integrations and allows providers to focus on | ||
| their unique value proposition. | ||
@@ -77,3 +80,4 @@ ## 🔍 Requirements: | ||
| Sometimes the value of a flag must take into account some dynamic criteria about the application or user, such as the user location, IP, email address, or the location of the server. | ||
| Sometimes the value of a flag must take into account some dynamic criteria about the application or user, such as the | ||
| user location, IP, email address, or the location of the server. | ||
| In OpenFeature, we refer to this as [`targeting`](https://openfeature.dev/specification/glossary#targeting). | ||
@@ -92,3 +96,6 @@ If the flag system you're using supports targeting, you can provide the input data using the `EvaluationContext`. | ||
| To develop a provider, you need to create a new project and include the OpenFeature SDK as a dependency. This can be a new repository or included in an existing contrib repository available under the OpenFeature organization. Finally, you’ll then need to write the provider itself. In most languages, this can be accomplished by implementing the provider interface exported by the OpenFeature SDK. | ||
| To develop a provider, you need to create a new project and include the OpenFeature SDK as a dependency. This can be a | ||
| new repository or included in an existing contrib repository available under the OpenFeature organization. Finally, | ||
| you’ll then need to write the provider itself. In most languages, this can be accomplished by implementing the provider | ||
| interface exported by the OpenFeature SDK. | ||
@@ -101,3 +108,3 @@ ```typescript | ||
| readonly metadata = { | ||
| name: 'My Provider', | ||
| name: 'My Provider' | ||
| } as const; | ||
@@ -126,3 +133,5 @@ | ||
| Hooks are a mechanism that allow for the addition of arbitrary behavior at well-defined points of the flag evaluation life-cycle. Use cases include validation of the resolved flag value, modifying or adding data to the evaluation context, logging, telemetry, and tracking. | ||
| Hooks are a mechanism that allow for the addition of arbitrary behavior at well-defined points of the flag evaluation | ||
| life-cycle. Use cases include validation of the resolved flag value, modifying or adding data to the evaluation context, | ||
| logging, telemetry, and tracking. | ||
@@ -145,3 +154,4 @@ ```typescript | ||
| You can implement the `Logger` interface (compatible with the `console` object, and implementations from common logging libraries such as [winston](https://www.npmjs.com/package/winston)) and set it on the global API object. | ||
| You can implement the `Logger` interface (compatible with the `console` object, and implementations from common logging | ||
| libraries such as [winston](https://www.npmjs.com/package/winston)) and set it on the global API object. | ||
@@ -154,8 +164,11 @@ ```typescript | ||
| } | ||
| warn(...args: unknown[]): void { | ||
| // implement me | ||
| } | ||
| info(...args: unknown[]): void { | ||
| // implement me | ||
| } | ||
| debug(...args: unknown[]): void { | ||
@@ -170,2 +183,60 @@ // implement me | ||
| ### Named clients: | ||
| You can have several clients, that can be referenced by a name. | ||
| Every client can have a different provider assigned. If no provider is assigned to a named client, the global default | ||
| provider is used. | ||
| ```typescript | ||
| import { OpenFeature, ProviderEvents } from '@openfeature/web-sdk'; | ||
| OpenFeature.setProvider(new YourProviderOfChoice()) | ||
| OpenFeature.setProvider("client-1", new YourOtherProviderOfChoice()) | ||
| // Uses YourProviderOfChoice (the default) | ||
| const unnamedClient = OpenFeature.getClient() | ||
| // Uses YourOtherProviderOfChoice as it is set explicitly | ||
| const client1 = OpenFeature.getClient("client-1") | ||
| // Uses YourProviderOfChoice as no provider is set | ||
| const client2 = OpenFeature.getClient("client-2") | ||
| ``` | ||
| ### Events: | ||
| Events provide a way to react to state changes in the provider or underlying flag management system. | ||
| You can listen to events of either the OpenFeature API or individual clients. | ||
| The events after initialization, `PROVIDER_READY` on success, `PROVIDER_ERROR` on failure during initialization, | ||
| are dispatched for every provider. | ||
| However, other event types may not be supported by your provider. | ||
| Please refer to the documentation of the provider you're using to see what events are supported. | ||
| ```typescript | ||
| import { OpenFeature, ProviderEvents } from '@openfeature/web-sdk'; | ||
| // OpenFeature API | ||
| OpenFeature.addHandler(ProviderEvents.Ready, (eventDetails) => { | ||
| console.log(`Ready event from: ${eventDetails.clientName}:`, eventDetails); | ||
| }); | ||
| // Specific client | ||
| const client = OpenFeature.getClient(); | ||
| client.addHandler(ProviderEvents.Error, async (eventDetails) => { | ||
| console.log(`Error event from: ${eventDetails.clientName}:`, eventDetails); | ||
| }); | ||
| ``` | ||
| ### Shutdown: | ||
| The OpenFeature API provides a close function to perform a cleanup of all registered providers. | ||
| This should only be called when your application is in the process of shutting down. | ||
| ```typescript | ||
| import { OpenFeature, ProviderEvents } from '@openfeature/web-sdk'; | ||
| await OpenFeature.close() | ||
| ``` | ||
| ### Complete API documentation: | ||
@@ -172,0 +243,0 @@ |
New alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Fixed alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Improved metrics
- Total package byte prevSize
- increased by0.69%
292411
- Number of lines in readme file
- increased by42.51%
238
No dependency changes