@fluidframework/react 0.41.4 → 2.63.0-358419

package/README.md

@@ -1,300 +1,149 @@
 # @fluidframework/react
 
-The Fluid Framework's React package enables React developers to quickly start building large, scalable React apps with synced views powered by Fluid data. It does this by providing a `SyncedDataObject`, Fluid React hooks and a base view class for building React views that use synced states provided by Fluid.
-
-Examples on how to use all of the different tools in this package can be found in the [clicker-react](../../../examples/data-objects/clicker-react) and [`likes-and-comments`](../../../examples/data-objects/likes-and-comments) folders under `./examples/data-object/` from the Fluid Framework repo root.
-
-A good general order of operations to follow when writing a `SyncedDataObject` implementation is the following:
-1. Define the DDSes needed in the `SyncedDataObject`constructor. This can be done using the `set*Config` functions.
-2. Fill in the `render(element: HTMLElement)` function with a call to `ReactDOM.render` and pass in a React view.
-3. Build out the React view either using the `FluidReactView` class or as a functional view using the various hooks that are available.
-
-## SyncedDataObject
-
-The ['SyncedDataObject'](./src/syncedDataObject.ts) is an extension of the Fluid `DataObject` class provided by the `@fluidframework/aqueduct` package. This will be the base class that users developing Fluid objects with React views will want to extend.
-
-The `SyncedDataObject` essentially acts as the data store for the React app that is rendered within it. It provides a configuration where we can set up the schema for our data store, and also guarantees that all the values defined in the configuration will be automatically initialized prior to the view rendering. It also ensures that all updates that were made in the data store for that session will be automatically restored when the app is loaded fresh again by another client for that session. Finally, and most importantly, it guarantees that all updates that are made in the data store are synced live with all other clients that are currently viewing this React app in the current session, without requiring event listeners or component lifecycle methods.
-
-`SyncedDataObject` uses the same factory as `DataObject`. However, in addition, it also provides the following functionality:
-
-- A `syncedStateConfig` where users can define the different types of values that they would like to see prepared for their view to consume. Values defined here are guaranteed to be initialized and available prior to `render` being called. Here, users can assign the DDSes that their React views will need by using the pre-built helper functions available to them from the `syncedObjects` folder, i.e. `setSyncedStringConfig`, `setSyncedArrayConfig`, etc. or they can manually define their own unique configuration with `this.setConfig`. Each value set on the config will have its own `syncedStateId` which we will use to refer to the prepared value from the view.
-
-- An implementation of `IFluidHTMLView` where users fill in the `render` function and the `IFluidHTMLView` interface is already fulfilled without any further code. The React view used in the `render` function should pass in the synced data object for the view to use.
-
-- A `fluidObjectMap` that guarantees that all Fluid DDSes/objects used by this `SyncedDataObject` will be automatically created and loaded without the need for component lifecycle methods such as `initializeStateFirstTime` and `initializeStateFromExisting`
-
-#### SyncedDataObject Example
-
-```jsx
-export class LikesAndComments extends SyncedDataObject {
-    constructor(props) {
-        super(props);
-        // Adds a synced counter to config under ID 'likes'
-        setSyncedCounterConfig(
-            this,
-            "likes",
-        );
-        // Adds a synced array to config under ID 'comments'
-        setSyncedArrayConfig<IComment>(
-            this,
-            "comments",
-        );
-        // Adds a synced string to config under ID 'imgUrl'
-        setSyncedStringConfig(
-            this,
-            "imgUrl",
-            defaultImgUrl,
-        );
-    }
-
-    // Renders the React view
-    public render(div: HTMLElement) {
-        ReactDOM.render(
-            <div>
-                <LikesAndCommentsView
-                    syncedDataObject={this}
-                />
-            </div>,
-            div,
-        );
-        return div;
-    }
-}
-```
+Utilities for integrating content powered by the Fluid Framework into [React](https://react.dev/) applications.
 
-## syncedObject Hooks
-
-The [synced Objects folder](./src/syncedObjects) contains a collection of setSynced\*Config helper function and useSynced\* hook pairings. These functions allow you to easily start using the DDSes that were prepared in the `syncedDataObject`. Since these are all wrappers around the `React.useState` hook, with added syncing functionality, simply calling these functions using regular React hook rules will automatically convert the function into a React functional view.
-
-Each of these helper & hook pairings take a Fluid DDS and binds them to the `syncedDataObject` under the unique `syncedStateId`. This ensures that any changes that happen on these DDSes see synced updates show up live on all connected React views.
-
-A single `syncedDataObject` can hold multiple different types of DDSes and other `DataObjects` under different `syncedStateIds`. However, each unique ID is exclusive to the type of value that is set there when using the helper & hook pairs.
-
-The current roster of available helper & hook pairs for different DDSes are:
-- For just setting type T objects on a `SharedMap` -> `useSyncedObject<T>` & `setSyncedObjectConfig<T>`
-- `SharedCounter` -> `useSyncedCounter` & `setSyncedCounterConfig`
-- `SharedObjectSequence` -> `useSyncedArray<T>` & `setSyncedArrayConfig`
-- `SharedString` -> `useSyncedString` & `setSyncedStringConfig`
-
-NOTE: IT IS IMPORTANT TO PICK THE RIGHT DDS.
-
-While it may be tempting to use `useSyncedObject` for any type T object, a SharedMap has different syncing logic from a SharedString, SharedObjectSequence, etc. Therefore, passing a string to be set on a SharedMap is not the same as using a SharedString. The latter contains additional logic that allows people to, for example, type on the same word together without overwriting one another's characters. Please use `useSyncedString` for these scenarios. The SharedMap, on the other hand, is useful for having a distributed dictionary of items that are always in sync based on the values being set on the map.
-
-### syncedObject Hooks Example
-
-This example provides the view for the `syncedDataObject` in the example above.
-
-```jsx
-function LikesAndCommentsView(
-    props: ILikesAndCommentsViewProps,
-) {
-    // Use the synced states that were prepared on our syncedDataObject above using the setSynced*Config helper functions. Note that the useSynced* function and the ID passed in correspond to the how the config was set above. These values are guaranteed to be available in the view
-    const [likes, likesReducer] = useSyncedCounter(props.syncedDataObject, "likes");
-    const [comments, commentReducer] = useSyncedArray<IComment>(props.syncedDataObject, "comments");
-    const [imgUrl, setImgUrl] = useSyncedString(props.syncedDataObject,"imgUrl");
-
-    // Use local state for the comment as we don't want it to be synced until it is submitted
-    const [currentComment, setCurrentComment] = React.useState("");
-
-    // The remaining code is for rendering the React view elements themselves
-
-    // Convert data to JSX for comments state
-    const commentListItems = comments.map((item, key) => (
-        <li key={key}>
-            {`${item.author}: ${item.message}`}
-        </li>
-    ));
-
-    // Render
-    return (
-        <div>
-            <div>
-                <img width='100%' src={imgUrl?.getText()}/>
-                {imgUrl !== undefined
-                    ? <CollaborativeInput
-                        style={{ width: "90%" }}
-                        sharedString={imgUrl}
-                        onInput={(value: SharedString) => setImgUrl({ value })}
-                    />
-                    : undefined}
-            </div>
-            <span>
-                {`Likes: ${likes}`}
-            </span>
-            <button onClick={() => likesReducer.increment(1)}>
-                {"+"}
-            </button>
-            <div>
-                <div>
-                    <input
-                        type="text"
-                        value={currentComment}
-                        onChange={(e) => setCurrentComment(e.target.value)}
-                        placeholder="Add Comment"
-                    />
-                    <button
-                        onClick={() => {
-                            commentReducer.add({
-                                message: currentComment,
-                                author: getAuthorName(props.syncedDataObject),
-                            });
-                            setCurrentComment("");
-                        }}
-                    >{"Submit"}</button>
-                </div>
-                <ul>{commentListItems}</ul>
-            </div>
-        </div>
-    );
-}
-```
+This package currently has some experimental APIs focused on integrating SharedTree content into React.
 
-Please note that for every different type of DDS that is used, the initial factory for the data object needs to be updated to include those dependencies. Each DDS only needs to be added to the factory dependency list once, regardless of how many different ways it is used.
-
-I.e. for the example above,
-```jsx
-// ----- FACTORY SETUP -----
-export const LikesAndCommentsInstantiationFactory = new DataObjectFactory(
-    "likes-and-comments",
-    LikesAndComments,
-    [
-        SharedCounter.getFactory(),
-        SharedObjectSequence.getFactory(),
-        SharedString.getFactory(),
-    ],
-    {},
-);
-export const fluidExport = LikesAndCommentsInstantiationFactory;
-```
+## Known Issues and Limitations
 
-These hooks should allow for general functionality to start users off building synced React views using Fluid DDSes. However, if users would like to set up their own custom relationships and configurations, we do also offer the `FluidReactView` base class that extends `React.Component` for classical views, and the `useStateFluid` and `useReducerFluid` hooks for functional views.
-
-## FluidReactView
-
-This is the base level `FluidReactView` that offers a synced view state and a mapping between the view and synced state stored in the root. It allows users to set up their own unique relationships between the Fluid state, which is the data state that is being synced, and the view state, which extracts the synced data from the Fluid state in a format that is ready for consumption in the view. In many cases, these the Fluid and view state can be identical but, in more complex scenarios, it may be beneficial to have a cleaner view state that picks out the relevant values needed for the view from the Fluid state.
-
-To see an example of this, please take a look at the `@fluid-example/clicker-react` example. If we take a look at this example in parts, we can see how the `SyncedDataObject` that houses the view aligns with the `FluidReactView` that is rendered.
-
-Looking at the constructor, we see that a configuration is created under ID `clicker` containing a SharedCounter:
-```jsx
-    constructor(props) {
-        super(props);
-        // Mark the counter value in the state as a SharedCounter type and pass in its create function
-        // so that it will be created on the first run and be available on our React state
-        // We also mark the "incremented" event as we want to update the React state when the counter
-        // is incremented to display the new value
-        this.setConfig<ICounterState>(
-            "clicker",
-            {
-                syncedStateId: "clicker",
-                fluidToView: new Map([
-                    [
-                        "counter", {
-                            type: SharedCounter.name,
-                            viewKey: "counter",
-                            sharedObjectCreate: SharedCounter.create,
-                            listenedEvents: ["incremented"],
-                        },
-                    ],
-                ]),
-                defaultViewState: {},
-            },
-        );
-    }
-```
+These are a mix of issues that were encountered when authoring this package, as well as limitations of this package.
 
-Each `FluidReactView` is bound to its unique state ID and will automatically re-render when any values within the synced state change, without needing any additional event listeners or component lifecycle methods. However, since we are defining our own custom relationships now, we are not limited to only one DDS/Fluid object per `syncedStateId` like we were with the helper & hook pairs above. We can define multiple different DDS/Fluid objects per `syncedStateId` by adding keys to the `fluidToView` map. If we wanted a second counter, the configuration would look like this:
-
-```jsx
-this.setConfig<ICounterState>(
-    "clicker",
-    {
-        syncedStateId: "clicker",
-        fluidToView: new Map([
-            [
-                "counter", {
-                    type: SharedCounter.name,
-                    viewKey: "counter",
-                    sharedObjectCreate: SharedCounter.create,
-                    listenedEvents: ["incremented"],
-                },
-                 "counter2", {
-                    type: SharedCounter.name,
-                    viewKey: "counter2",
-                    sharedObjectCreate: SharedCounter.create,
-                    listenedEvents: ["incremented"],
-                },
-            ],
-        ]),
-        defaultViewState: {},
-    },
-);
-```
+Some of this logic would be useful for non-react applications: to avoid creating even more septate packages, that logic is not split into its own package.
+If there is clear demand for this to be done, it might be done in the future.
 
-This is then passed to the `FluidReactView` in the render function with the `clicker` ID:
-```jsx
-public render(element: HTMLElement) {
-    ReactDOM.render(
-        <CounterReactView
-            syncedStateId={"clicker"}
-            syncedDataObject={this}
-        />,
-        element,
-    );
-    return element;
-}
-```
+There is no service implementation agnostic client abstraction that can be referred to here (ex: shared by TinyliciousClient, AzureClient and OdspClient).
+This makes documenting compatibility with that implicit common API difficult.
+It also makes writing service agnostic code at that abstraction level harder.
+
+There does not appear to be a local service implementation of the above mentioned abstraction, which makes testing the code in the package harder.
+
+The commonly used boilerplate for setting up a ContainerSchema based application configures the dev-tools,
+but currently can't be included in this package due to dependency layering issues.
+
+<!-- AUTO-GENERATED-CONTENT:START (LIBRARY_README_HEADER) -->
 
-And now if we look at the view itself, we will see that the state is now pre-loaded with the SharedCounter under the key `counter`, as we defined in the synced state configuration.
-
-```jsx
-class CounterReactView extends FluidReactView<CounterViewState, CounterFluidState> {
-    constructor(props) {
-        super(props);
-        this.state = {};
-    }
-
-    render() {
-        return (
-            <div>
-                <span className="value">
-                    {this.state.counter?.value}
-                </span>
-                <button onClick={() => { this.state.counter?.increment(1); }}>+</button>
-            </div>
-        );
-    }
-}
+<!-- prettier-ignore-start -->
+<!-- NOTE: This section is automatically generated using @fluid-tools/markdown-magic. Do not update these generated contents directly. -->
+
+## Using Fluid Framework libraries
+
+When taking a dependency on a Fluid Framework library's public APIs, we recommend using a `^` (caret) version range, such as `^1.3.4`.
+While Fluid Framework libraries may use different ranges with interdependencies between other Fluid Framework libraries,
+library consumers should always prefer `^`.
+
+If using any of Fluid Framework's unstable APIs (for example, its `beta` APIs), we recommend using a more constrained version range, such as `~`.
+
+## Installation
+
+To get started, install the package by running the following command:
+
+```bash
+npm i @fluidframework/react
 ```
 
-This state will automatically update for all clients when `counter?.increment(1)` is called, and trigger a re-render for everyone. No additional event listeners are required.
+## Importing from this package
+
+This package leverages [package.json exports](https://nodejs.org/api/packages.html#exports) to separate its APIs by support level.
+For more information on the related support guarantees, see [API Support Levels](https://fluidframework.com/docs/build/releases-and-apitags/#api-support-levels).
+
+To access the `public` ([SemVer](https://semver.org/)) APIs, import via `@fluidframework/react` like normal.
+
+To access the `beta` APIs, import via `@fluidframework/react/beta`.
+
+To access the `alpha` APIs, import via `@fluidframework/react/alpha`.
+
+## API Documentation
+
+API documentation for **@fluidframework/react** is available at <https://fluidframework.com/docs/apis/react>.
+
+<!-- prettier-ignore-end -->
+
+<!-- AUTO-GENERATED-CONTENT:END -->
+
+<!-- AUTO-GENERATED-CONTENT:START (README_FOOTER) -->
+
+<!-- prettier-ignore-start -->
+<!-- NOTE: This section is automatically generated using @fluid-tools/markdown-magic. Do not update these generated contents directly. -->
+
+## Minimum Client Requirements
+
+These are the platform requirements for the current version of Fluid Framework Client Packages.
+These requirements err on the side of being too strict since within a major version they can be relaxed over time, but not made stricter.
+For Long Term Support (LTS) versions this can require supporting these platforms for several years.
+
+It is likely that other configurations will work, but they are not supported: if they stop working, we do not consider that a bug.
+If you would benefit from support for something not listed here, file an issue and the product team will evaluate your request.
+When making such a request please include if the configuration already works (and thus the request is just that it becomes officially supported), or if changes are required to get it working.
+
+### Supported Runtimes
+
+-   NodeJs ^20.10.0 except that we will drop support for it [when NodeJs 20 loses its upstream support on 2026-04-30](https://github.com/nodejs/release#release-schedule), and will support a newer LTS version of NodeJS (22) at least 1 year before 20 is end-of-life. This same policy applies to NodeJS 22 when it is end of life (2027-04-30).
+    -   Running Fluid in a Node.js environment with the `--no-experimental-fetch` flag is not supported.
+-   Modern browsers supporting the es2022 standard library: in response to asks we can add explicit support for using babel to polyfill to target specific standards or runtimes (meaning we can avoid/remove use of things that don't polyfill robustly, but otherwise target modern standards).
+
+### Supported Tools
+
+-   TypeScript 5.4:
+    -   All [`strict`](https://www.typescriptlang.org/tsconfig) options are supported.
+    -   [`strictNullChecks`](https://www.typescriptlang.org/tsconfig) is required.
+    -   [Configuration options deprecated in 5.0](https://github.com/microsoft/TypeScript/issues/51909) are not supported.
+    -   `exactOptionalPropertyTypes` is currently not fully supported.
+        If used, narrowing members of Fluid Framework types types using `in`, `Reflect.has`, `Object.hasOwn` or `Object.prototype.hasOwnProperty` should be avoided as they may incorrectly exclude `undefined` from the possible values in some cases.
+-   [webpack](https://webpack.js.org/) 5
+    -   We are not intending to be prescriptive about what bundler to use.
+        Other bundlers which can handle ES Modules should work, but webpack is the only one we actively test.
+
+### Module Resolution
+
+[`Node16`, `NodeNext`, or `Bundler`](https://www.typescriptlang.org/tsconfig#moduleResolution) resolution should be used with TypeScript compilerOptions to follow the [Node.js v12+ ESM Resolution and Loading algorithm](https://nodejs.github.io/nodejs.dev/en/api/v20/esm/#resolution-and-loading-algorithm).
+Node10 resolution is not supported as it does not support Fluid Framework's API structuring pattern that is used to distinguish stable APIs from those that are in development.
+
+### Module Formats
+
+-   ES Modules:
+    ES Modules are the preferred way to consume our client packages (including in NodeJs) and consuming our client packages from ES Modules is fully supported.
+-   CommonJs:
+    Consuming our client packages as CommonJs is supported only in NodeJS and only for the cases listed below.
+    This is done to accommodate some workflows without good ES Module support.
+    If you have a workflow you would like included in this list, file an issue.
+    Once this list of workflows motivating CommonJS support is empty, we may drop support for CommonJS one year after notice of the change is posted here.
 
-If we wanted to access our second counter, we can simply do `this.state.counter2?.value`.
+    -   Testing with Jest (which lacks [stable ESM support](https://jestjs.io/docs/ecmascript-modules) due to [unstable APIs in NodeJs](https://github.com/nodejs/node/issues/37648))
 
-## useStateFluid
+## Contribution Guidelines
 
-This is analogous to the React view but as a functional hook. Users can similarly use the returned setState callback to perform synced updates to both their local and synced states.
+There are many ways to [contribute](https://github.com/microsoft/FluidFramework/blob/main/CONTRIBUTING.md) to Fluid.
 
-Some of the `useSynced*` hooks that we discussed above use this underlying call to power their DDS-specifc behavior. It can also be used directly.
+-   Participate in Q&A in our [GitHub Discussions](https://github.com/microsoft/FluidFramework/discussions).
+-   [Submit bugs](https://github.com/microsoft/FluidFramework/issues) and help us verify fixes as they are checked in.
+-   Review the [source code changes](https://github.com/microsoft/FluidFramework/pulls).
+-   [Contribute bug fixes](https://github.com/microsoft/FluidFramework/blob/main/CONTRIBUTING.md).
 
-## useReducerFluid
+Detailed instructions for working in the repo can be found in the [Wiki](https://github.com/microsoft/FluidFramework/wiki).
 
-This is the hook of choice for larger-scale applications that require more complex mutations, need to work with multiple Fluid objects, and need to have a division between data and view models. Here, instead of having only the view state to manipulate, users have both the view state and the Fluid state, with the former containing primitives used for rendering and the latter containing Fluid views to manipulate data in a synced manner. This hook also introduces the concept of a local FluidObjectMap that stores and listens to changes on already fetched Fluid objects.
+This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
+For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
 
+This project may contain Microsoft trademarks or logos for Microsoft projects, products, or services.
+Use of these trademarks or logos must follow Microsoft’s [Trademark & Brand Guidelines](https://www.microsoft.com/trademarks).
+Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
 
-Reducers offer ways of mutating the state whereas selectors offer ways of fetching data from other Fluid objects. When either involves the addition of new Fluid objects locally, these are added to the FluidObjectMap so that they can be accessed by the view synchronously.
+## Help
 
+Not finding what you're looking for in this README? Check out [fluidframework.com](https://fluidframework.com/docs/).
 
-Any updates to the root state are converted to updates in the view using the provided fluidConverters in the fluidToView map, and vice versa. This allows changes locally to reflect on the root, and root changes to also be translated back to local state updates.
+Still not finding what you're looking for? Please [file an issue](https://github.com/microsoft/FluidFramework/wiki/Submitting-Bugs-and-Feature-Requests).
 
-This is currently used to power the `useSyncedCounter` and `useSyncedArray` hook, and an example showcasing how to use it is coming soon.
+Thank you!
 
-## createContextFluid
+## Trademark
 
-This hook is for users who want to be able to easily create a context with provider and consumer that pass the root and initial state through their app.
+This project may contain Microsoft trademarks or logos for Microsoft projects, products, or services.
 
+Use of these trademarks or logos must follow Microsoft's [Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general).
 
-This hook calls useStateFluid and returns the state and setState values back to be used as part of the initial values passed down by the provider and used by a consumer
+Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
 
+<!-- prettier-ignore-end -->
 
-Essentially, this allows that portion of the root state to be manipulated through different levels of a React app, giving apps the ability to have multiple different views manipulate the same data not only throughout the app but through all renders of the app on different clients
+<!-- AUTO-GENERATED-CONTENT:END -->

package/api-extractor/api-extractor-lint-alpha.cjs.json

@@ -0,0 +1,5 @@
+{
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "<projectFolder>/../../../common/build/build-common/api-extractor-lint.entrypoint.json",
+	"mainEntryPointFilePath": "<projectFolder>/dist/alpha.d.ts"
+}

package/api-extractor/api-extractor-lint-alpha.esm.json

@@ -0,0 +1,5 @@
+{
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "<projectFolder>/../../../common/build/build-common/api-extractor-lint.entrypoint.json",
+	"mainEntryPointFilePath": "<projectFolder>/lib/alpha.d.ts"
+}

package/api-extractor/api-extractor-lint-beta.cjs.json

@@ -0,0 +1,5 @@
+{
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "<projectFolder>/../../../common/build/build-common/api-extractor-lint.entrypoint.json",
+	"mainEntryPointFilePath": "<projectFolder>/dist/beta.d.ts"
+}

package/api-extractor/api-extractor-lint-beta.esm.json

@@ -0,0 +1,5 @@
+{
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "<projectFolder>/../../../common/build/build-common/api-extractor-lint.entrypoint.json",
+	"mainEntryPointFilePath": "<projectFolder>/lib/beta.d.ts"
+}

package/api-extractor/api-extractor-lint-bundle.json

@@ -0,0 +1,5 @@
+{
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "<projectFolder>/../../../common/build/build-common/api-extractor-lint.json",
+	"mainEntryPointFilePath": "<projectFolder>/lib/index.d.ts"
+}

package/api-extractor/api-extractor-lint-public.cjs.json

@@ -0,0 +1,5 @@
+{
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "<projectFolder>/../../../common/build/build-common/api-extractor-lint.entrypoint.json",
+	"mainEntryPointFilePath": "<projectFolder>/dist/public.d.ts"
+}

package/api-extractor/api-extractor-lint-public.esm.json

@@ -0,0 +1,5 @@
+{
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "<projectFolder>/../../../common/build/build-common/api-extractor-lint.entrypoint.json",
+	"mainEntryPointFilePath": "<projectFolder>/lib/public.d.ts"
+}

package/api-extractor-lint.json

@@ -0,0 +1,4 @@
+{
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "../../../common/build/build-common/api-extractor-lint.esm.primary.json"
+}

package/api-extractor.json

@@ -1,4 +1,4 @@
 {
-  "$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
-  "extends": "@fluidframework/build-common/api-extractor-common.json"
+	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
+	"extends": "../../../common/build/build-common/api-extractor-base.esm.no-legacy.json"
 }

package/api-report/react.alpha.api.md

@@ -0,0 +1,114 @@
+## Alpha API Report File for "@fluidframework/react"
+
+> Do not edit this file. It is a report generated by [API Extractor](https://api-extractor.com/).
+
+```ts
+
+// @alpha @sealed
+export interface IReactTreeDataObject<TSchema extends ImplicitFieldSchema> {
+    readonly config: TreeViewConfiguration<TSchema>;
+    readonly treeView: TreeView<TSchema>;
+    readonly TreeViewComponent: (props: TreeViewProps<TSchema>) => React_2.JSX.Element;
+}
+
+// @alpha @system
+export type IsMappableObjectType<T, True = true, False = false, Mapped = {
+    [P in keyof T]: T[P];
+}> = [Mapped] extends [T] ? ([T] extends [Mapped] ? True : False) : False;
+
+// @alpha
+export type NodeRecord = Record<string, TreeNode | TreeLeafValue>;
+
+// @alpha
+export function objectIdNumber(object: object): number;
+
+// @alpha @input
+export interface ObservationOptions {
+    onInvalidation?: () => void;
+}
+
+// @alpha
+export interface PropTreeNode<T extends TreeNode> extends ErasedType<[T, "PropTreeNode"]> {
+}
+
+// @alpha
+export type PropTreeNodeRecord = Record<string, TreeLeafValue | PropTreeNode<TreeNode> | undefined>;
+
+// @alpha
+export type PropTreeValue<T extends TreeNode | TreeLeafValue | undefined> = T extends TreeNode ? PropTreeNode<T> : T;
+
+// @alpha
+export interface SchemaIncompatibleProps {
+    readonly compatibility: SchemaCompatibilityStatus;
+    readonly upgradeSchema: () => void;
+}
+
+// @alpha
+export function toPropTreeNode<T extends TreeNode | TreeLeafValue>(node: T): PropTreeValue<T>;
+
+// @alpha
+export function toPropTreeRecord<T extends NodeRecord>(node: T): WrapPropTreeNodeRecord<T>;
+
+// @alpha
+export function treeDataObject<TSchema extends ImplicitFieldSchema>(treeConfiguration: TreeViewConfiguration<TSchema>, createInitialTree: () => InsertableTreeFieldFromImplicitField<TSchema>): SharedObjectKind<IReactTreeDataObject<TSchema> & IFluidLoadable>;
+
+// @alpha
+export function TreeViewComponent<TSchema extends ImplicitFieldSchema>({ tree, viewComponent: ViewComponent, errorComponent, }: TreeViewProps<TSchema> & {
+    tree: Pick<IReactTreeDataObject<TSchema>, "treeView">;
+}): React_2.JSX.Element;
+
+// @alpha @input
+export interface TreeViewProps<TSchema extends ImplicitFieldSchema> {
+    readonly errorComponent?: React_2.FC<SchemaIncompatibleProps>;
+    readonly viewComponent: React_2.FC<{
+        root: PropTreeValue<TreeFieldFromImplicitField<TSchema>>;
+    }>;
+}
+
+// @alpha
+export type UnwrapPropTreeNode<T extends TreeLeafValue | PropTreeNode<TreeNode> | undefined> = T extends PropTreeNode<infer Node> ? Node : T;
+
+// @alpha
+export function unwrapPropTreeNode<T extends TreeNode | TreeLeafValue>(propNode: PropTreeValue<T> | T): T;
+
+// @alpha
+export type UnwrapPropTreeNodeRecord<T extends PropTreeNodeRecord> = {
+    readonly [P in keyof T]: UnwrapPropTreeNode<T[P]>;
+};
+
+// @alpha
+export function unwrapPropTreeRecord<T extends PropTreeNodeRecord>(props: T): UnwrapPropTreeNodeRecord<T>;
+
+// @alpha
+export function usePropTreeNode<T extends TreeNode | TreeLeafValue, TResult>(propNode: PropTreeValue<T> | T, trackDuring: (node: T) => TResult): WrapNodes<TResult>;
+
+// @alpha
+export function usePropTreeRecord<const T extends PropTreeNodeRecord, TResult>(props: T, f: (node: UnwrapPropTreeNodeRecord<T>) => TResult): WrapNodes<TResult>;
+
+// @alpha
+export function useTree(subtreeRoot: TreeNode): number;
+
+// @alpha
+export function useTreeObservations<TResult>(trackDuring: () => TResult, options?: ObservationOptions): TResult;
+
+// @alpha
+export function withMemoizedTreeObservations<TIn>(component: React_2.FC<TIn>, options?: ObservationOptions & {
+    readonly propsAreEqual?: Parameters<typeof React_2.memo>[1];
+}): React_2.MemoExoticComponent<ReturnType<typeof withTreeObservations<TIn>>>;
+
+// @alpha
+export function withTreeObservations<TIn>(component: React_2.FC<TIn>, options?: ObservationOptions): React_2.FC<TIn> & React_2.FC<WrapNodes<TIn>> & React_2.FC<TIn | WrapNodes<TIn>>;
+
+// @alpha
+export type WrapNodes<T> = T extends TreeNode ? PropTreeNode<T> : T extends readonly (infer U)[] ? readonly WrapNodes<U>[] : T extends infer U ? IsMappableObjectType<U, {
+    [P in keyof U]: WrapNodes<U[P]>;
+} extends U ? U : {
+    [P in keyof U]: WrapNodes<U[P]>;
+}, T> : T;
+
+// @alpha
+export type WrapPropTreeNodeRecord<T extends NodeRecord> = {
+    readonly [P in keyof T]: PropTreeValue<T[P]>;
+};
+
+```

package/api-report/react.beta.api.md

@@ -0,0 +1,7 @@
+## Beta API Report File for "@fluidframework/react"
+
+> Do not edit this file. It is a report generated by [API Extractor](https://api-extractor.com/).
+
+```ts
+
+```

package/api-report/react.public.api.md

@@ -0,0 +1,7 @@
+## Public API Report File for "@fluidframework/react"
+
+> Do not edit this file. It is a report generated by [API Extractor](https://api-extractor.com/).
+
+```ts
+
+```

package/biome.jsonc

@@ -0,0 +1,4 @@
+{
+	"$schema": "./node_modules/@biomejs/biome/configuration_schema.json",
+	"extends": ["../../../biome.jsonc"]
+}