AdapTable Version:

Framework:

AdapTable State Persistence Guide

Summary

By default, AdapTable State is saved to local storage and users need to do anything
In practice most users use remote storage which AdapTable provides via a series of functions in State Options

AdapTable State is designed to be persisted allowing for a seamless user experience between sessions.

Local Storage

By default, AdapTable State is stored in the browser's local storage.

This is done using the unique adaptableStateKey property provided in Adaptable Options.

Caution

If using Local Storage, all user state will be lost each time the user clear's the browser cache or switches computers

In practice, very few production users of AdapTable use local storage as their storage mechanism.

Find Out More

Learn more about setting the adaptableStateKey property in the Integration Guide

Remote Storage

AdapTable also enables User State to be persisted remotely in - and subsequently retrieved from - any location of the users' choice.

Note

Most of the demos in this site use Local Storage for convenience sake
However, the overwhelming majority of real world applications that use AdapTable leverage remote storage

Remote storage is accessible via a set of JavaScript functions available in State Options.

State Options provides 5 functions which allow developers to control the management of AdapTable State and supports custom implementations and functionality for managing state:

Hint

This allows you to provide your own hydration or rehydration functionality if required
It also allows you to enrich the State when its being loaded with your own items (e.g. Entitlements)

Function	Enables	Default AdapTable Behaviour
`loadState`	Customization of State loading	Loads State from local storage
`applyState`	Hooking into State hydration
`saveState`	Customization of State that is about to be persisted
`persistState`	Customisation of State persistence	Persists State to local storage
`clearState`	Clears all User State	Clears State from local storage

Remote Storage Workflow

The AdapTable State flow is as follows:

User Loads Page --> loadState() state1 -> applyState(state1)
state2 ---- ADAPTABLE NOW READY WITH STATE (state2)
User Updates State ------ saveState(state3):
state4 -> persistState(state4)

Load State

loadState

Default: Loads State from local storage

AdaptableLoadStateFunction

Manages loading remote Adaptable State (async)

AdaptableLoadStateFunction

By default, AdapTable will read and return the state that was persisted from localStorage (using the adaptableId key)

Note

loadState is nearly always used in conjunction with persistState - the other side of the persistence mechanism

The function is of type AdaptableLoadStateFunction:

export interface AdaptableLoadStateFunction {
  (adaptableStateFunctionConfig: AdaptableStateFunctionConfig): Promise<any>;
}

The function receives a AdaptableStateFunctionConfig object defined as follows:

Property	Description
actionName	Name of the action that triggered the state change.
adaptableApi	Adaptable API
adaptableContext	Custom application Context provided in `AdaptableOptions.adaptableContext`
adaptableId	Id of current Adaptable instance
adaptableStateKey	State Key being used
previousState	Previous state before the action was applied. This is useful for comparing changes or reverting if necessary.
userName	current Adaptable user

Hint

loadState can be used to load Adaptable State from the browser window object or a remote location

The hydration flow is: loadState -> applyState

So whatever loadState returns, is passed to applyState.

stateOptions: {
  // loadState is used to load the Adaptable State from a remote source (firebase in this example)
  // It returns a promise which is resolved when the State is retrieved from firebase
  loadState: () => {
    return firebase
      .database()
      .ref(`initialState/${id}`)
      .once('value')
      .then(function (snapshot) {
        const str = snapshot.val();
        return str ? JSON.parse(str) : {};
      });
  },
}

Caution

This function should be asynchronous

Apply State

applyState

Allows hooking into Adaptable State hydration

This function determines what state is (re)applied in AdapTable when AdapTable is initialized.

The definition of the function is:

applyState?: (state: any) => any;

Note

This function is useful when saveState was specified and added new custom properties, which will again be accessible into the applyState function.

The hydration flow is: loadState -> applyState

So whatever loadState returns, is passed to this function.

Caution

This function should be synchronous

The default implementation is to do nothing:

(state) => state

Hint

If you used saveState to add custom app-specific properties on the top-level object you returned, it's a good practice to clear these properties and just return Adaptable State from this function.

