Mirekys/overridable bundle project

[mirekys]

This PR adds OverridableBundleProject which can be used to provide site-wide UI component overrides using:

#invenio.cfg
WEBPACKEXT_PROJECT = "oarepo_ui.webpack:project"

UI_OVERRIDES = {
    # Flask blueprint endpoint name
    "documents.search": {
       # Overridable component ID            Default import name                  Import path
        "Documents.Search.ResultsList.item": ("ResultsListItem", "@js/documents/search/ResultsListItem")
    }
}

Requires oarepo/nrp-devtools#54

[Ducica]

@mirekys I like the solution, very nice job.

I've also made some checks and if we use this and make some small refactoring, the bundle on search for example, goes from 38 to 27 mb which is a pretty good improvement. it is still not great, but 7 of those that are left is just tiny mce, which we cannot do anything about right now (numbers are of course much smaller for production builds). Anyway, it is a solid step in a good direction.

I got two remarks/questions:

1. If we wish to just disable a certain component, normally, I would do "cmpid":()=>null. The question is if this can be handled by the code generator (meaning if you do not provide component, to just add to override store "cmpid":()=>null". Or to just have a "NullComponent" that can be used in invenio.cfg for when you want to do this.
2. It would be really great, if a 4th parameter (after the import type), could be introduced, which would be for parametrization, i.e. an object with props, so that the component will be automatically parametrized as well. This would be a nice to have and is bypassable like we discussed.

[mirekys]

@mirekys I like the solution, very nice job.

I've also made some checks and if we use this and make some small refactoring, the bundle on search for example, goes from 38 to 27 mb which is a pretty good improvement. it is still not great, but 7 of those that are left is just tiny mce, which we cannot do anything about right now (numbers are of course much smaller for production builds). Anyway, it is a solid step in a good direction.

I got two remarks/questions:

1. If we wish to just disable a certain component, normally, I would do "cmpid":()=>null. The question is if this can be handled by the code generator (meaning if you do not provide component, to just add to override store "cmpid":()=>null". Or to just have a "NullComponent" that can be used in invenio.cfg for when you want to do this.
2. It would be really great, if a 4th parameter (after the import type), could be introduced, which would be for parametrization, i.e. an object with props, so that the component will be automatically parametrized as well. This would be a nice to have and is bypassable like we discussed.

Thanks @Ducica for excellent feedback! The solution for 1. would probably be having this simple Disabled or Noop component exported by e.g. oarepo_ui and referenced from overrides config. That way you could also know, when looking into React devtools component tree, by its name, which parts of UI was deliberately disabled. For 2., I'll have a look at how that could be done. I think it could be possible now without too much effort

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud