Merge pull request #215 from splitio/revert_hocs_and_render_props

Revert HOCs and Render Props components

Author: EmilianoSanchez

CHANGES.txt

@@ -1,15 +1,17 @@
-2.0.0 (November XX, 2024)
+2.0.0 (November 1, 2024)
  - Added support for targeting rules based on large segments.
  - Added support for passing factory instances to the `factory` prop of the `SplitFactoryProvider` component from other SDK packages that extends the `SplitIO.IBrowserSDK` interface, such as `@splitsoftware/splitio-react-native`, `@splitsoftware/splitio-browserjs` and `@splitsoftware/browser-suite` packages.
  - Updated @splitsoftware/splitio package to version 11.0.0 that includes major updates, and updated some transitive dependencies for vulnerability fixes.
  - Renamed distribution folders from `/lib` to `/cjs` for CommonJS build, and `/es` to `/esm` for ECMAScript Modules build.
  - Bugfixing - When the `config` prop is provided, the `SplitFactoryProvider` now makes the SDK factory and client instances available in the context immediately during the initial render, instead of waiting for the first SDK event (Related to https://github.com/splitio/react-client/issues/198). This change fixes a bug in the `useTrack` hook, which was not retrieving the client's `track` method during the initial render.
  - BREAKING CHANGES:
+      - Updated the default value of the `updateOnSdkUpdate` and `updateOnSdkTimedout` parameters of the `useSplitClient` and `useSplitTreatments` hooks options object to `true`, to re-render on all SDK events by default. The same applies for the equivalent props in the `[with]SplitClient` and `[with]SplitTreatments` components.
       - Updated error handling: using the library modules without wrapping them in a `SplitFactoryProvider` component will now throw an error instead of logging it, as the modules requires the `SplitContext` to work properly.
-      - Removed the `core.trafficType` configuration option and the `trafficType` parameter from the SDK `client()` method, `useSplitClient`, `useTrack`, and `SplitClient` component. This is because traffic types can no longer be bound to SDK clients in JavaScript SDK v11.0.0, and so the traffic type must be provided as first argument in the `track` method calls.
-      - Removed deprecated modules: `SplitFactory` component, `useClient`, `useTreatments` and `useManager` hooks, and `withSplitFactory`, `withSplitClient` and `withSplitTreatments` high-order components. Refer to ./MIGRATION-GUIDE.md for instructions on how to migrate to the new alternatives.
-      - Renamed some TypeScript interfaces: `ISplitFactoryProps` to `ISplitFactoryProviderProps`, and `ISplitFactoryChildProps` to `ISplitFactoryProviderChildProps`.
+      - Updated the `SplitFactoryProvider` component to not accept a child as a function (render prop), to avoid unnecessary re-renders when using the library hooks. Refer to ./MIGRATION-GUIDE.md for instructions on how to migrate the child as a function to a regular component.
+      - Removed the `core.trafficType` option from the SDK configuration object, and the `trafficType` parameter from the SDK `client()` method, `useSplitClient`, `useTrack`, `withSplitClient` and `SplitClient` component. This is because traffic types can no longer be bound to SDK clients in JavaScript SDK v11.0.0, and so the traffic type must be provided as first argument in the `track` method calls.
+      - Removed deprecated modules: `SplitFactory` component, `useClient`, `useTreatments` and `useManager` hooks. Refer to ./MIGRATION-GUIDE.md for instructions on how to migrate to the new alternatives.
       - Renamed `SplitSdk` to `SplitFactory` function, which is the underlying Split SDK factory, i.e., `import { SplitFactory } from '@splitsoftware/splitio'`.
+      - Renamed TypeScript interface: `ISplitFactoryProps` to `ISplitFactoryProviderProps`.
       - Dropped support for React below 16.8.0, as the library components where rewritten using the React Hooks API available in React v16.8.0 and above. This refactor simplifies code maintenance and reduces bundle size.
 
 1.13.0 (September 6, 2024)

MIGRATION-GUIDE.md

@@ -14,7 +14,7 @@ Notable changes to consider when migrating:
 
  - 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<Event>` 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.
+ - Updating the `config` prop in `SplitFactoryProvider` re-initializes 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 re-initializations.
 
  - Updating the `factory` prop in `SplitFactoryProvider` replaces the current SDK instance, unlike `SplitFactory` where it is ignored.
 

package-lock.json

@@ -1,6 +1,6 @@
 {
   "name": "@splitsoftware/splitio-react",
-  "version": "2.0.0-rc.2",
+  "version": "2.0.0",
   "description": "A React library to easily integrate and use Split JS SDK",
   "main": "cjs/index.js",
   "module": "esm/index.js",
@@ -63,7 +63,7 @@
   },
   "homepage": "https://github.com/splitio/react-client#readme",
   "dependencies": {
-    "@splitsoftware/splitio": "11.0.0-rc.5",
+    "@splitsoftware/splitio": "11.0.0",
     "memoize-one": "^5.1.1",
     "shallowequal": "^1.1.0",
     "tslib": "^2.3.1"

package.json

@@ -10,7 +10,7 @@ import { useSplitClient } from './useSplitClient';
  * The underlying SDK client can be changed during the component lifecycle
  * if the component is updated with a different splitKey prop.
  *
- * @see {@link https://help.split.io/hc/en-us/articles/360020448791-JavaScript-SDK#advanced-instantiate-multiple-sdk-clients}
+ * @deprecated `SplitClient` will be removed in a future major release. We recommend replacing it with the `useSplitClient` hook.
  */
 export function SplitClient(props: ISplitClientProps) {
   const { children } = props;

src/SplitClient.tsx

@@ -3,9 +3,8 @@ import { ISplitContextValues } from './types';
 import { EXCEPTION_NO_SFP } from './constants';
 
 /**
- * Split Context is the React Context instance that represents our SplitIO global state.
- * It contains Split SDK objects, such as a factory instance, a client and its status (isReady, isTimedout, lastUpdate)
- * The context is created with default empty values, that SplitFactoryProvider and SplitClient access and update.
+ * Split Context is the React Context instance provided by the SplitFactoryProvider and consumed by the Split Hooks.
+ * It is used to share the SDK factory instance and other values across the application.
  */
 export const SplitContext = React.createContext<ISplitContextValues | undefined>(undefined);
 

src/SplitContext.ts

@@ -1,30 +1,30 @@
 import React from 'react';
 
-import { SplitClient } from './SplitClient';
 import { ISplitFactoryProviderProps } from './types';
 import { WARN_SF_CONFIG_AND_FACTORY } from './constants';
-import { getSplitFactory, destroySplitFactory, getSplitClient, getStatus } from './utils';
+import { getSplitFactory, destroySplitFactory, getSplitClient, getStatus, initAttributes } from './utils';
 import { SplitContext } from './SplitContext';
 
 /**
- * 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).
+ * The SplitFactoryProvider is the top level component that provides the Split SDK factory to all child components via the Split Context.
+ * It accepts either an SDK `factory` instance or a `config` object as props to initialize a new SDK factory.
  *
  * 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.
+ * 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 re-initializations.
  *
  * @see {@link https://help.split.io/hc/en-us/articles/360038825091-React-SDK#2-instantiate-the-sdk-and-create-a-new-split-client}
  */
 export function SplitFactoryProvider(props: ISplitFactoryProviderProps) {
-  const { config, factory: propFactory } = props;
+  const { config, factory: propFactory, attributes } = props;
 
   const factory = React.useMemo(() => {
-    return propFactory || (config ? getSplitFactory(config) : undefined);
-  }, [config, propFactory]);
+    const factory = propFactory || (config ? getSplitFactory(config) : undefined);
+    initAttributes(factory && factory.client(), attributes);
+    return factory;
+  }, [config, propFactory, attributes]);
   const client = factory ? getSplitClient(factory) : undefined;
 
-  // Effect to initialize and destroy the factory
+  // Effect to initialize and destroy the factory when config is provided
   React.useEffect(() => {
     if (propFactory) {
       if (config) console.log(WARN_SF_CONFIG_AND_FACTORY);
@@ -42,10 +42,8 @@ export function SplitFactoryProvider(props: ISplitFactoryProviderProps) {
   }, [config, propFactory]);
 
   return (
-    <SplitContext.Provider value={{
-      factory, client, ...getStatus(client)
-    }} >
-      <SplitClient {...props} />
+    <SplitContext.Provider value={{ factory, client, ...getStatus(client) }} >
+      {props.children}
     </SplitContext.Provider>
   );
 }

src/SplitFactoryProvider.tsx

@@ -9,12 +9,11 @@ import { useSplitTreatments } from './useSplitTreatments';
  * call the 'client.getTreatmentsWithConfig()' method if the `names` prop is provided, or the 'client.getTreatmentsWithConfigByFlagSets()' method
  * if the `flagSets` prop is provided. It then passes the resulting treatments to a child component as a function.
  *
- * @see {@link https://help.split.io/hc/en-us/articles/360020448791-JavaScript-SDK#get-treatments-with-configurations}
+ * @deprecated `SplitTreatments` will be removed in a future major release. We recommend replacing it with the `useSplitTreatments` hook.
  */
 export function SplitTreatments(props: ISplitTreatmentsProps) {
   const { children } = props;
-  // SplitTreatments doesn't update on SDK events, since it is inside SplitFactory and/or SplitClient.
-  const context = useSplitTreatments({ ...props, updateOnSdkReady: false, updateOnSdkReadyFromCache: false });
+  const context = useSplitTreatments(props);
 
   return (
     <SplitContext.Provider value={context}>