Consider creating a central store package for managing and sharing state

Feature Description

While reorganizing the packages from story-editor in #10452 we wanted to make elmements package to provide various APIs to register and retrieve element types and element-library package to be the library of elements available in the story editor. Currently, we use a simple array of elmentTypes in packages/story-editor/src/elements/elementTypes.js and we use the same array to get/create different element configurations using utility functions like getDefinitionForType, createNewElement, which is not ideal when we aim to register and share it between packages. We would also want to allow other consumers to register new element types so that they can create their own elements to be used in the story-editor in the future. We could create a custom react hook and make it a state however it would have a cascading effect on other parts of the code. ( see https://github.com/GoogleForCreators/web-stories-wp/pull/10452#discussion_r806699404 ).

Another instance was while moving meta boxes to wp-story-editor ( see #9027 ) for the decoupling efforts, we wanted to share some states like isSaving so that it can be accessed and modified by both story-editor and wp-story-editor but we had to use some workaround for it instead.

In a broader context, we may also want to allow other plugins ( for example Yoast SEO, etc ) to read and write data using javascript APIs which is currently not possible. So we should consider creating a central store like @wordpress/data which can also manage and share state between modules.

Alternatives Considered

We may use redux or redux-toolkit for this data package but needs discussion.

Additional Context

[sayedtaqui]

or has redux-toolkit already built exactly what we need & there’s no need to re-invent the wheel

That’s what it feels like to me, but it’s probably because I am less familiar with Zustand. I am exploring its docs to see what’s possible.

[swissspidy]

cool cool. I feel like we could make this separate things then? Like have 1 task/epic to move necessary state management into a separate package, then a separate task/epic to convert what state we need from a provider based setup to store based setup. Thoughts?

Yeah absolutely, all this work can be split up into multiple tickets. But first we need to discuss and align on an approach, which this ticket is about. I’ll leave it up to the owning pod(s) to then split up work in a way that makes sense to them.

maybe best to do it selectively as needed vs wholesale?

👍

---

FYI, I asked @sayedtaqui to create small POC using Zustand just to get a better sense of what we’re trying to solve here / act as a base for further discussion. That doesn’t mean any decision on approach has been made or anything, nothing is set in stone.