...

The script managed to correctly migrate a lot of components, but some of them required more attention because of custom decorators such as @RendersSectionForMenu or @listableObjectComponent, such as components in theme folders and components with custom decorators, that were not immediately compatible with a standalone approach.

Already existing themes (dspace and custom) have already been migrated to standalone.

Additional themes, however, can be migrated with the following console command even at a latter time:

Unfortunately, this script is not going to resolve any import of standalone component in the src/app folder, so those imports should be resolved Moreover, themed components were unaffected by the script, so they had to be migrated manually.

Handling CoreModule providers

...

This will also help later on, when we will move to a plugin architecture: since services are provided in root, it would be easy to move them outside the app code to library code.

Handling

...

Custom Decorators for Maps of Injectable Components

In DSpace we used the decorators pattern to create maps of components, which are retrieved and injected by a given key (e.g. @RendersSectionForMenu or @listableObjectComponent).

Such custom decorators were functioning thanks to a workaround: a module method (usually called withEntryComponents()) was serving decorated components the same way that entryComponents worked before Ivy.

This approach is not compatible anymore since we are removing modules thanks to the Standalone architecture.

To fix this problem we replaced the maps - that were previously built dynamically - with static maps.

Image Added

This has been done for almost every decorator. The exception lies in the @ListableObjectComponent decorator. This decorator is creating a very large map of Components, both in depth (the decorator is called 119 times) and width (the map uses 4 keys to retrieve the correct component), and these components are scattered throughout the application.

We temporarily moved all these components into a single module (called ListableModule) that uses the old approach (with the withEntryComponents() method), this means that all such components are not standalone for now. The ListableModule is imported in the AppModule, even if this is not strictly necessary. We are aiming for a better and definitive solution.

In order to maintain some backwards compatibility with custom decorated components in custom-made themes, we did not remove the decorator function, instead we marked it as deprecated.

Image Added

// TODO

Handling Decorated Components: the @ListableObjectComponent Case

// TODO

Migrating Routing and Lazy Loading

...

According to the Angular Standalone Migration Guide, a module can be safely deleted if:

• Has no declarations.
• Has no providers.
• Has no bootstrap components.
• Has no imports that reference a ModuleWithProviders symbol or a module that can't be removed.
• Has no class members. Empty constructors are ignored.

After using the migration script to delete such modules, we checked for other ones that could be safely deleted (e.g. any module that had all the properties in the bullet list, but with an withEntryComponents() method that was not called anymore).

...