Package Reference


Package Alerts Description
@fluid-experimental/attributable-map The map library provides interfaces and implementing classes for map-like distributed data structures.

Primary entry-point to the Fluid Devtools.

To initialize the Devtools alongside your application's IFluidContainer, call initializeDevtools.

The Devtools will automatically dispose of themselves upon Window unload, but if you would like to close them earlier, call IDevtools.dispose.

To enable visualization of Telemetry data, you may create a DevtoolsLogger and provide it during Devtools initialization.


Contains an API for initializing developer tooling alongside the Fluid Framework.

This tooling is built for use alongside our Chromium browser extension. It listens for incoming messages from the corresponding extension, and posts direct responses as well as automatic updates for Fluid state changes.

Individual Fluid Containers can be registered to generate Container-level stats.

Visualization of telemetry logs can be enabled by creating a DevtoolsLogger and providing it to Devtools initialization.

See the package README for more details.

@fluid-experimental/devtools-view This library contains a simple React-based visualizer for the Fluid Devtools.
@fluid-experimental/tree Fluid DDS storing a tree.
@fluid-internal/app-insights-logger This package provides a telemetry logger that will route typical Fluid telemetry to Azure App Insights. Azure App Insights
@fluidframework/aqueduct The aqueduct package is a library for building Fluid objects and Fluid containers within the Fluid Framework. Its goal is to provide a thin base layer over the existing Fluid Framework interfaces that allows developers to get started quickly.
@fluidframework/azure-client A simple and powerful way to consume collaborative Fluid data with the Azure Fluid Relay.

A set of helper utilities for building backend APIs for use with Azure Fluid Relay.

Note that this library's primary entry-point (generateToken) is only intended to be run in a browser context. It is **not** Node.js-compatible.

@fluidframework/cell The SharedCell Distributed Data Structure (DDS) stores a single, shared value that can be edited or deleted.
@fluidframework/common-definitions This library contains common interfaces and definitions used by the Fluid Framework.
@fluidframework/common-utils This library contains common utility functions and classes used by the Fluid Framework.
@fluidframework/container-utils DEPRECATED
@fluidframework/counter This library contains the SharedCounter distributed data structure. A SharedCounter is a shared object which holds a whole number that can be incremented or decremented.
@fluidframework/data-object-base The view interfaces provide a generic way for objects to expose their rendering capabilities to consumers.
@fluidframework/datastore-definitions This library defines the interfaces required to implement and/or communicate with a data store.
@fluidframework/fluid-static Provides a simple and powerful way to consume collaborative Fluid data.
@fluidframework/map The map library provides interfaces and implementing classes for map-like distributed data structures.
@fluidframework/protocol-definitions Core set of Fluid protocol interfaces shared between services and clients. These interfaces must always be back and forward compatible.

Supports distributed data structures which are list-like.

This library's main export is SharedString, a DDS for storing and simultaneously editing a sequence of text.

See the package's README for a high-level introduction to SharedString's feature set.

@fluidframework/task-manager Contains a distributed data structure, ITaskManager, to track the queues of clients that want to exclusively run tasks.

The **tinylicious-client** library provides a simple and powerful way to consume collaborative Fluid data with the Tinylicious service.

The Tinylicious service is a local, in-memory Fluid service intended for prototyping and development purposes.



This library provides an implementation of an in-memory undo redo stack, as well as handlers for the SharedMap, and SharedSegmentSequence distributed datastructures.

<h3>Undo Redo Stack Manager</h3>

The undo redo stack manager is where undo and redo commands are issued, and it holds the stack of all undoable and redoable operations. The undo redo stack manager is a stack of stacks.

The outer stack contains operations, and the inner stack contains all the IRevertible objects that make up that operation. This allows the consumer of the undo redo stack manager to determine the granularity of what is undone or redone.

For instance, you could defined a text operation at the word level, so as a user types you could close the current operation whenever the user types a space. By doing this when the user issues an undo mid-word the characters typed since the last space would be undone, if they issue another undo the previous word would them be undone.

As mentioned above operations are a stack of IRevertible objects. As suggested by the name, these objects have the ability to revert some change which usually means two things. They must be able to track what was changed, and store enough metadata to revert that change.

In order to create IRevertible object there are provided undo redo handlers for commonly used data structures.

<h3>Shared Map Undo Redo Handler</h3>

The SharedMapUndoRedoHandler generates IRevertible objects, SharedMapRevertible for all local changes made to a SharedMap and pushes them to the current operation on the undo redo stack. These objects are created via the valueChanged event of the SharedMap. This handler will never close the current operation on the stack. This is a fairly simple handler, and a good example to look at for understanding how IRevertible objects should work.

<h3>Shared Segment Sequence Undo Redo Handler</h3>

The SharedSegmentSequenceUndoRedoHandler generates IRevertible objects, SharedSegmentSequenceRevertible for any SharedSegmentSequence based distributed data structures like SharedString.

This handler pushes an SharedSegmentSequenceRevertible for every local Insert, Remove, and Annotate operations made to the sequence. The objects are created via the sequenceDelta event of the sequence. Like the SharedMapUndoRedoHandler this handler will never close the current operation on the stack.

This handler is more complex than the SharedMapUndoRedoHandler. The handler itself batches the SharedSegmentSequence changes into the smallest number of IRevertible objects it can to minimize the memory and performance overhead on the SharedSegmentSequence of tracking changes for revert.

<h3>Shared Segment Sequence Revertible</h3>

The SharedSegmentSequenceRevertible does the heavy lifting of tracking and reverting changes on the underlying SharedSegmentSequence. This is accomplished via TrackingGroup objects. A TrackingGroup creates a bi-direction link between itself and the segment. This link is maintained across segment movement, splits, merges, and removal. When a sequence delta event is fired the segments contained in that event are added to a TrackingGroup. The TrackingGroup is then tracked along with additional metadata, like the delta type and the annotate property changes. From the TrackingGroup's segments we can find the ranges in the current document that were affected by the original change even in the presence of other changes. The segments also contain the content which can be used. With the ranges, content, and metadata we can revert the original change on the sequence.

As called out above, there is some memory and performance overhead associated with undo redo. This overhead is from the TrackingGroup. This overhead manifests in a few ways:

- Removed segments in a TrackingGroup will not be garbage collected from the backing tree structure.

- Segments can only be merged if they have all the same TrackingGroups.

This object minimizes the number of TrackingGroups created, so this overhead is very low. This undo redo infrastructure is entirely in-memory so it does not affect other users or sessions. If custom IRevertible objects use TrackingGroups this overhead should be kept in mind to avoid possible performance issues.


Views may be written using a variety of UI frameworks. The view adapters module provides helpful tools for composing these views, intended for use when either:

1. The view being composed is from a different framework than its visual host.

2. It is not known which framework was used in the view being composed.

The adapters translate between different view frameworks to satisfy #1, and are able to inspect a view to deduce its framework to satisfy #2.

fluid-framework The **fluid-framework** package bundles a collection of Fluid Framework client libraries for easy use when paired with a corresponding service client library (for example, \@fluidframework/azure-client or \@fluidframework/tinylicious-client).