From 22960522405bf5664b89636dbe1adb72c61fcfed Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 26 Jan 2024 13:03:55 -0300 Subject: [PATCH 01/18] Update CHANGES file and comments to explain breaking changes when migrating from SplitFactory to SplitFactoryProvider --- CHANGES.txt | 11 ++++++++--- src/SplitFactory.tsx | 14 +++++++++++--- src/withSplitFactory.tsx | 16 ++++++++++++---- 3 files changed, 31 insertions(+), 10 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 3ece218..4af1bfb 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,7 +1,12 @@ 1.11.0 (January 16, 2023) - - Added the new `SplitFactoryProvider` component as a replacement for the now deprecated `SplitFactory` component. - The new component is a revised version of `SplitFactory`, addressing improper handling of the SDK initialization side-effects in the `componentDidMount` and `componentDidUpdate` methods (commit phase), causing some issues like memory leaks and the SDK not reinitializing when component props change (Related to issue #11 and #148). - The `SplitFactoryProvider` component can be used as a drop-in replacement for `SplitFactory`. It utilizes the React Hooks API, that requires React 16.8.0 or later, and supports server-side rendering. See our documentation for more details (Related to issue #11 and #109). + - Added new `SplitFactoryProvider` component as a replacement for the now deprecated `SplitFactory` component. + - The `SplitFactoryProvider` component, a drop-in replacement for `SplitFactory`, supports server-side rendering (Related to issues #11 and #109). For more details, see our documentation. + - Bugfixing - The new component is a revised version of `SplitFactory` that addresses improper handling of SDK initialization side-effects in the `componentDidMount` and `componentDidUpdate` methods (commit phase), resolving memory leak issues on server-side, React development and strict modes. It also ensures the SDK is updated when component props change (Related to issues #11 and #148). + - BREAKING CHANGES when migrating from `SplitFactory` to `SplitFactoryProvider`: + - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. + - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. + - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. Pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance to avoid unnecessary reinitialization. + - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. - Updated internal code to remove a circular dependency and avoid warning messages with tools like PNPM (Related to issue #176). - Updated @splitsoftware/splitio package to version 10.25.1 for vulnerability fixes. diff --git a/src/SplitFactory.tsx b/src/SplitFactory.tsx index 74d9236..c753f9d 100644 --- a/src/SplitFactory.tsx +++ b/src/SplitFactory.tsx @@ -15,9 +15,17 @@ import { DEFAULT_UPDATE_OPTIONS } from './useSplitClient'; * even if the component is updated with a different config or factory prop. * * @deprecated Replace with the new `SplitFactoryProvider` component. - * `SplitFactoryProvider` is a drop-in replacement that properly handles side effects (factory creation and destruction) within the React component lifecycle, avoiding issues with factory recreation and memory leaks. - * Note: There is a subtle breaking change in `SplitFactoryProvider`. When using the `config` prop, `factory` and `client` properties in the context are `null` in the first render, until the context is updated when some event is emitted on - * the SDK main client (ready, ready from cache, timeout or update depending on the configuration of the `updateOnXXX` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. + * `SplitFactoryProvider` is a drop-in replacement that properly handles side effects (factory creation and destruction) within + * the React component lifecycle, resolving memory leak issues on server-side, React development and strict modes. + * + * BREAKING CHANGES to consider when migrating: + * - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. + * - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until + * the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration + * of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. + * - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. + * Pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance to avoid unnecessary reinitialization. + * - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. * * @see {@link https://help.split.io/hc/en-us/articles/360038825091-React-SDK#2-instantiate-the-sdk-and-create-a-new-split-client} */ diff --git a/src/withSplitFactory.tsx b/src/withSplitFactory.tsx index 45eb55f..6891cbd 100644 --- a/src/withSplitFactory.tsx +++ b/src/withSplitFactory.tsx @@ -10,10 +10,18 @@ import { SplitFactory } from './SplitFactory'; * @param config Config object used to instantiate a Split factory * @param factory Split factory instance to use instead of creating a new one with the config object. * - * @deprecated Use `SplitFactoryProvider` instead. - * `SplitFactoryProvider` is a drop-in replacement of `SplitFactory` that properly handles side effects (factory creation and destruction) within the React component lifecycle, avoiding issues with factory recreation and memory leaks. - * Note: There is a subtle breaking change in `SplitFactoryProvider`. When using the `config` prop, `factory` and `client` properties in the context are `null` in the first render, until the context is updated when some event is emitted on - * the SDK main client (ready, ready from cache, timeout or update depending on the configuration of the `updateOnXXX` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. + * @deprecated Replace with the new `SplitFactoryProvider` component. + * `SplitFactoryProvider` is a drop-in replacement of `SplitFactory` that properly handles side effects (factory creation and destruction) within + * the React component lifecycle, resolving memory leak issues on server-side, React development and strict modes. + * + * BREAKING CHANGES to consider when migrating: + * - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. + * - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until + * the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration + * of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. + * - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. + * Pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance to avoid unnecessary reinitialization. + * - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. */ export function withSplitFactory(config?: SplitIO.IBrowserSettings, factory?: SplitIO.IBrowserSDK, attributes?: SplitIO.Attributes) { From c1803cad36857d72b11242210becbce1fbb32175 Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 26 Jan 2024 13:28:30 -0300 Subject: [PATCH 02/18] Update comment regarding factory and config props in SplitFactoryProvider --- src/SplitFactoryProvider.tsx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/SplitFactoryProvider.tsx b/src/SplitFactoryProvider.tsx index 5f91df7..01e09f3 100644 --- a/src/SplitFactoryProvider.tsx +++ b/src/SplitFactoryProvider.tsx @@ -11,8 +11,8 @@ import { DEFAULT_UPDATE_OPTIONS } from './useSplitClient'; * and automatically destroy the SDK (shutdown and release resources) when it is unmounted or `config` prop updated. SplitFactoryProvider must wrap other library components and * functions since they access the Split Context and its properties (factory, client, isReady, etc). * - * NOTE: Either pass a factory instance or a config object. If both are passed, the config object will be ignored. - * Pass the same reference to the config or factory object rather than a new instance on each render, to avoid unnecessary props changes and SDK reinitializations. + * NOTE: Either pass a `factory` instance or a `config` object as props. If both props are passed, the `config` prop will be ignored. + * Pass the same reference to the `config` or `factory` object rather than a new instance on each render, to avoid unnecessary props changes and SDK reinitializations. * * @see {@link https://help.split.io/hc/en-us/articles/360038825091-React-SDK#2-instantiate-the-sdk-and-create-a-new-split-client} */ From 6105b3f886dc27fb80d30733dbcd63e2d8b0e31f Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Tue, 30 Jan 2024 13:40:02 -0300 Subject: [PATCH 03/18] Nico's feedback: 'Notable changes' rather than 'Breaking changes' --- CHANGES.txt | 9 +++++---- src/SplitFactory.tsx | 10 +++++----- src/withSplitFactory.tsx | 10 +++++----- 3 files changed, 15 insertions(+), 14 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 4af1bfb..2f33acf 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,11 +1,12 @@ 1.11.0 (January 16, 2023) - Added new `SplitFactoryProvider` component as a replacement for the now deprecated `SplitFactory` component. - - The `SplitFactoryProvider` component, a drop-in replacement for `SplitFactory`, supports server-side rendering (Related to issues #11 and #109). For more details, see our documentation. - - Bugfixing - The new component is a revised version of `SplitFactory` that addresses improper handling of SDK initialization side-effects in the `componentDidMount` and `componentDidUpdate` methods (commit phase), resolving memory leak issues on server-side, React development and strict modes. It also ensures the SDK is updated when component props change (Related to issues #11 and #148). - - BREAKING CHANGES when migrating from `SplitFactory` to `SplitFactoryProvider`: + - Bugfixing: The new component is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, + - resolving memory leak issues in React development mode, strict mode and server-side rendering (Related to issues #11 and #109), + - and also ensuring that the SDK is updated if `config` or `factory` props change (Related to issues #11 and #148). + - Notable changes when migrating from `SplitFactory` to `SplitFactoryProvider`: - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. - - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. Pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance to avoid unnecessary reinitialization. + - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. It is recommended to pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. - Updated internal code to remove a circular dependency and avoid warning messages with tools like PNPM (Related to issue #176). - Updated @splitsoftware/splitio package to version 10.25.1 for vulnerability fixes. diff --git a/src/SplitFactory.tsx b/src/SplitFactory.tsx index c753f9d..95ea953 100644 --- a/src/SplitFactory.tsx +++ b/src/SplitFactory.tsx @@ -15,16 +15,16 @@ import { DEFAULT_UPDATE_OPTIONS } from './useSplitClient'; * even if the component is updated with a different config or factory prop. * * @deprecated Replace with the new `SplitFactoryProvider` component. - * `SplitFactoryProvider` is a drop-in replacement that properly handles side effects (factory creation and destruction) within - * the React component lifecycle, resolving memory leak issues on server-side, React development and strict modes. + * `SplitFactoryProvider` is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, + * resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. * - * BREAKING CHANGES to consider when migrating: + * Notable changes to consider when migrating: * - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. * - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until * the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration * of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. - * - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. - * Pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance to avoid unnecessary reinitialization. + * - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. It is recommended to + * pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. * - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. * * @see {@link https://help.split.io/hc/en-us/articles/360038825091-React-SDK#2-instantiate-the-sdk-and-create-a-new-split-client} diff --git a/src/withSplitFactory.tsx b/src/withSplitFactory.tsx index 6891cbd..b838358 100644 --- a/src/withSplitFactory.tsx +++ b/src/withSplitFactory.tsx @@ -11,16 +11,16 @@ import { SplitFactory } from './SplitFactory'; * @param factory Split factory instance to use instead of creating a new one with the config object. * * @deprecated Replace with the new `SplitFactoryProvider` component. - * `SplitFactoryProvider` is a drop-in replacement of `SplitFactory` that properly handles side effects (factory creation and destruction) within - * the React component lifecycle, resolving memory leak issues on server-side, React development and strict modes. + * `SplitFactoryProvider` is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, + * resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. * - * BREAKING CHANGES to consider when migrating: + * Notable changes to consider when migrating: * - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. * - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until * the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration * of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. - * - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. - * Pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance to avoid unnecessary reinitialization. + * - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. It is recommended to + * pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. * - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. */ export function withSplitFactory(config?: SplitIO.IBrowserSettings, factory?: SplitIO.IBrowserSDK, attributes?: SplitIO.Attributes) { From 11e01ae222b02f5c10905eb7c408d7457dda11bc Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Tue, 30 Jan 2024 18:26:24 -0300 Subject: [PATCH 04/18] Team's feedback: add MIGRATION-GUIDE.md file --- MIGRATION-GUIDE.md | 84 ++++++++++++++++++++++++++++++++++++++++ package.json | 1 + src/SplitFactory.tsx | 3 +- src/withSplitFactory.tsx | 3 +- 4 files changed, 89 insertions(+), 2 deletions(-) create mode 100644 MIGRATION-GUIDE.md diff --git a/MIGRATION-GUIDE.md b/MIGRATION-GUIDE.md new file mode 100644 index 0000000..0d51c20 --- /dev/null +++ b/MIGRATION-GUIDE.md @@ -0,0 +1,84 @@ +# React SDK v1.11.0: replace deprecated components with the new `SplitFactoryProvider` component + +The `SplitFactory` and `withSplitFactory` components have been deprecated since React SDK v1.11.0, and will be removed on a future major release. + +We recommend migrating to the new `SplitFactoryProvider` component instead. This component is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. + +Notable changes to consider when migrating: + - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. + + - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. Nonetheless, it is not recommended to use the `client` and `factory` properties directly as better alternatives are available. For example, use the `useTrack` and `useSplitTreatments` hooks rather than the client's `track` and `getTreatments` methods. + + - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. It is recommended to pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. + + - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. + +# React SDK v1.10.0: replace deprecated hooks with new ones + +The `useClient`, `useTreatments` and `useManager` hooks have been deprecated since React SDK v1.10.0, and will be removed on a future major release. + +We recommend migrating to the new versions `useSplitClient`, `useSplitTreatments` and `useSplitManager` respectively, which provide a more flexible API: + +- They accept extra optional parameters, `updateOnSdkReady`, `updateOnSdkReadyFromCache`, `updateOnSdkTimedout` and `updateOnSdkUpdate`, which enable to control when the hook updates the component. For example, you can set `updateOnSdkReady` to `true`, which is `false` by default, to update the component when an `SDK_UPDATE` event is emitted. This is useful when you want to avoid unnecessary re-renders of your components. + +- They return an object containing the SDK status properties. These properties are described in the ['Subscribe to events and changes' section](https://help.split.io/hc/en-us/articles/360038825091-React-SDK#subscribe-to-events-and-changes) and enable conditional rendering of components based on the SDK status, eliminating the need to access the Split context or using the client's `ready` promise or event listeners. For example, you can show a loading spinner while the SDK is not ready, and use the `treatments` result to render the variants of your App once the SDK is ready. + +```js +const { client, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitClient(); +const { treatments, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitTreatments({ names: ['feature-flag-1'] }); +const { manager, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitManager(); +``` + + + +To refactor your existing code, replace: + +```javascript +const client = useClient(optionalSplitKey, optionalTrafficType, optionalAttributes); +const treatments = useTreatments(featureFlagNames, optionalAttributes, optionalSplitKey); +const manager = useManager(); +``` + +with: + +```javascript +const { client } = useSplitClient({ splitKey: optionalSplitKey, trafficType: optionalTrafficType, attributes: optionalAttributes }); +const { treatments } = useSplitTreatments({ names: featureFlagNames, attributes: optionalAttributes, splitKey: optionalSplitKey }); +const { manager } = useSplitManager(); +``` + +and use the status properties to conditionally render your components. For example, do: + +```javascript +const MyComponent = ({ userId }) => { + + const { treatments, isReady } = useSplitTreatments({ names: [FEATURE_X], splitKey: userId }) + + return isReady ? + treatments[FEATURE_X].treatment === 'on' ? + : + : + +} +``` + +instead of: + +```javascript +const MyComponent = ({ userId }) => { + + const [sdkIsReady, setSdkIsReady] = useState(false); + const client = useClient(userId); + const treatments = useTreatments([FEATURE_X], undefined, userId); + + useEffect(() => { + if (client) client.ready().then(() => setSdkIsReady(true)); + }, [client]); + + return isReady ? + treatments[FEATURE_X].treatment === 'on' ? + : + : + +} +``` diff --git a/package.json b/package.json index 9085bdd..e12faf4 100644 --- a/package.json +++ b/package.json @@ -8,6 +8,7 @@ "files": [ "README.md", "CONTRIBUTORS-GUIDE.md", + "MIGRATION-GUIDE.md", "LICENSE", "CHANGES.txt", "src", diff --git a/src/SplitFactory.tsx b/src/SplitFactory.tsx index 95ea953..1065821 100644 --- a/src/SplitFactory.tsx +++ b/src/SplitFactory.tsx @@ -14,7 +14,8 @@ import { DEFAULT_UPDATE_OPTIONS } from './useSplitClient'; * The underlying SDK factory and client is set on the constructor, and cannot be changed during the component lifecycle, * even if the component is updated with a different config or factory prop. * - * @deprecated Replace with the new `SplitFactoryProvider` component. + * @deprecated `SplitFactory` will be removed in a future major release. We recommend replacing it with the new `SplitFactoryProvider` component. + * * `SplitFactoryProvider` is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, * resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. * diff --git a/src/withSplitFactory.tsx b/src/withSplitFactory.tsx index b838358..c352ac0 100644 --- a/src/withSplitFactory.tsx +++ b/src/withSplitFactory.tsx @@ -10,7 +10,8 @@ import { SplitFactory } from './SplitFactory'; * @param config Config object used to instantiate a Split factory * @param factory Split factory instance to use instead of creating a new one with the config object. * - * @deprecated Replace with the new `SplitFactoryProvider` component. + * @deprecated `withSplitFactory` will be removed in a future major release. We recommend replacing it with the new `SplitFactoryProvider` component. + * * `SplitFactoryProvider` is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, * resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. * From 4d88095cdc670b5967500a2065cd9dfa38dbc665 Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Wed, 31 Jan 2024 11:50:19 -0300 Subject: [PATCH 05/18] Team's feedback: add MIGRATION-GUIDE.md file --- MIGRATION-GUIDE.md | 84 ++++++++++++++++++++++++++++++++++++++++++++++ package.json | 1 + 2 files changed, 85 insertions(+) create mode 100644 MIGRATION-GUIDE.md diff --git a/MIGRATION-GUIDE.md b/MIGRATION-GUIDE.md new file mode 100644 index 0000000..0d51c20 --- /dev/null +++ b/MIGRATION-GUIDE.md @@ -0,0 +1,84 @@ +# React SDK v1.11.0: replace deprecated components with the new `SplitFactoryProvider` component + +The `SplitFactory` and `withSplitFactory` components have been deprecated since React SDK v1.11.0, and will be removed on a future major release. + +We recommend migrating to the new `SplitFactoryProvider` component instead. This component is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. + +Notable changes to consider when migrating: + - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. + + - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. Nonetheless, it is not recommended to use the `client` and `factory` properties directly as better alternatives are available. For example, use the `useTrack` and `useSplitTreatments` hooks rather than the client's `track` and `getTreatments` methods. + + - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. It is recommended to pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. + + - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. + +# React SDK v1.10.0: replace deprecated hooks with new ones + +The `useClient`, `useTreatments` and `useManager` hooks have been deprecated since React SDK v1.10.0, and will be removed on a future major release. + +We recommend migrating to the new versions `useSplitClient`, `useSplitTreatments` and `useSplitManager` respectively, which provide a more flexible API: + +- They accept extra optional parameters, `updateOnSdkReady`, `updateOnSdkReadyFromCache`, `updateOnSdkTimedout` and `updateOnSdkUpdate`, which enable to control when the hook updates the component. For example, you can set `updateOnSdkReady` to `true`, which is `false` by default, to update the component when an `SDK_UPDATE` event is emitted. This is useful when you want to avoid unnecessary re-renders of your components. + +- They return an object containing the SDK status properties. These properties are described in the ['Subscribe to events and changes' section](https://help.split.io/hc/en-us/articles/360038825091-React-SDK#subscribe-to-events-and-changes) and enable conditional rendering of components based on the SDK status, eliminating the need to access the Split context or using the client's `ready` promise or event listeners. For example, you can show a loading spinner while the SDK is not ready, and use the `treatments` result to render the variants of your App once the SDK is ready. + +```js +const { client, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitClient(); +const { treatments, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitTreatments({ names: ['feature-flag-1'] }); +const { manager, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitManager(); +``` + + + +To refactor your existing code, replace: + +```javascript +const client = useClient(optionalSplitKey, optionalTrafficType, optionalAttributes); +const treatments = useTreatments(featureFlagNames, optionalAttributes, optionalSplitKey); +const manager = useManager(); +``` + +with: + +```javascript +const { client } = useSplitClient({ splitKey: optionalSplitKey, trafficType: optionalTrafficType, attributes: optionalAttributes }); +const { treatments } = useSplitTreatments({ names: featureFlagNames, attributes: optionalAttributes, splitKey: optionalSplitKey }); +const { manager } = useSplitManager(); +``` + +and use the status properties to conditionally render your components. For example, do: + +```javascript +const MyComponent = ({ userId }) => { + + const { treatments, isReady } = useSplitTreatments({ names: [FEATURE_X], splitKey: userId }) + + return isReady ? + treatments[FEATURE_X].treatment === 'on' ? + : + : + +} +``` + +instead of: + +```javascript +const MyComponent = ({ userId }) => { + + const [sdkIsReady, setSdkIsReady] = useState(false); + const client = useClient(userId); + const treatments = useTreatments([FEATURE_X], undefined, userId); + + useEffect(() => { + if (client) client.ready().then(() => setSdkIsReady(true)); + }, [client]); + + return isReady ? + treatments[FEATURE_X].treatment === 'on' ? + : + : + +} +``` diff --git a/package.json b/package.json index 9085bdd..e12faf4 100644 --- a/package.json +++ b/package.json @@ -8,6 +8,7 @@ "files": [ "README.md", "CONTRIBUTORS-GUIDE.md", + "MIGRATION-GUIDE.md", "LICENSE", "CHANGES.txt", "src", From 50b50282f3a3135209bdcd66ad0f6682fca92d4f Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 2 Feb 2024 11:16:13 -0300 Subject: [PATCH 06/18] Polishing --- CHANGES.txt | 2 +- MIGRATION-GUIDE.md | 2 +- src/SplitFactory.tsx | 2 +- src/withSplitFactory.tsx | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 2f33acf..6495e26 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,6 +1,6 @@ 1.11.0 (January 16, 2023) - Added new `SplitFactoryProvider` component as a replacement for the now deprecated `SplitFactory` component. - - Bugfixing: The new component is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, + - Bugfixing: The new component is a revised version of `SplitFactory` that properly handles SDK side effects (i.e., factory creation and destruction) within the React component lifecycle, - resolving memory leak issues in React development mode, strict mode and server-side rendering (Related to issues #11 and #109), - and also ensuring that the SDK is updated if `config` or `factory` props change (Related to issues #11 and #148). - Notable changes when migrating from `SplitFactory` to `SplitFactoryProvider`: diff --git a/MIGRATION-GUIDE.md b/MIGRATION-GUIDE.md index 0d51c20..5de1c04 100644 --- a/MIGRATION-GUIDE.md +++ b/MIGRATION-GUIDE.md @@ -2,7 +2,7 @@ The `SplitFactory` and `withSplitFactory` components have been deprecated since React SDK v1.11.0, and will be removed on a future major release. -We recommend migrating to the new `SplitFactoryProvider` component instead. This component is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. +We recommend migrating to the new `SplitFactoryProvider` component instead. This component is a revised version of `SplitFactory` that properly handles SDK side effects (i.e., factory creation and destruction) within the React component lifecycle, resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. Notable changes to consider when migrating: - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. diff --git a/src/SplitFactory.tsx b/src/SplitFactory.tsx index 1065821..e78d021 100644 --- a/src/SplitFactory.tsx +++ b/src/SplitFactory.tsx @@ -16,7 +16,7 @@ import { DEFAULT_UPDATE_OPTIONS } from './useSplitClient'; * * @deprecated `SplitFactory` will be removed in a future major release. We recommend replacing it with the new `SplitFactoryProvider` component. * - * `SplitFactoryProvider` is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, + * `SplitFactoryProvider` is a revised version of `SplitFactory` that properly handles SDK side effects (i.e., factory creation and destruction) within the React component lifecycle, * resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. * * Notable changes to consider when migrating: diff --git a/src/withSplitFactory.tsx b/src/withSplitFactory.tsx index c352ac0..27368c4 100644 --- a/src/withSplitFactory.tsx +++ b/src/withSplitFactory.tsx @@ -12,7 +12,7 @@ import { SplitFactory } from './SplitFactory'; * * @deprecated `withSplitFactory` will be removed in a future major release. We recommend replacing it with the new `SplitFactoryProvider` component. * - * `SplitFactoryProvider` is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, + * `SplitFactoryProvider` is a revised version of `SplitFactory` that properly handles SDK side effects (i.e., factory creation and destruction) within the React component lifecycle, * resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. * * Notable changes to consider when migrating: From 40fdfe158b6edfbdf4b637901f981b59281ff758 Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 2 Feb 2024 12:02:25 -0300 Subject: [PATCH 07/18] Lena's feedback --- MIGRATION-GUIDE.md | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/MIGRATION-GUIDE.md b/MIGRATION-GUIDE.md index 0d51c20..6d8d769 100644 --- a/MIGRATION-GUIDE.md +++ b/MIGRATION-GUIDE.md @@ -1,31 +1,36 @@ -# React SDK v1.11.0: replace deprecated components with the new `SplitFactoryProvider` component -The `SplitFactory` and `withSplitFactory` components have been deprecated since React SDK v1.11.0, and will be removed on a future major release. +# [Migrating to get React SDK v1.11.0 improvements: Replacing the deprecated `SplitFactory` and `withSplitFactory` components](#react-sdk-v1.11.0) -We recommend migrating to the new `SplitFactoryProvider` component instead. This component is a revised version of `SplitFactory` that properly handles SDK side effects (factory creation and destruction) within the React component lifecycle, resolving memory leak issues in React development mode, strict mode and server-side rendering, and also ensuring that the SDK is updated if `config` or `factory` props change. +Starting from React SDK v1.11.0, the `SplitFactoryProvider` component is available and can replace the older `SplitFactory` and `withSplitFactory` components. The deprecated components will continue working, until they are removed in a future major release. + +We recommend migrating to the new `SplitFactoryProvider` component instead. This component is a revised version of `SplitFactory` that properly handles SDK side effects (i.e., factory creation and destruction) within the React component lifecycle. By migrating, you can benefit from a number of improvements: + + - Resolution of memory leak issues in React development mode, strict mode, and server-side rendering. + + - Updating the SDK when `config` or `factory` props change. Notable changes to consider when migrating: - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. - - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. Nonetheless, it is not recommended to use the `client` and `factory` properties directly as better alternatives are available. For example, use the `useTrack` and `useSplitTreatments` hooks rather than the client's `track` and `getTreatments` methods. + - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout, or update, depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. Nonetheless, it is not recommended to use the `client` and `factory` properties directly as better alternatives are available. For example, use the `useTrack` and `useSplitTreatments` hooks rather than the client's `track` and `getTreatments` methods. - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. It is recommended to pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. -# React SDK v1.10.0: replace deprecated hooks with new ones +# [Migrating to get React SDK v1.10.0 improvements: Replacing the deprecated `useClient`, `useTreatments`, and `useManager` hooks with the new `useSplitClient`, `useSplitTreatments`, and `useSplitManager` hooks](#react-sdk-v1.10.0) The `useClient`, `useTreatments` and `useManager` hooks have been deprecated since React SDK v1.10.0, and will be removed on a future major release. We recommend migrating to the new versions `useSplitClient`, `useSplitTreatments` and `useSplitManager` respectively, which provide a more flexible API: -- They accept extra optional parameters, `updateOnSdkReady`, `updateOnSdkReadyFromCache`, `updateOnSdkTimedout` and `updateOnSdkUpdate`, which enable to control when the hook updates the component. For example, you can set `updateOnSdkReady` to `true`, which is `false` by default, to update the component when an `SDK_UPDATE` event is emitted. This is useful when you want to avoid unnecessary re-renders of your components. +- They accept an options object as parameter, instead of a list of parameters as their deprecated counterparts. The options object can contain the same parameters as the old hooks, plus some extra optional parameters: `updateOnSdkReady`, `updateOnSdkReadyFromCache`, `updateOnSdkTimedout` and `updateOnSdkUpdate`, which control when the hook updates the component. For example, you can set `updateOnSdkUpdate` to `true`, which is `false` by default, to update the component when an `SDK_UPDATE` event is emitted. This is useful when you want to avoid unnecessary re-renders of your components. -- They return an object containing the SDK status properties. These properties are described in the ['Subscribe to events and changes' section](https://help.split.io/hc/en-us/articles/360038825091-React-SDK#subscribe-to-events-and-changes) and enable conditional rendering of components based on the SDK status, eliminating the need to access the Split context or using the client's `ready` promise or event listeners. For example, you can show a loading spinner while the SDK is not ready, and use the `treatments` result to render the variants of your App once the SDK is ready. +- They return an object containing the SDK status properties. These properties are described in the ['Subscribe to events and changes' section](https://help.split.io/hc/en-us/articles/360038825091-React-SDK#subscribe-to-events-and-changes) and enable conditional rendering of components based on the SDK status, eliminating the need to access the Split context or use the client's `ready` promise or event listeners. For example, you can show a loading spinner until the SDK is ready, and use the `treatments` result to render the variants of your app once the SDK is ready. ```js -const { client, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitClient(); -const { treatments, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitTreatments({ names: ['feature-flag-1'] }); +const { client, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitClient({ splitKey: userId, updateOnSdkUpdate: true }); +const { treatments, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitTreatments({ names: ['feature-flag-1'], updateOnSdkTimedout: false }); const { manager, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitManager(); ``` @@ -47,7 +52,7 @@ const { treatments } = useSplitTreatments({ names: featureFlagNames, attributes: const { manager } = useSplitManager(); ``` -and use the status properties to conditionally render your components. For example, do: +and use the status properties to conditionally render your components. For example, use the following code: ```javascript const MyComponent = ({ userId }) => { From af8066df376049bf4401d3615f6c258c86fac287 Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 2 Feb 2024 12:05:58 -0300 Subject: [PATCH 08/18] Rollback header links (not working as expected) --- MIGRATION-GUIDE.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MIGRATION-GUIDE.md b/MIGRATION-GUIDE.md index 6d8d769..f6ccb90 100644 --- a/MIGRATION-GUIDE.md +++ b/MIGRATION-GUIDE.md @@ -1,5 +1,5 @@ -# [Migrating to get React SDK v1.11.0 improvements: Replacing the deprecated `SplitFactory` and `withSplitFactory` components](#react-sdk-v1.11.0) +# Migrating to get React SDK v1.11.0 improvements: Replacing the deprecated `SplitFactory` and `withSplitFactory` components Starting from React SDK v1.11.0, the `SplitFactoryProvider` component is available and can replace the older `SplitFactory` and `withSplitFactory` components. The deprecated components will continue working, until they are removed in a future major release. @@ -18,7 +18,7 @@ Notable changes to consider when migrating: - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. -# [Migrating to get React SDK v1.10.0 improvements: Replacing the deprecated `useClient`, `useTreatments`, and `useManager` hooks with the new `useSplitClient`, `useSplitTreatments`, and `useSplitManager` hooks](#react-sdk-v1.10.0) +# Migrating to get React SDK v1.10.0 improvements: Replacing the deprecated `useClient`, `useTreatments`, and `useManager` hooks with the new `useSplitClient`, `useSplitTreatments`, and `useSplitManager` hooks The `useClient`, `useTreatments` and `useManager` hooks have been deprecated since React SDK v1.10.0, and will be removed on a future major release. From 2bbe2ca0d044828fb999410fcda7b48211711752 Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 2 Feb 2024 14:36:05 -0300 Subject: [PATCH 09/18] Lena's feedback --- MIGRATION-GUIDE.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/MIGRATION-GUIDE.md b/MIGRATION-GUIDE.md index f6ccb90..e61a9e1 100644 --- a/MIGRATION-GUIDE.md +++ b/MIGRATION-GUIDE.md @@ -14,13 +14,13 @@ Notable changes to consider when migrating: - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout, or update, depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. Nonetheless, it is not recommended to use the `client` and `factory` properties directly as better alternatives are available. For example, use the `useTrack` and `useSplitTreatments` hooks rather than the client's `track` and `getTreatments` methods. - - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. It is recommended to pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. + - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. You should pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. # Migrating to get React SDK v1.10.0 improvements: Replacing the deprecated `useClient`, `useTreatments`, and `useManager` hooks with the new `useSplitClient`, `useSplitTreatments`, and `useSplitManager` hooks -The `useClient`, `useTreatments` and `useManager` hooks have been deprecated since React SDK v1.10.0, and will be removed on a future major release. +Starting from React SDK v1.10.0, the `useSplitClient`, `useSplitTreatments`, and `useSplitManager` hooks are available and can replace the older `useClient`, `useTreatments`, and `useManager` hooks respectively. The deprecated hooks will continue working, until they are removed in a future major release. We recommend migrating to the new versions `useSplitClient`, `useSplitTreatments` and `useSplitManager` respectively, which provide a more flexible API: @@ -28,6 +28,8 @@ We recommend migrating to the new versions `useSplitClient`, `useSplitTreatments - They return an object containing the SDK status properties. These properties are described in the ['Subscribe to events and changes' section](https://help.split.io/hc/en-us/articles/360038825091-React-SDK#subscribe-to-events-and-changes) and enable conditional rendering of components based on the SDK status, eliminating the need to access the Split context or use the client's `ready` promise or event listeners. For example, you can show a loading spinner until the SDK is ready, and use the `treatments` result to render the variants of your app once the SDK is ready. +The usage of the new hooks is shown below: + ```js const { client, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitClient({ splitKey: userId, updateOnSdkUpdate: true }); const { treatments, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplitTreatments({ names: ['feature-flag-1'], updateOnSdkTimedout: false }); @@ -36,7 +38,7 @@ const { manager, isReady, isReadyFromCache, hasTimedout, lastUpdate } = useSplit -To refactor your existing code, replace: +To migrate your existing code, replace: ```javascript const client = useClient(optionalSplitKey, optionalTrafficType, optionalAttributes); From ceac3a7c42cf804c047b00c0440ca819ae9553eb Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 2 Feb 2024 15:23:24 -0300 Subject: [PATCH 10/18] Add migration example for SplitFactoryProvider --- MIGRATION-GUIDE.md | 53 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/MIGRATION-GUIDE.md b/MIGRATION-GUIDE.md index e61a9e1..bf6aef1 100644 --- a/MIGRATION-GUIDE.md +++ b/MIGRATION-GUIDE.md @@ -12,12 +12,63 @@ We recommend migrating to the new `SplitFactoryProvider` component instead. This Notable changes to consider when migrating: - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. - - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout, or update, depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. Nonetheless, it is not recommended to use the `client` and `factory` properties directly as better alternatives are available. For example, use the `useTrack` and `useSplitTreatments` hooks rather than the client's `track` and `getTreatments` methods. + - When using the `config` prop with `SplitFactoryProvider`, the `factory` and `client` properties in `SplitContext` and the `manager` property in `useSplitManager` results are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout, or update, depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. Nonetheless, it is not recommended to use the `client` and `factory` properties directly as better alternatives are available. For example, use the `useTrack` and `useSplitTreatments` hooks rather than the client's `track` and `getTreatments` methods. - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. You should pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. +To migrate your existing code, replace: + +```javascript +const MyApp = () => { + return ( + + + + ); +}; +``` + +or + +```javascript +const MyApp = withSplitFactory(mySplitConfig)(MyComponent); +``` + +with: + +```javascript +const MyApp = () => { + return ( + + + + ); +}; +``` + +and consider that `factory`, `client` and `manager` properties might be `null` until the SDK has emitted some event: + +```javascript +const MyComponent = () => { + // factoryFromContext === factory, clientFromContext === client, and they are null until some SDK event is emitted + const { factory: factoryFromContext, client: clientFromContext } = useContext(SplitContext); + const { factory, client } = useSplitClient(); + + // Example to evaluate all your flags when the SDK is ready and re-evaluate on SDK_UPDATE events + const { manager } = useSplitManager(); + const FEATURE_FLAG_NAMES = manager ? manager.names() : []; + const { treatments, isReady } = useSplitTreatments({ names: FEATURE_FLAG_NAMES, updateOnSdkUpdate: true }); // updateOnSdkReady is true by default + + return isReady ? + treatments['feature-flag-1'].treatment === 'on' ? + : + : + +} +``` + # Migrating to get React SDK v1.10.0 improvements: Replacing the deprecated `useClient`, `useTreatments`, and `useManager` hooks with the new `useSplitClient`, `useSplitTreatments`, and `useSplitManager` hooks Starting from React SDK v1.10.0, the `useSplitClient`, `useSplitTreatments`, and `useSplitManager` hooks are available and can replace the older `useClient`, `useTreatments`, and `useManager` hooks respectively. The deprecated hooks will continue working, until they are removed in a future major release. From eee6e11c17e364ece7ed8e7221e294fa82525abe Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 2 Feb 2024 15:37:11 -0300 Subject: [PATCH 11/18] Polishing --- CHANGES.txt | 4 ++-- src/SplitFactory.tsx | 10 +++++----- src/withSplitFactory.tsx | 10 +++++----- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 6495e26..6260881 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -5,8 +5,8 @@ - and also ensuring that the SDK is updated if `config` or `factory` props change (Related to issues #11 and #148). - Notable changes when migrating from `SplitFactory` to `SplitFactoryProvider`: - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. - - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. - - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. It is recommended to pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. + - When using the `config` prop with `SplitFactoryProvider`, the `factory` and `client` properties in `SplitContext` and the `manager` property in `useSplitManager` results are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout, or update, depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory`, `client`, and `manager` were immediately available. + - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. You should pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. - Updated internal code to remove a circular dependency and avoid warning messages with tools like PNPM (Related to issue #176). - Updated @splitsoftware/splitio package to version 10.25.1 for vulnerability fixes. diff --git a/src/SplitFactory.tsx b/src/SplitFactory.tsx index e78d021..1636100 100644 --- a/src/SplitFactory.tsx +++ b/src/SplitFactory.tsx @@ -21,11 +21,11 @@ import { DEFAULT_UPDATE_OPTIONS } from './useSplitClient'; * * Notable changes to consider when migrating: * - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. - * - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until - * the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration - * of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. - * - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. It is recommended to - * pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. + * - When using the `config` prop with `SplitFactoryProvider`, the `factory` and `client` properties in `SplitContext` and the `manager` property in `useSplitManager` results + * are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout, or update, depending on + * the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory`, `client`, and `manager` were immediately available. + * - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. You should pass a + * reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. * - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. * * @see {@link https://help.split.io/hc/en-us/articles/360038825091-React-SDK#2-instantiate-the-sdk-and-create-a-new-split-client} diff --git a/src/withSplitFactory.tsx b/src/withSplitFactory.tsx index 27368c4..fd83a0e 100644 --- a/src/withSplitFactory.tsx +++ b/src/withSplitFactory.tsx @@ -17,11 +17,11 @@ import { SplitFactory } from './SplitFactory'; * * Notable changes to consider when migrating: * - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. - * - When using the `config` prop with `SplitFactoryProvider`, `factory` and `client` properties in `SplitContext` are `null` in the first render, until - * the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout or update depending on the configuration - * of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. - * - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. It is recommended to - * pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. + * - When using the `config` prop with `SplitFactoryProvider`, the `factory` and `client` properties in `SplitContext` and the `manager` property in `useSplitManager` results + * are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout, or update, depending on + * the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory`, `client`, and `manager` were immediately available. + * - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. You should pass a + * reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. * - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored. */ export function withSplitFactory(config?: SplitIO.IBrowserSettings, factory?: SplitIO.IBrowserSDK, attributes?: SplitIO.Attributes) { From f0b6978899b507eb70883ad2a21ec1a4758f4fe0 Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 2 Feb 2024 15:38:50 -0300 Subject: [PATCH 12/18] Add comment regarding manager property --- MIGRATION-GUIDE.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MIGRATION-GUIDE.md b/MIGRATION-GUIDE.md index bf6aef1..1a4af15 100644 --- a/MIGRATION-GUIDE.md +++ b/MIGRATION-GUIDE.md @@ -12,7 +12,7 @@ We recommend migrating to the new `SplitFactoryProvider` component instead. This Notable changes to consider when migrating: - `SplitFactoryProvider` utilizes the React Hooks API, requiring React 16.8.0 or later, while `SplitFactory` is compatible with React 16.3.0 or later. - - When using the `config` prop with `SplitFactoryProvider`, the `factory` and `client` properties in `SplitContext` and the `manager` property in `useSplitManager` results are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout, or update, depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory` and `client` were immediately available. Nonetheless, it is not recommended to use the `client` and `factory` properties directly as better alternatives are available. For example, use the `useTrack` and `useSplitTreatments` hooks rather than the client's `track` and `getTreatments` methods. + - When using the `config` prop with `SplitFactoryProvider`, the `factory` and `client` properties in `SplitContext` and the `manager` property in `useSplitManager` results are `null` in the first render, until the context is updated when some event is emitted on the SDK main client (ready, ready from cache, timeout, or update, depending on the configuration of the `updateOn` props of the component). This differs from the previous behavior where `factory`, `client`, and `manager` were immediately available. Nonetheless, it is not recommended to use the `client` and `factory` properties directly as better alternatives are available. For example, use the `useTrack` and `useSplitTreatments` hooks rather than the client's `track` and `getTreatments` methods. - Updating the `config` prop in `SplitFactoryProvider` reinitializes the SDK with the new configuration, while `SplitFactory` does not reinitialize the SDK. You should pass a reference to the configuration object (e.g., via a global variable, `useState`, or `useMemo`) rather than a new instance on each render, to avoid unnecessary reinitializations. @@ -75,7 +75,7 @@ Starting from React SDK v1.10.0, the `useSplitClient`, `useSplitTreatments`, and We recommend migrating to the new versions `useSplitClient`, `useSplitTreatments` and `useSplitManager` respectively, which provide a more flexible API: -- They accept an options object as parameter, instead of a list of parameters as their deprecated counterparts. The options object can contain the same parameters as the old hooks, plus some extra optional parameters: `updateOnSdkReady`, `updateOnSdkReadyFromCache`, `updateOnSdkTimedout` and `updateOnSdkUpdate`, which control when the hook updates the component. For example, you can set `updateOnSdkUpdate` to `true`, which is `false` by default, to update the component when an `SDK_UPDATE` event is emitted. This is useful when you want to avoid unnecessary re-renders of your components. +- They accept an options object as parameter, instead of a list of parameters as their deprecated counterparts. The options object can contain the same parameters as the old hooks, plus some extra optional parameters: `updateOnSdkReady`, `updateOnSdkReadyFromCache`, `updateOnSdkTimedout`, and `updateOnSdkUpdate`, which control when the hook updates the component. For example, you can set `updateOnSdkUpdate` to `true`, which is `false` by default, to update the component when an `SDK_UPDATE` event is emitted. This is useful when you want to avoid unnecessary re-renders of your components. - They return an object containing the SDK status properties. These properties are described in the ['Subscribe to events and changes' section](https://help.split.io/hc/en-us/articles/360038825091-React-SDK#subscribe-to-events-and-changes) and enable conditional rendering of components based on the SDK status, eliminating the need to access the Split context or use the client's `ready` promise or event listeners. For example, you can show a loading spinner until the SDK is ready, and use the `treatments` result to render the variants of your app once the SDK is ready. From d28e3eb883959c01d134f54954d4d7f1ccf07213 Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 2 Feb 2024 17:17:34 -0300 Subject: [PATCH 13/18] Polishing --- src/SplitFactoryProvider.tsx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/SplitFactoryProvider.tsx b/src/SplitFactoryProvider.tsx index 01e09f3..5b55b8b 100644 --- a/src/SplitFactoryProvider.tsx +++ b/src/SplitFactoryProvider.tsx @@ -3,7 +3,7 @@ import React from 'react'; import { SplitComponent } from './SplitClient'; import { ISplitFactoryProps } from './types'; import { WARN_SF_CONFIG_AND_FACTORY } from './constants'; -import { getSplitFactory, destroySplitFactory, IFactoryWithClients, getSplitClient, getStatus, __factories } from './utils'; +import { getSplitFactory, destroySplitFactory, IFactoryWithClients, getSplitClient, getStatus } from './utils'; import { DEFAULT_UPDATE_OPTIONS } from './useSplitClient'; /** @@ -44,7 +44,7 @@ export function SplitFactoryProvider(props: ISplitFactoryProps) { // Effect to subscribe/unsubscribe to events React.useEffect(() => { - const factory = config && __factories.get(config); + const factory = config && getSplitFactory(config); if (factory) { const client = getSplitClient(factory); const status = getStatus(client); From fb367835688a78b6d498742d5ca737f08758269d Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 2 Feb 2024 17:18:34 -0300 Subject: [PATCH 14/18] Update MIGRATION-GUIDE.md Co-authored-by: lenasano <114319916+lenasano@users.noreply.github.com> --- MIGRATION-GUIDE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MIGRATION-GUIDE.md b/MIGRATION-GUIDE.md index 1a4af15..7cb805f 100644 --- a/MIGRATION-GUIDE.md +++ b/MIGRATION-GUIDE.md @@ -69,7 +69,7 @@ const MyComponent = () => { } ``` -# Migrating to get React SDK v1.10.0 improvements: Replacing the deprecated `useClient`, `useTreatments`, and `useManager` hooks with the new `useSplitClient`, `useSplitTreatments`, and `useSplitManager` hooks +# Migrating to get React SDK v1.10.0 improvements: Replacing the deprecated `useClient`, `useTreatments`, and `useManager` hooks Starting from React SDK v1.10.0, the `useSplitClient`, `useSplitTreatments`, and `useSplitManager` hooks are available and can replace the older `useClient`, `useTreatments`, and `useManager` hooks respectively. The deprecated hooks will continue working, until they are removed in a future major release. From d8a77bfd4ace6a68fab1e6db8c54307b14ef7987 Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 2 Feb 2024 17:33:46 -0300 Subject: [PATCH 15/18] Formatting --- src/__tests__/testUtils/utils.tsx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/__tests__/testUtils/utils.tsx b/src/__tests__/testUtils/utils.tsx index 0d02364..443f46e 100644 --- a/src/__tests__/testUtils/utils.tsx +++ b/src/__tests__/testUtils/utils.tsx @@ -110,7 +110,7 @@ export function testAttributesBinding(Component: React.FunctionComponent); - wrapper.rerender(); - wrapper.rerender(); - wrapper.rerender(); + wrapper.rerender(); + wrapper.rerender(); + wrapper.rerender(); } From 6c10873048ea1ba3f8f57976130b11584ced0b36 Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Fri, 22 Mar 2024 15:24:52 -0300 Subject: [PATCH 16/18] Add tslib as a dependency explicitly --- CHANGES.txt | 5 ++++- README.md | 2 ++ package-lock.json | 23 +++++++++++++---------- package.json | 7 ++++--- 4 files changed, 23 insertions(+), 14 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 6260881..f395494 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,7 @@ -1.11.0 (January 16, 2023) +1.11.1 (XXX XX, 2024) + - Bugfixing - Added tslib as an explicit dependency to avoid issues with some package managers that don't install it automatically as a transitive dependency from @splitsoftware/splitio-commons (Related to issue https://github.com/splitio/javascript-client/issues/795). + +1.11.0 (January 16, 2024) - Added new `SplitFactoryProvider` component as a replacement for the now deprecated `SplitFactory` component. - Bugfixing: The new component is a revised version of `SplitFactory` that properly handles SDK side effects (i.e., factory creation and destruction) within the React component lifecycle, - resolving memory leak issues in React development mode, strict mode and server-side rendering (Related to issues #11 and #109), diff --git a/README.md b/README.md index 53c4b7f..3937848 100644 --- a/README.md +++ b/README.md @@ -79,6 +79,7 @@ Split has built and maintains SDKs for: * .NET [Github](https://github.com/splitio/dotnet-client) [Docs](https://help.split.io/hc/en-us/articles/360020240172--NET-SDK) * Android [Github](https://github.com/splitio/android-client) [Docs](https://help.split.io/hc/en-us/articles/360020343291-Android-SDK) * Angular [Github](https://github.com/splitio/angular-sdk-plugin) [Docs](https://help.split.io/hc/en-us/articles/6495326064397-Angular-utilities) +* Flutter [Github](https://github.com/splitio/flutter-sdk-plugin) [Docs](https://help.split.io/hc/en-us/articles/8096158017165-Flutter-plugin) * GO [Github](https://github.com/splitio/go-client) [Docs](https://help.split.io/hc/en-us/articles/360020093652-Go-SDK) * iOS [Github](https://github.com/splitio/ios-client) [Docs](https://help.split.io/hc/en-us/articles/360020401491-iOS-SDK) * Java [Github](https://github.com/splitio/java-client) [Docs](https://help.split.io/hc/en-us/articles/360020405151-Java-SDK) @@ -86,6 +87,7 @@ Split has built and maintains SDKs for: * JavaScript for Browser [Github](https://github.com/splitio/javascript-browser-client) [Docs](https://help.split.io/hc/en-us/articles/360058730852-Browser-SDK) * Node [Github](https://github.com/splitio/javascript-client) [Docs](https://help.split.io/hc/en-us/articles/360020564931-Node-js-SDK) * PHP [Github](https://github.com/splitio/php-client) [Docs](https://help.split.io/hc/en-us/articles/360020350372-PHP-SDK) +* PHP thin-client [Github](https://github.com/splitio/php-thin-client) [Docs](https://help.split.io/hc/en-us/articles/18305128673933-PHP-Thin-Client-SDK) * Python [Github](https://github.com/splitio/python-client) [Docs](https://help.split.io/hc/en-us/articles/360020359652-Python-SDK) * React [Github](https://github.com/splitio/react-client) [Docs](https://help.split.io/hc/en-us/articles/360038825091-React-SDK) * React Native [Github](https://github.com/splitio/react-native-client) [Docs](https://help.split.io/hc/en-us/articles/4406066357901-React-Native-SDK) diff --git a/package-lock.json b/package-lock.json index 377cab9..faf6971 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,17 +1,18 @@ { "name": "@splitsoftware/splitio-react", - "version": "1.11.0", + "version": "1.11.1-rc.0", "lockfileVersion": 2, "requires": true, "packages": { "": { "name": "@splitsoftware/splitio-react", - "version": "1.11.0", + "version": "1.11.1-rc.0", "license": "Apache-2.0", "dependencies": { - "@splitsoftware/splitio": "10.25.1", + "@splitsoftware/splitio": "10.25.2-rc.0", "memoize-one": "^5.1.1", - "shallowequal": "^1.1.0" + "shallowequal": "^1.1.0", + "tslib": "^2.3.1" }, "devDependencies": { "@testing-library/jest-dom": "^5.16.5", @@ -1547,9 +1548,9 @@ } }, "node_modules/@splitsoftware/splitio": { - "version": "10.25.1", - "resolved": "https://registry.npmjs.org/@splitsoftware/splitio/-/splitio-10.25.1.tgz", - "integrity": "sha512-QmCOI2VNhjIMieibtMcc595oyQB5sgrYKSqw7wxKtwMX0VtuPbZ3Lw8fwd0nH2WSKq3Pcjyu3nVSYQRp1bGEvA==", + "version": "10.25.2-rc.0", + "resolved": "https://registry.npmjs.org/@splitsoftware/splitio/-/splitio-10.25.2-rc.0.tgz", + "integrity": "sha512-1itbXQJLqCyUprTsbsYTHVonivyeB42t+viKPGWDbV9kiws0Sl9wF9ESLpV1xfqt9m0NstwJ/uQEcdQr6jqVpQ==", "dependencies": { "@splitsoftware/splitio-commons": "1.13.1", "@types/google.analytics": "0.0.40", @@ -1558,6 +1559,7 @@ "ioredis": "^4.28.0", "js-yaml": "^3.13.1", "node-fetch": "^2.7.0", + "tslib": "^2.3.1", "unfetch": "^4.2.0" }, "engines": { @@ -12089,9 +12091,9 @@ } }, "@splitsoftware/splitio": { - "version": "10.25.1", - "resolved": "https://registry.npmjs.org/@splitsoftware/splitio/-/splitio-10.25.1.tgz", - "integrity": "sha512-QmCOI2VNhjIMieibtMcc595oyQB5sgrYKSqw7wxKtwMX0VtuPbZ3Lw8fwd0nH2WSKq3Pcjyu3nVSYQRp1bGEvA==", + "version": "10.25.2-rc.0", + "resolved": "https://registry.npmjs.org/@splitsoftware/splitio/-/splitio-10.25.2-rc.0.tgz", + "integrity": "sha512-1itbXQJLqCyUprTsbsYTHVonivyeB42t+viKPGWDbV9kiws0Sl9wF9ESLpV1xfqt9m0NstwJ/uQEcdQr6jqVpQ==", "requires": { "@splitsoftware/splitio-commons": "1.13.1", "@types/google.analytics": "0.0.40", @@ -12101,6 +12103,7 @@ "ioredis": "^4.28.0", "js-yaml": "^3.13.1", "node-fetch": "^2.7.0", + "tslib": "^2.3.1", "unfetch": "^4.2.0" } }, diff --git a/package.json b/package.json index e12faf4..5f291c9 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "@splitsoftware/splitio-react", - "version": "1.11.0", + "version": "1.11.1-rc.0", "description": "A React library to easily integrate and use Split JS SDK", "main": "lib/index.js", "module": "es/index.js", @@ -63,9 +63,10 @@ }, "homepage": "https://github.com/splitio/react-client#readme", "dependencies": { - "@splitsoftware/splitio": "10.25.1", + "@splitsoftware/splitio": "10.25.2-rc.0", "memoize-one": "^5.1.1", - "shallowequal": "^1.1.0" + "shallowequal": "^1.1.0", + "tslib": "^2.3.1" }, "devDependencies": { "@testing-library/jest-dom": "^5.16.5", From 136814d4e35c5c21e620c3eb68f0766edd7e36ab Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Mon, 25 Mar 2024 16:36:51 -0300 Subject: [PATCH 17/18] ci-cd update for UMD build --- .github/workflows/ci-cd.yml | 4 ++-- CHANGES.txt | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/workflows/ci-cd.yml b/.github/workflows/ci-cd.yml index 3870a1f..386b114 100644 --- a/.github/workflows/ci-cd.yml +++ b/.github/workflows/ci-cd.yml @@ -77,7 +77,7 @@ jobs: -Dsonar.pullrequest.base=${{ github.event.pull_request.base.ref }} - name: Store assets - if: github.event_name == 'push' && (github.ref == 'refs/heads/master' || github.ref == 'refs/heads/development') + if: github.event_name == 'push' && (github.ref == 'refs/heads/master' || github.ref == 'refs/heads/release_v1.11.1') uses: actions/upload-artifact@v3 with: name: assets @@ -88,7 +88,7 @@ jobs: name: Upload assets runs-on: ubuntu-latest needs: build - if: github.event_name == 'push' && github.ref == 'refs/heads/development' + if: github.event_name == 'push' && github.ref == 'refs/heads/release_v1.11.1' strategy: matrix: environment: diff --git a/CHANGES.txt b/CHANGES.txt index f395494..941d295 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,5 +1,5 @@ -1.11.1 (XXX XX, 2024) - - Bugfixing - Added tslib as an explicit dependency to avoid issues with some package managers that don't install it automatically as a transitive dependency from @splitsoftware/splitio-commons (Related to issue https://github.com/splitio/javascript-client/issues/795). +1.11.1 (March 26, 2024) + - Bugfixing - Added tslib as an explicit dependency to avoid issues with some package managers that don't resolve it automatically as a transitive dependency from @splitsoftware/splitio-commons (Related to issue https://github.com/splitio/javascript-client/issues/795). 1.11.0 (January 16, 2024) - Added new `SplitFactoryProvider` component as a replacement for the now deprecated `SplitFactory` component. From 825a50285981074b6c32f9f04dccb3cfe805a02e Mon Sep 17 00:00:00 2001 From: Emiliano Sanchez Date: Tue, 26 Mar 2024 13:08:12 -0300 Subject: [PATCH 18/18] prepare stable version --- .github/workflows/ci-cd.yml | 4 ++-- package-lock.json | 18 +++++++++--------- package.json | 4 ++-- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/.github/workflows/ci-cd.yml b/.github/workflows/ci-cd.yml index 386b114..3870a1f 100644 --- a/.github/workflows/ci-cd.yml +++ b/.github/workflows/ci-cd.yml @@ -77,7 +77,7 @@ jobs: -Dsonar.pullrequest.base=${{ github.event.pull_request.base.ref }} - name: Store assets - if: github.event_name == 'push' && (github.ref == 'refs/heads/master' || github.ref == 'refs/heads/release_v1.11.1') + if: github.event_name == 'push' && (github.ref == 'refs/heads/master' || github.ref == 'refs/heads/development') uses: actions/upload-artifact@v3 with: name: assets @@ -88,7 +88,7 @@ jobs: name: Upload assets runs-on: ubuntu-latest needs: build - if: github.event_name == 'push' && github.ref == 'refs/heads/release_v1.11.1' + if: github.event_name == 'push' && github.ref == 'refs/heads/development' strategy: matrix: environment: diff --git a/package-lock.json b/package-lock.json index faf6971..c39002d 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,15 +1,15 @@ { "name": "@splitsoftware/splitio-react", - "version": "1.11.1-rc.0", + "version": "1.11.1", "lockfileVersion": 2, "requires": true, "packages": { "": { "name": "@splitsoftware/splitio-react", - "version": "1.11.1-rc.0", + "version": "1.11.1", "license": "Apache-2.0", "dependencies": { - "@splitsoftware/splitio": "10.25.2-rc.0", + "@splitsoftware/splitio": "10.25.2", "memoize-one": "^5.1.1", "shallowequal": "^1.1.0", "tslib": "^2.3.1" @@ -1548,9 +1548,9 @@ } }, "node_modules/@splitsoftware/splitio": { - "version": "10.25.2-rc.0", - "resolved": "https://registry.npmjs.org/@splitsoftware/splitio/-/splitio-10.25.2-rc.0.tgz", - "integrity": "sha512-1itbXQJLqCyUprTsbsYTHVonivyeB42t+viKPGWDbV9kiws0Sl9wF9ESLpV1xfqt9m0NstwJ/uQEcdQr6jqVpQ==", + "version": "10.25.2", + "resolved": "https://registry.npmjs.org/@splitsoftware/splitio/-/splitio-10.25.2.tgz", + "integrity": "sha512-lX06PSoA+hcw66c889RxK9t9cd8evguBFk+x1pw2L4J/58+7XHxp/z1Nnbtb3AOw8s/sX4h87qlTiZqMGPmcmA==", "dependencies": { "@splitsoftware/splitio-commons": "1.13.1", "@types/google.analytics": "0.0.40", @@ -12091,9 +12091,9 @@ } }, "@splitsoftware/splitio": { - "version": "10.25.2-rc.0", - "resolved": "https://registry.npmjs.org/@splitsoftware/splitio/-/splitio-10.25.2-rc.0.tgz", - "integrity": "sha512-1itbXQJLqCyUprTsbsYTHVonivyeB42t+viKPGWDbV9kiws0Sl9wF9ESLpV1xfqt9m0NstwJ/uQEcdQr6jqVpQ==", + "version": "10.25.2", + "resolved": "https://registry.npmjs.org/@splitsoftware/splitio/-/splitio-10.25.2.tgz", + "integrity": "sha512-lX06PSoA+hcw66c889RxK9t9cd8evguBFk+x1pw2L4J/58+7XHxp/z1Nnbtb3AOw8s/sX4h87qlTiZqMGPmcmA==", "requires": { "@splitsoftware/splitio-commons": "1.13.1", "@types/google.analytics": "0.0.40", diff --git a/package.json b/package.json index 5f291c9..a8dcb9c 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "@splitsoftware/splitio-react", - "version": "1.11.1-rc.0", + "version": "1.11.1", "description": "A React library to easily integrate and use Split JS SDK", "main": "lib/index.js", "module": "es/index.js", @@ -63,7 +63,7 @@ }, "homepage": "https://github.com/splitio/react-client#readme", "dependencies": { - "@splitsoftware/splitio": "10.25.2-rc.0", + "@splitsoftware/splitio": "10.25.2", "memoize-one": "^5.1.1", "shallowequal": "^1.1.0", "tslib": "^2.3.1"