-
Notifications
You must be signed in to change notification settings - Fork 10
Switch to Reflag naming #463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Replaced occurrences of "Bucket" with "Reflag" in various files, including README, config files, and example applications. - Updated the .gitignore to exclude reflag.config.json instead of bucket.config.json. - Adjusted documentation and comments to reflect the new naming convention. - Ensured consistency in naming across SDKs and examples to align with the rebranding effort.
…base URL - Changed the configuration file name from "bucket.config.json" to "reflag.config.json" to align with the rebranding effort. - Updated the environment variable from "REFLAG_HOST" to "REFLAG_API_BASE_URL" for better clarity and consistency in the SDK.
- Updated README and example files to replace "feature" terminology with "flag" for consistency. - Adjusted code comments and variable names to reflect the new flag-based approach. - Enhanced the FlagsTable component and related CSS for improved user experience. - Implemented a new FlagCache for efficient flag management and retrieval. - Updated tests to ensure proper functionality with the new flag structure.
…s and types - Changed API endpoint in feedback examples from "tracking.reflag.co" to "tracking.bucket.co" for consistency. - Updated type references in app.ts from RawFeatures to RawFlags to align with the new flag terminology. - Enhanced documentation in client.ts for the requestFeedback method to clarify parameter usage. - Adjusted variable names in various components to reflect the transition from features to flags, ensuring clarity in the codebase.
- Updated test cases in index.test.ts to replace "feature" terminology with "flag" for consistency. - Refactored the implementation in index.ts to change method names and variable references from "feature" to "flag". - Enhanced clarity in the codebase by aligning with the new flag-based approach.
- Renamed the `Feature` interface to `Flag` and updated related types and methods to reflect the new flag-based approach. - Adjusted the `FlagsClient` to handle flag values and overrides consistently. - Updated the `FlagsTable` and `Toolbar` components to use the new flag structure. - Refactored tests to ensure proper functionality with the updated flag terminology. - Enhanced documentation and comments to clarify the transition from features to flags.
- Updated the CLI to register and handle flag commands instead of feature commands. - Introduced a new `flags.ts` file to manage flag-related actions such as creating, listing, and generating types for flags. - Removed the deprecated `features.ts` service file and adjusted related imports accordingly. - Updated the `new` command to create flags instead of features, ensuring consistency with the new flag-based approach.
- Renamed `featureKey` to `flagKey` in `EvaluationParams` and `EvaluationResult` interfaces for consistency with the new flag-based approach. - Updated the `evaluateFeatureRules` function to `evaluateFlagRules` to reflect the terminology change. - Adjusted related comments and documentation to clarify the transition from features to flags. - Ensured that all references in the flag evaluation logic are aligned with the new flag structure.
…tion - Renamed references from "feature" to "flag" in the `index.test.ts` file to maintain consistency with the new flag-based approach. - Updated the `ReflagClient` class methods and properties to reflect the terminology change, ensuring clarity in the flag evaluation logic. - Adjusted related tests to ensure proper functionality with the updated flag structure and terminology. - Enhanced documentation and comments to clarify the transition from features to flags.
- Changed `UntypedFlag` payload type from a union to `any` for flexibility.
- Refactored `Flag` type to use a default type of `{}` instead of `boolean | object | string | number | null`.
- Updated `TypedFlags` and `TypedFeatures` types to reflect the new flag structure.
- Renamed test cases and methods in `client.test.ts` to use `getFlag` and `getFlagDefinitions` for consistency with the flag-based approach.
- Enhanced documentation to clarify the transition from features to flags in the SDK.
- Changed copyright statements in LICENSE and various README files to reflect the new ownership by Bucket ApS. - Updated references in the browser and node SDKs to ensure consistency with the new branding. - Adjusted example files and documentation to align with the updated copyright information.
- Replaced the `Feature` icon component with a new `Flag` component for consistency with the updated flag terminology. - Updated imports in the `Flags.tsx` file to reference the new `Flag` component. - Removed the deprecated `Feature.tsx` file to streamline the codebase. - Adjusted documentation in the React SDK README to reflect changes in flag terminology and usage.
- Replaced instances of `getFeature` with `getFlag` in the README and example files to align with the new flag-based approach. - Updated the `Feedback` component to reference `ExampleFlag` instead of `ExampleFeature`. - Adjusted the `ReflagClient` class to ensure consistent usage of `flagKey` in feedback requests and related methods. - Enhanced documentation to clarify the transition from features to flags, including migration instructions for users moving from the Bucket SDK to the Reflag SDK.
- Renamed `flagKey` to `key` in the feedback form options for consistency. - Refactored the `updateFlags` function in the `Toolbar` component to use `Object.entries` for better readability and updated flag handling. - Simplified the `Logo` component's SVG attributes for improved clarity. - Removed deprecated `getFeature` references in tests and adjusted related logic to align with the new flag-based approach. - Updated mock handlers to reflect the new endpoint structure for user requests.
- Updated `ReflagClient` to replace deprecated feature references with flag terminology, including renaming methods and properties for consistency. - Removed deprecated `featureOverrides` handling and adjusted related logic to focus solely on `flagOverrides`. - Enhanced documentation and comments throughout the codebase to clarify the transition from features to flags. - Updated tests to reflect the new flag-based approach, ensuring proper functionality and alignment with the updated terminology.
Contributor
|
Closing in favour of #465 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.