Move state management to the Entity API?

Created on 28 August 2025, about 1 month ago

Problem/Motivation

We have 2 services for state management:

StateManager (display_builder.state_manager) which is injected and used everywhere

StateStorage ()

They work very well, but:

  • they are very specific and not "drupaly", so not easy to understand for newcomers. The specific interfaces are very broad (around 50 methods!)
  • some features are missing, like access control, and we don't know how to introduce them without additional complexity.
  • we are not benefiting from cool Drupal mechanisms like the MemoryCache

We are delivering the last alpha release soon. So let's try something a bit crazy before beta phase.

Proposed resolution

Let's adopt the Entity API:

  1. Init Instance entity (just a barebone entity, not a content entity, not a config entity) and InstanceStorage handler
  2. Move StateManager service logic to Instance entity
  3. Keep StateStorage service untouched for now. InstanceStorage will only be a "faΓ§ade" in between Enttiy API and StateStorage service.
  4. Replace all calls to StateManager service to calls to Entity API.
  5. Streamline API's routes and controllers.

Let's be very careful not break anything. It is better to cancel the task than to take the risk .

One of the goal of this task is to simplify the implementation and hopefully reduce the number of line of code! If it makes a mess, let's cancel the task.

Follow-ups

So, out of scope of this issue:

πŸ“Œ Task
Status

Active

Version

1.0

Component

State Manager

Created by

πŸ‡«πŸ‡·France pdureau Paris

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Production build 0.71.5 2024