Update comments and CHANGES file

Author: EmilianoSanchez

CHANGES.txt

@@ -1,8 +1,9 @@
-1.11.0 (January 15, 2023)
- - Added new `SplitFactoryProvider` component as replacement for the now deprecated `SplitFactory` component.
- This new component is a fixed version of the `SplitFactory` component, which is not handling the SDK initialization side-effects in the `componentDidMount` and `componentDidUpdate` methods (commit phase), causing some issues like the SDK not being reinitialized when component props change (Related to issue #11 and #148).
- The new component also supports server-side rendering. See our documentation for more details: https://help.split.io/hc/en-us/articles/360038825091-React-SDK#server-side-rendering (Related to issue #11 and #109).
+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).
  - 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.
 
 1.10.2 (December 12, 2023)
  - Updated @splitsoftware/splitio package to version 10.24.1 that updates localStorage usage to clear cached feature flag definitions before initiating the synchronization process, if the cache was previously synchronized with a different SDK key (i.e., a different environment) or different Split Filter criteria, to avoid using invalid cached data when the SDK is ready from cache.

package-lock.json

@@ -1,6 +1,6 @@
 {
   "name": "@splitsoftware/splitio-react",
-  "version": "1.10.3-rc.3",
+  "version": "1.10.3-rc.4",
   "description": "A React library to easily integrate and use Split JS SDK",
   "main": "lib/index.js",
   "module": "es/index.js",
@@ -62,7 +62,7 @@
   },
   "homepage": "https://github.com/splitio/react-client#readme",
   "dependencies": {
-    "@splitsoftware/splitio": "10.25.1-rc.0",
+    "@splitsoftware/splitio": "10.25.1",
     "memoize-one": "^5.1.1",
     "shallowequal": "^1.1.0"
   },

package.json

@@ -9,14 +9,15 @@ import { DEFAULT_UPDATE_OPTIONS } from './useSplitClient';
 /**
  * SplitFactory will initialize the Split SDK and its main client, listen for its events in order to update the Split Context,
  * and automatically shutdown and release resources when it is unmounted. SplitFactory must wrap other components and functions
- * from this library, since they access the Split Context and its elements (factory, clients, etc).
+ * from this library, since they access the Split Context and its properties (factory, client, isReady, etc).
  *
  * 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.
  * `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 the factory is ready. This differs from the previous behavior where `factory` and `client` were immediately available.
+ * 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.
  *
  * @see {@link https://help.split.io/hc/en-us/articles/360038825091-React-SDK#2-instantiate-the-sdk-and-create-a-new-split-client}
  */

src/SplitFactory.tsx

@@ -7,9 +7,9 @@ import { getSplitFactory, destroySplitFactory, IFactoryWithClients, getSplitClie
 import { DEFAULT_UPDATE_OPTIONS } from './useSplitClient';
 
 /**
- * SplitFactoryProvider will initialize the Split SDK and its main client when it is mounted, listen for its events in order to update the Split Context,
- * and automatically shutdown and release resources when it is unmounted. SplitFactoryProvider must wrap other library components and functions
- * since they access the Split Context and its elements (factory, clients, etc).
+ * SplitFactoryProvider will initialize the Split SDK and its main client when `config` prop is provided or updated, listen for its events in order to update the Split Context,
+ * 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.

src/SplitFactoryProvider.tsx

@@ -12,7 +12,8 @@ import { SplitFactory } from './SplitFactory';
  *
  * @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 the factory is ready. This differs from the previous behavior where `factory` and `client` were immediately available.
+ * 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.
  */
 export function withSplitFactory(config?: SplitIO.IBrowserSettings, factory?: SplitIO.IBrowserSDK, attributes?: SplitIO.Attributes) {