adaptableOptions = {
  stateOptions: {
    saveState: (state) => {
      return {
        ...state,
        userSettings: {
          language: 'de',
        },
      };
    },
    applyState: (state) => {
      const {userSettings, ...adaptableState} = state;
      // do something with userSettings here
      return adaptableState;
    },
  },
};

Save State

saveState

AdaptableSaveStateFunction

Allows customization of the Adaptable State about to be persisted

AdaptableSaveStateFunction

This function allows developers to customise the AdapTable State that is going to be persisted.

The function is of type AdaptableSaveStateFunction:

export interface AdaptableSaveStateFunction {
  (
    state: AdaptableState, adaptableStateFunctionConfig: AdaptableStateFunctionConfig
  ): any;
}

The function receives a AdaptableStateFunctionConfig object defined as follows:

Property	Description
actionName	Name of the action that triggered the state change.
adaptableApi	Adaptable API
adaptableContext	Custom application Context provided in `AdaptableOptions.adaptableContext`
adaptableId	Id of current Adaptable instance
adaptableStateKey	State Key being used
previousState	Previous state before the action was applied. This is useful for comparing changes or reverting if necessary.
userName	current Adaptable user

In this case, you might find it useful to also define applyState which hooks into state hydration, and gives you access to the persisted custom properties, so you can use them later in the applicaton.

Hint

If you also want to modify the persistence behaviour, you should implement the persistState as well

The persistence (dehydration) flow is the following: saveState -> persistState

Note

You have to make sure that the returned object is serializable with JSON.stringify - in case that it's not, you could define persistState to do a custom serialization of the object.

Caution

This function should be synchronous

The default implementation is to do nothing:

(state) => state

Hint

Use this function to add other properties to Adaptable State before persistence

adaptableOptions = {
  stateOptions: {
    saveState: (state) => {
      return {
        ...state,
        userSettings: {
          language: 'de',
        },
      };
    },
  },
};

Persist State

persistState

Default: Persists State to local storage

AdaptablePersistStateFunction

Enables the customization of State persistence

AdaptablePersistStateFunction

By default AdapTable stringifies the AdapTable State and puts it into the localStorage using the adaptableId key.

This function can be used to change this behaviour, and to throttle state persistence or perform other actions.

The function is of type AdaptablePersistStateFunction:

export interface AdaptablePersistStateFunction {
  (
    state: AdaptableState, adaptableStateFunctionConfig: AdaptableStateFunctionConfig
  ): any;
}

The function receives a AdaptableStateFunctionConfig object defined as follows:

Property	Description
actionName	Name of the action that triggered the state change.
adaptableApi	Adaptable API
adaptableContext	Custom application Context provided in `AdaptableOptions.adaptableContext`
adaptableId	Id of current Adaptable instance
adaptableStateKey	State Key being used
previousState	Previous state before the action was applied. This is useful for comparing changes or reverting if necessary.
userName	current Adaptable user

Note

This function is generally used in conjunction with loadState - the other side of the persistence mechanism

The persistence (dehydration) flow is: saveState -> persistState.

Hint

Use saveState to add props to the state about to be persisted; whatever that returns is passed to persistState

Clear State

clearState

AdaptableClearStateFunction

Allows clearing of remote Adaptable State

AdaptableClearStateFunction

This is an optional function which will clear out any saved remote state.

It is only invoked in one place in AdapTable - inside the reloadInitialState function in State API

Note

If using local storage then AdapTable will clear this out automatically

The function is of type AdaptableClearStateFunction:

export interface AdaptableClearStateFunction {
  (adaptablestatefunctionconfig: AdaptableStateFunctionConfig): Promise<any>;
}

The function receives a AdaptableStateFunctionConfig object defined as follows:

Property	Description
actionName	Name of the action that triggered the state change.
adaptableApi	Adaptable API
adaptableContext	Custom application Context provided in `AdaptableOptions.adaptableContext`
adaptableId	Id of current Adaptable instance
adaptableStateKey	State Key being used
previousState	Previous state before the action was applied. This is useful for comparing changes or reverting if necessary.
userName	current Adaptable user

