Skip to content

Commit

Permalink
Nico's feedback: 'Notable changes' rather than 'Breaking changes'
Browse files Browse the repository at this point in the history
  • Loading branch information
EmilianoSanchez committed Jan 30, 2024
1 parent c1803ca commit 6105b3f
Show file tree
Hide file tree
Showing 3 changed files with 15 additions and 14 deletions.
9 changes: 5 additions & 4 deletions CHANGES.txt
Original file line number Diff line number Diff line change
@@ -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<Event>` 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.
Expand Down
10 changes: 5 additions & 5 deletions src/SplitFactory.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -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<Event>` 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}
Expand Down
10 changes: 5 additions & 5 deletions src/withSplitFactory.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -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<Event>` 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) {
Expand Down

0 comments on commit 6105b3f

Please sign in to comment.