TASK: Introduce api to use global-state for global registry

[mhsdesign]

TASK: Introduce api to use global state for configuration and global registry

Originally the Neos Ui was build seemingly without real global state. There is a high order component function - invoked via a decorator @neos() which allowed to inject the registry which was distributed via react context.

For functional components currently one would need to use the same high-order-pattern which is a little quirky with functions compared to say the new concept of hooks.

The use of hooks as approach was shown in @sitegeist-archeaopteryx/neos-bridge we would continue to use the NeosContext and fetch the global registry or configuration from there via hooks like

• useNeos()
• useGlobalRegistry()
• useI18n()
• useConfiguration()

but as this information is truly global and never leads to a re-rendering e.g. is static. We dont have to make that look like a hook but just use javascript state instead. (Like we do for the new translate() function)

This change introduces a new package "@neos-project/neos-ui-registry" to host the global registry as singleton

import {getGlobalRegistry, getRegistryById} from '@neos-project/neos-ui-registry';

const globalRegistry = getGlobalRegistry();
globalRegistry.get('...');
globalRegistry.set('...', ...);

// alias as "get" is common enough
const validators = getRegistryById('validators');

Plugins

Further as part of this refactoring to move correlated code better together - the SynchronousRegistry and SynchronousMetaRegistry are moved to the new @neos-project/neos-ui-registry package.

This has an implication as those are exposed via extensibility api - plugins using import {SynchronousRegistry} from '@neos-project/neos-ui-extensibility' must update this to use import {SynchronousRegistry} from '@neos-project/neos-ui-registry'. This is a soft breaking change as we do not require anyone to update their @neos-project/neos-ui-extensibility package. Previously build plugins continue to work. BUT to also allow plugins build this new way a patch must be made to 9.0 which provides @neos-project/neos-ui-registry already for plugins.

-> or we decide to target 9.0 instead.

Typings 🥳

Also we now have improved typescript support for the globalRegistry - at least with a few registries:

What I did

How I did it

How to verify it

[mhsdesign]

In some (minor) regards this change itself is not finished -> it definitely needs the followup #4012 but id prefer to merge these as separate parts

[Sebobo]

Looks good, but we have to be careful with any changes to the extensibility package

[mhsdesign]

Regarding that we no longer expose SynchronousRegistry when doing import {SynchronousRegistry} from '@neos-project/neos-ui-extensibility' -> i know that this might cause adjustments in the plugins and i also wrote about that above under "Plugins".

At first i thought we could provide a b/c layer to still support that but that might be impossible due to the global state initialisation.

I think the important part is that few people used SynchronousRegistry and that already build plugins continue to work and that if people update their extensibility yarn package @neos-project/neos-ui-extensibility from 9.0.2 to this planned upcoming 9.0.3 that yes they have to rewrite the import to import {SynchronousRegistry} from '@neos-project/neos-ui-registry' -> but i believe this might be preferred over to targeting that change only to 9.1 which would mean that plugins build with `'@neos-project/neos-ui-registry'`` would not work on a Neos 9.0 host ... if we merge into 9.0.3 these plugins would at least work with Neos 9.0.3 and above.

If we consider this a bad deal still and want to preserve full yarn semver promise i will find a way to make import {SynchronousRegistry} from '@neos-project/neos-ui-extensibility' work -> even if we need to duplicate code.

EDIT @Sebobo found a way to support the "SynchronousRegistry" still 744659a

[Sebobo]

EDIT @Sebobo found a way to support the "SynchronousRegistry" still 744659a

Thx. Cool, less breaky, more happy and yes I agree, we should keep targeting 9.0 with this.

[mhsdesign]

I applied some git magic to backport some of the fixups from the other pr to here ;) Now this pr is independent ;)

And as you agree ill probably merge it soon before the sprint^^