[DEPR]: Compound components in Paragon

[viktorrusakov]

Proposal Date

2023-07-25

Target Ticket Acceptance Date

2023-08-08

Earliest Open edX Named Release Without This Functionality

Quince - 2023-10

Rationale

A lot of Paragon components currently use compound pattern to group components into one by making child components be available through common parent component. This simplifies their usage and reduces amount of imports in consuming applications.

However, this pattern has a drawback in that such components do not support tree-shaking, an optimization technique that allows to detect and remove unused code from the JavaScript's bundle. This means that importing a parent component into the code will bring all of its compound components into the bundle even if they are not used in the application, which will negatively impact consuming application's performance by increasing its bundle size (note that effect on the bundle size in most cases is very minor, but that still is an issue).

Removal

Any repository that installs Paragon will need to update its code to no longer use its compound components, that is components of the form <componentName>.<subComponentName>.

Replacement

Compound components will be replaced by their standalone alternative, e.g. Form.Group component will now be available as a standalone component under FormGroup name and usage of Form.Group will no longer be supported. All of the consuming micro-frontends will need to adhere to this change when they upgrade to the new version of Paragon.

Deprecation

No response

Migration

To ease migration process for the consumers, we will implement a CLI tool in Paragon that will be able to replace compound components with their standalone alternatives across the codebase, this tool will be release together with deprecation of compound components. Ideally, upgrade process would involve only installing new version of Paragon, running a CLI command and commiting the changes.

Additional Info

Related issues from Paragon:

• Compound component (e.g., Form.Group, SearchField.Advanced) exports include entire module in Webpack bundles paragon#2425
• Migrate off of compound components to standalone components paragon#2464

[adamstankiewicz]

[inform] Here's another frontend performance related issue in an attempt to have more proactive observability into bundle size changes on contributions on CI checks, where if there were large file size discrepancies (over a specified threshold) due to introducing a compound component, the PR's CI would fail: openedx/axim-engineering#837

[viktorrusakov]

There have been no objections on https://discuss.openedx.org/t/deprecation-compound-components-in-paragon-public-engineering-204/10809, so moving this to "Accepted" state.

[dianakhuang]

@viktorrusakov Are you planning on working on this and moving it forward? Or could you tell us someone who should be the owner for this DEPR?

[viktorrusakov]

Hi @dianakhuang, probably not anymore as I just don't have required bandwith for this task (and won't have it in the near future). @adamstankiewicz @brian-smith-tcril would any of you be willing to pick this up?

[robrap]

[inform] This DEPR is in the Draft state. It can't move forward without a DEPR coordinator to help update it to match the updated DEPR template. No action is required, unless anyone wants to move this out of Draft.

[feanil]

Looks like no one is willing to pick this up so I'm closing this for now.