adaptableOptions = {
  stateOptions: {
    clearState: (state) => {
      return {
        ...state,
        userSettings: {
          language: 'de',
        },
      };
    },
  },
};

Remote State Persistence

Fork Fork

This example illustrates how straightforward is to load/persist state from/to a remote datastore
Here we use Supabase as our persistence layer
We provide custom implementations for loadState and persistState from State Options

In this demo we provide implementations for the loadState and persistState functions to connect our State to a remote Supabase datastore. Note: The state is shared with everyone who uses the same AdaptableStateKey.

Loading the state from a remote datastore - using loadState in State Options:

/**
 * The loadState function is used to load the state
 * from a remote source - namely Supabase in this example
 *
 * It returns a promise which is resolved when the state object is
 * retrieved from Supabase.
 */
loadState: (config: AdaptableStateFunctionConfig) => {
    return supabaseService.loadAdaptableState(config.adaptableStateKey);
}

Persist state changes to a remote datastore - using persistState in State Options:

/**
 * The persistState function is called with the state that needs to be persisted.
 * By default, state is persisted in localStorage, but this example
 * illustrates how you can persist it to a remote datastore (Supabase, etc)
 */
persistState: (
    state: Partial<AdaptableState>,
    config: AdaptableStateFunctionConfig
) => {
    return supabaseService.persistAdaptableState(
        state,
        config.adaptableStateKey,
        config.userName
    );
}

Try It Out

make any changes to the AdapTable State (e.g. change the current Layout) and then refresh the page: the changes will be retained
change the AdaptableStateKey: the grid will be reset to its initial state and a new state will be persisted
going back to the previous AdaptableStateKey will restore the previous state

import {
  AdaptableApi,
  AdaptableButton,
  AdaptableOptions,
  AdaptableState,
  AdaptableStateFunctionConfig,
  CustomToolbarButtonContext,
} from '@adaptabletools/adaptable';
import {SupabasePersistenceService} from './SupabasePersistenceService';
import {WebFramework} from './rowData';

const supabaseService = new SupabasePersistenceService();

export const adaptableOptions: AdaptableOptions<WebFramework> = {
  primaryKey: 'id',
  adaptableId: 'Using Supabase State',
  adaptableStateKey: 'docs/PersistentStateDemo',
  stateOptions: {
    /**
     * The loadState function is used to load the state
     * from a remote source - namely Supabase in this example
     *
     * It returns a promise which is resolved when the state object is
     * retrieved from Supabase.
     */
    loadState: (config: AdaptableStateFunctionConfig) => {
      return supabaseService.loadAdaptableState(config.adaptableStateKey);
    },

    /**
     * The persistState function is called with the state that needs to be persisted.
     * By default, state is persisted in localStorage, but this example
     * illustrates how you can persist it to a remote datastore (Supabase, etc)
     */
    persistState: (
      state: Partial<AdaptableState>,
      config: AdaptableStateFunctionConfig
    ) => {
      return supabaseService.persistAdaptableState(
        state,
        config.adaptableStateKey,
        config.userName
      );
    },
  },
  dashboardOptions: {
    customToolbars: [
      {
        name: 'StateKeyConfigInput',
        render: ({adaptableApi}: {adaptableApi: AdaptableApi}) => {
          const stateKeyValue = adaptableApi.optionsApi.getAdaptableStateKey();
          return `
                <label>AdapTable State Key:</label>
                <input type="text" id="stateKeyValueInput" value="${stateKeyValue}" style="width: 15rem;">
        `;
        },
      },
      {
        name: 'StateKeyConfigButton',
        toolbarButtons: [
          {
            label: 'Set Key & Refresh State',
            buttonStyle: {
              tone: 'info',
              variant: 'raised',
            },
            onClick: (
              button: AdaptableButton<CustomToolbarButtonContext>,
              context: CustomToolbarButtonContext
            ) => {
              const element: any =
                document.getElementById('stateKeyValueInput');
              const stateKeyValue = element!.value;
              if (stateKeyValue) {
                context.adaptableApi.stateApi.setAdaptableStateKey(
                  stateKeyValue
                );
              }
            },
          },
        ],
      },
    ],
  },
  initialState: {
    Dashboard: {
      Tabs: [
        {
          Name: 'State Settings',
          Toolbars: ['StateKeyConfigInput', 'StateKeyConfigButton'],
        },
      ],
      PinnedToolbars: ['Layout'],
    },
    Theme: {CurrentTheme: 'dark'},
    FormatColumn: {
      FormatColumns: [
        {
          Name: 'formatColumn-github_stars',
          Rule: {
            Predicates: [
              {
                PredicateId: 'GreaterThan',
                Inputs: [1000],
              },
            ],
          },
          Style: {
            BackColor: 'Yellow',
            ForeColor: 'Black',
          },
          Scope: {
            ColumnIds: ['github_stars'],
          },
        },
      ],
    },
    Layout: {
      CurrentLayout: 'Pivot Layout',
      Layouts: [
        {
          Name: 'Pivot Layout',
          PivotColumns: ['license'],
          PivotGroupedColumns: ['language'],
          PivotAggregationColumns: [
            {ColumnId: 'github_watchers', AggFunc: 'sum'},
            {ColumnId: 'github_stars', AggFunc: 'sum'},
          ],
        },
        {
          Name: 'Standard Layout',
          TableColumns: [
            'name',
            'github_stars',
            'language',
            'github_watchers',
            'updated_at',
            'description',
            'created_at',
            'has_wiki',
            'pushed_at',
            'open_issues_count',
            'open_pr_count',
            'closed_pr_count',
            'has_projects',
            'has_pages',
            'week_issue_change',
          ],
          AutoSizeColumns: true,
        },
      ],
    },
  },
};

