TASK: cleanup imports of components

[crydotsnake]

Resolves: #3453

What I did

I tidied the imports of our components. So If we have more then one component, they will be imported in only one line.

How I did it

Tidied the imports of the specific components.

How to verify it
None

[crydotsnake]

Will take a look threw the UI code again. To make sure i didnt forget something :)

[crydotsnake]

Checked everything again.

Looks like I didn't miss anything 🙂

[JamesAlias]

Does the current build system support tree-shaking? If not, this change might have an impact on bundle sizes.
cc @mhsdesign

[markusguenther]

Does the current build system support tree-shaking? If not, this change might have an impact on bundle sizes. cc @mhsdesign

Tried to find out, but I think we are not using tree shaking at the moment.
The docs say that it is off by default for our case and we are not using the --tree-shaking=true flag.

[markusguenther]

Ok I guess I was wrong.

By default, tree shaking is only enabled either when [bundling](https://esbuild.github.io/api/#bundle) is enabled or when the output [format](https://esbuild.github.io/api/#format) is set to iife, otherwise tree shaking is disabled. You can force-enable tree shaking by setting it to true:

The iife format is the default format unless we set the platform to node. So, we should have tree shaking at the moment. @mhsdesign is on vacation at the moment 🙈

[Sebobo]

Yes three shaking is active. The bundle would be much bigger without.

[crydotsnake]

Out of interest: How exactly does this affect the way we import the components. How is the difference now compared to before? 🤔

[JamesAlias]

Out of interest: How exactly does this affect the way we import the components. How is the difference now compared to before? 🤔

take these two lines of code:

1. import MyComponent from 'huge-library-of-components/MyComponent'
2. import { MyComponent } from 'huge-library-of-components'

The first line imports all the code exposed by huge-library-of-components/MyComponent.
The second line imports all the code exposed by huge-library-of-components, but only uses/assigns MyComponent.

If tree shaking is not enabled, the hole huge-library-of-component would now be in the final build.
Tree shaking removes the unused code, so it should not matter which import strategy is used.

Does this help? 🙂

[crydotsnake]

ping

[mhsdesign]

Hi hello, yes we have treeshaking turned on and it saves us roughly 0.3mb

but in this case tree-shaking should not make any difference, because we import all the react ui components either way to expose them in our api:

neos-ui/packages/neos-ui/src/apiExposureMap.js

Line 15 in 9585ca7

import * as ReactUiComponents from '@neos-project/react-ui-components';

but we should wait for #3492 as a merge conflict might turn up ^^

[crydotsnake]

Since #3492 is merged and no merge conflict came up, how do we continue here?

[mhsdesign]

A minor merge conflict will turn up with #3306 but if @grebaldi agrees we can merge this cleanup first ;)

• also we should target 9.0 imo ^^

[grebaldi]

Please go ahead :) #3306 will take some extra work anyway.

[crydotsnake]

I would say we can merge this? @mhsdesign

[mhsdesign]

good call :D Yeah but im still unsure if we should target 8.3 or 9.0?

Pro 8.3: Upmerges would be easier, if we add dependencies here

Pro 9.0: If there is a bug (which is unlikely) we are more likely to find it out fast and without any trouble as 9.0 is not released.

Maybe @markusguenther has an opinion.

But after writing this down i think we are safe to target 8.3 ;)

[jonnitto]

Fine by reading.