Debouncing State Changes

By default AdapTable will debounce saveState and persistState function calls for 400 miliseconds.

This enables grouping multiple sequential calls into single one.

Note

A good analogy might be how lift / elevator doors work

This can be changed using the debounceStateDelay property in State Options.

debounceStateDelay

Default: 400

boolean

Delay (in ms) to debounce saveState and persistState calls

Provides a debounce delay other than the default of 400ms.

Caution

The maximum value allowed is 1000ms, at which point the save/persist calls will happen anyway

// Wait 3/4 of a second before saving and persisting state
const adaptableOptions: AdaptableOptions = {
    stateOptions = {
        debounceStateDelay: 750
    }
};

Managing Multiple States

Load & persist state based on user identity/role

Fork Fork

This example shows how to load & persist state based on user identity/role; (the persistence uses Supabase, but any storage provider works (e.g. Firebase, AWS S3, etc.).
It also showcases user specific Permissions (Entitlements) and how to use them to control access to AdapTable features.
The demo showcases 3 different users:
- Guest (not logged in)
  - any changes they make will not be persisted and will be lost when the page is refreshed
  - all AdapTable features are available but only in read-only mode
- Alice
  - any changes she makes will be persisted and will be available only to her
  - all AdapTable features are available and editable, except for the StyledColumn module which is in read-only mode
- Bob
  - any changes he makes will be persisted and will be available only to him
  - all AdapTable features are available and editable, except for the Alert module which is hidden
The logged in users (Alice and Bob) can revert to the Initial Adaptable State by clicking the Reset State button in the Dashboard.

Expand to see how the State Management and Entitlements is configured

1. The current user information is loaded/set before AdapTable is initialised

in this case (a React app) in a local state variable called currentUser

2. The Initial Adaptable State is set based on the current user information

export const buildAdaptableState = (userName: 'Alice' | 'Bob' | 'GUEST') => {
  const initialConfigForUser = INITIAL_CONFIGS[userName];
  // merge common config with user specific config
  const initialConfig = {
    ...COMMON_CONFIG,
    ...initialConfigForUser,
  };

  // the rest of AdaptbleOptions is the same for all users
  // we handle the user specific behaviour via callbacks
  const adaptableOptions: AdaptableOptions = {
    primaryKey: 'id',
    adaptableId: 'User Specific State Demo',
    userName: userName,
    adaptableStateKey: 'docs/userSpecificStateDemo',
    initialState: initialConfig,
    // ...
  };
  // ...
};

3. The two main state management functions (loadState and saveState) are implemented (overwriting the default ones based on localStorage):

non-logged in users (Guest) will not have their state persisted at all
logged in users (Alice and Bob) will have their state persisted in Supabase
the state key is derived from the username, ensuring that each user has their own distinct state

   stateOptions: {
      loadState: (config: AdaptableStateFunctionConfig) => {
        if (config.userName === 'GUEST') {
          // no persistent state for non-logged in users
          return Promise.resolve({});
        }
        // state key is based on user name
        const stateKey = `${config.adaptableStateKey}/${config.userName}`;

        return supabaseService.loadAdaptableState(stateKey);
      },
      persistState: (state: any, config: AdaptableStateFunctionConfig) => {
        if (config.userName === 'GUEST') {
          // no persistent state for non-logged in users
          return Promise.resolve();
        }
        // state key is based on user name
        const stateKey = `${config.adaptableStateKey}/${config.userName}`;
        return supabaseService.persistAdaptableState(
          state,
          stateKey,
          config.userName
        );
   }

4. The Clear state button which is available to logged in users (Alice and Bob) simply makes use of the extensive Adaptable API:

onClick: (_button, context) => {
    // clear remote state
    // alternatively, we could also provide a `StateOptions.clearState()` function with the same implementation
    // if provided, it will be called automatically by the `reloadInitialState()` function
    const optionsApi = context.adaptableApi.optionsApi;
    const stateKey = `${optionsApi.getAdaptableStateKey()}/${
       context.userName
    }`;
    supabaseService.clearAdaptableState(stateKey, context.userName);

    // reload local state
    const stateApi = context.adaptableApi.stateApi;
    stateApi.reloadInitialState();
}

5. The Entitlements are configured based on the current user information:

    entitlementOptions: {
      defaultAccessLevel: context => {
        if (context.userName === 'GUEST') {
          return 'ReadOnly';
        }
        return 'Full';
      },
      moduleEntitlements: context => {
        if (
          context.userName === 'Alice' &&
          context.adaptableModule === 'StyledColumn'
        ) {
          return 'ReadOnly';
        }
        if (context.userName === 'Bob' && context.adaptableModule === 'Alert') {
          return 'Hidden';
        }
        return context.defaultAccessLevel;
      }
    }

Try It Out

Log in as Alice or Bob to see how the state is persisted distinctively for each user by making various changes to the grid and then refreshing the page
- e.g. change the current Layout (sorting/adding/hiding columns), add a new FormatColumn, etc.
Reset the state by clicking the Reset State button in the Dashboard at any time
Navigate to the StyledColumn module and try to edit the existing style (only Alice will not be able to do this)

Controlling State Persistence

In more advanced use cases, developers wish to control how and when State is persisted.

Their aim is to suppress automatic State Persistence, and to persist state imperatively instead.

There are 2 common scenarios:

suppressing all State Persistence and replacing it with an imperative save function
suppressing specific State Persistence and replacing just that with an imperative save function

Hint
A popular use case is to save Layouts manually, on clicking a button, rather than automatically

Suppressing all Persistence

Persisting state imperatively

Fork Fork

In this example we show how to suppress the automatic state persistence and imperatively persist the state
This is useful when you want to control when the state is persisted, e.g. after a user action or a specific event
This demo uses the Adaptable Context to handle the interaction, but you can use any other mechanism, including your own application logic/state management

Try It Out

Perform any changes to the AdapTable State: e.g. change the current Layout (sorting/adding/hiding columns), add a new FormatColumn, etc.
The changes will be kept client side and will be persisted only when you click the Persist State button in the Dashboard
Refreshing the demo will load the last persisted state, but any changes made since the last persistence will be lost
The suppressed changes are logged in the console
Reset the state to the initial value by clicking the Reset State button in the Dashboard at any time

import {AdaptableOptions} from '@adaptabletools/adaptable';
import {WebFramework} from './rowData';
import {
  cleanupPostPersistState,
  customStateOptions,
  forcePersistState,
  getUnsavedChangesCounter,
  updateLastPersistedState,
} from './stateOptions';

export const adaptableOptions: AdaptableOptions<WebFramework> = {
  primaryKey: 'id',
  adaptableId: 'Custom State Persistence: Imperative Persist',
  stateOptions: customStateOptions,
  dashboardOptions: {
    customToolbars: [
      {
        name: 'PersistState',
        toolbarButtons: [
          {
            label: (_button, context) => {
              const {adaptableApi} = context;
              const unsavedStateChangesCounter =
                getUnsavedChangesCounter(adaptableApi);
              return `Persist State (Unsaved Changes =  ${unsavedStateChangesCounter})`;
            },
            onClick: (_button, context) => {
              const {adaptableApi} = context;

              forcePersistState(adaptableApi);

              adaptableApi.stateApi.persistAdaptableState();
            },
            buttonStyle: (_button, context) => {
              const {adaptableApi} = context;
              const hasUnsavedChanged =
                getUnsavedChangesCounter(adaptableApi) > 0;
              return {
                variant: 'raised',
                tone: hasUnsavedChanged ? 'warning' : 'info',
              };
            },
          },
        ],
        title: 'Check console for more infos',
      },
    ],
    customDashboardButtons: [
      {
        tooltip: 'Reset state',
        icon: {
          name: 'refresh',
        },
        buttonStyle: {
          tone: 'error',
        },
        onClick: (_button, context) => {
          const {adaptableApi} = context;

          context.adaptableApi.stateApi.reloadInitialState();

          // reset transient state values
          // relevant only for this demo
          setTimeout(() => {
            const state = adaptableApi.stateApi.getPersistentState();
            updateLastPersistedState(state);
            cleanupPostPersistState(adaptableApi);
          }, 500);
        },
      },
    ],
  },
  initialState: {
    Dashboard: {
      Tabs: [
        {
          Name: 'Default',
          Toolbars: ['Layout', 'PersistState'],
        },
      ],
    },
    Theme: {CurrentTheme: 'dark'},
    FormatColumn: {
      FormatColumns: [
        {
          Name: 'formatColumn-github_stars',
          Rule: {
            Predicates: [
              {
                PredicateId: 'GreaterThan',
                Inputs: [1000],
              },
            ],
          },
          Style: {
            BackColor: 'Yellow',
            ForeColor: 'Black',
          },
          Scope: {
            ColumnIds: ['github_stars'],
          },
        },
      ],
    },
    Layout: {
      CurrentLayout: 'Standard Layout',
      Layouts: [
        {
          Name: 'Standard Layout',
          TableColumns: [
            'name',
            'github_stars',
            'language',
            'github_watchers',
            'updated_at',
            'description',
            'created_at',
            'has_wiki',
            'pushed_at',
            'open_issues_count',
            'open_pr_count',
            'closed_pr_count',
            'has_projects',
            'has_pages',
            'week_issue_change',
          ],
        },
      ],
    },
  },
};

Suppressing specific Persistence

Persisting specific state slices imperatively

Fork Fork

In this example we show how to suppress the automatic state persistence of specific state slices (e.g. only Layouts with a specific Tag) and imperatively persist them
All other state changes will be persisted automatically as usual
This is useful when you want to control when specific changes are persisted, e.g. Layout changes, but not other changes (e.g. FormatColumns)
This demo uses the Adaptable Context to handle the interaction, but you can use any other mechanism, including your own application logic/state management

Try It Out

Perform any changes to the 'Protected Layout': e.g. sort/filter/hide columns, etc.
- All changes will NOT be persisted automatically but only when you click the Persist State button in the Dashboard
- Refreshing the demo will load the last persisted state, but any changes made since the last persistence will be lost
- The suppressed changes are logged in the console
Perform any changes to the 'Standard Layout': e.g. sort/filter/hide columns, etc.
- All changes will be persisted automatically as usual
Any other changes to the AdapTable State will be persisted automatically as usual
Reset the state to the initial value by clicking the Reset State button in the Dashboard at any time

import {AdaptableOptions} from '@adaptabletools/adaptable';
import {WebFramework} from './rowData';
import {
  customStateOptions,
  forcePersistState,
  PROTECTED_LAYOUT_TAG,
} from './stateOptions';

export const adaptableOptions: AdaptableOptions<WebFramework> = {
  primaryKey: 'id',
  adaptableId: 'Custom State Persistence: Specific Changes',
  stateOptions: customStateOptions,
  dashboardOptions: {
    customToolbars: [
      {
        name: 'PersistState',
        toolbarButtons: [
          {
            disabled: (_button, context) => {
              const {adaptableApi} = context;
              const currentLayout = adaptableApi.layoutApi.getCurrentLayout();
              return !currentLayout.Tags?.includes(PROTECTED_LAYOUT_TAG);
            },
            label: (_button, context) => {
              return `Persist State (incl. Protected Layout)`;
            },
            onClick: (_button, context) => {
              const {adaptableApi} = context;

              forcePersistState(adaptableApi);

              adaptableApi.stateApi.persistAdaptableState();
            },
            buttonStyle: (_button, context) => {
              return {
                variant: 'raised',
                tone: 'success',
              };
            },
          },
          {
            label: (_button, context) => {
              return `Print Persisted State to Console`;
            },
            onClick: (_button, context) => {
              const {adaptableApi} = context;
              const state =
                JSON.parse(
                  localStorage.getItem(
                    adaptableApi.optionsApi.getAdaptableStateKey()
                  ) as string
                ) || {};

              console.log(`Current Persisted State:`, state);
            },
            buttonStyle: (_button, context) => {
              return {
                variant: 'raised',
                tone: 'accent',
              };
            },
          },
        ],
        title: 'Check console for more infos',
      },
    ],
    customDashboardButtons: [
      {
        tooltip: 'Reset state',
        icon: {
          name: 'refresh',
        },
        buttonStyle: {
          tone: 'error',
        },
        onClick: (_button, context) => {
          context.adaptableApi.stateApi.reloadInitialState();
        },
      },
    ],
  },
  initialState: {
    Dashboard: {
      Tabs: [
        {
          Name: 'Default',
          Toolbars: ['Layout', 'PersistState'],
        },
      ],
    },
    Theme: {CurrentTheme: 'dark'},
    FormatColumn: {
      FormatColumns: [
        {
          Name: 'formatColumn-github_stars',
          Rule: {
            Predicates: [
              {
                PredicateId: 'GreaterThan',
                Inputs: [1000],
              },
            ],
          },
          Style: {
            BackColor: 'Yellow',
            ForeColor: 'Black',
          },
          Scope: {
            ColumnIds: ['github_stars'],
          },
        },
      ],
    },
    Layout: {
      CurrentLayout: 'Protected Layout',
      Layouts: [
        {
          Name: 'Standard Layout',
          TableColumns: [
            'name',
            'github_stars',
            'language',
            'github_watchers',
            'updated_at',
            'description',
            'created_at',
            'has_wiki',
            'pushed_at',
            'open_issues_count',
            'open_pr_count',
            'closed_pr_count',
            'has_projects',
            'has_pages',
            'week_issue_change',
          ],
        },
        {
          Name: 'Protected Layout',
          Tags: [PROTECTED_LAYOUT_TAG],
          RowGroupedColumns: ['language'],
          TableColumns: [
            'name',
            'github_stars',
            'github_watchers',
            'updated_at',
            'description',
            'created_at',
            'has_wiki',
            'pushed_at',
            'open_issues_count',
            'open_pr_count',
            'closed_pr_count',
            'has_projects',
            'has_pages',
            'week_issue_change',
          ],
          RowGroupValues: {
            RowGroupDefaultBehavior: 'collapsed',
          },
        },
      ],
    },
  },
};

PreviousProviding Initial AdapTable State NextManaging AdapTable State

Framework: