This package consists of shared components required by RedHat Cloud Services team.
With npm
npm i -S @redhat-cloud-services/frontend-components
With yarn
yarn add @redhat-cloud-services/frontend-components
This package is dependent on @redhat-cloud-services/frontend-components-utilities and will automatically install it trough direct dependencies.
- Remove
cjs
oresm
from your import paths. - Remove the
components
fragment from your import path - Modules now have default value
// v2
import { Ansible } from '@redhat-cloud-services/frontend-components/components/cjs/Ansible';
// v3
import Ansible from '@redhat-cloud-services/frontend-components/Ansible';
/** OR */
import { Ansible } from '@redhat-cloud-services/frontend-components/Ansible';
Importing CSS for components is no longer required. Components import their styling whenever they are rendered for the first time.
-@import '~@redhat-cloud-services/frontend-components/index.css';
When importing a partial component like TextFilter
from ConditionalFilter
, use direct import shorthand from ConditionalFilter
. Do not import from TextFilter
file directly!
All imports must have at most only one level!
// OK
import { X } from '@redhat-cloud-services/frontend-components/<ModuleName>'
// Wrong!!
import X from '@redhat-cloud-services/frontend-components/<ModuleName>/X'
Deeper imports will break automatic csj/esm module resolution.
In order not to improve your bundle size you you should either import components trough direct imports or use babel plugin to change relative imports to direct imports. You can mix both direct imports and babel plugin, it's just convenient to use the babel plugin so you don't have to change all of your imports.
For speedy build times, you can use direct import paths For instance tableToolbar
can be imported as:
import TableToolbar from '@redhat-cloud-services/frontend-components/TableToolbar';
You can also use shorthand imports.
There are 2 plugins that can be used to change relative imports to direct imports
- babel-plugin-import - easy setup, however not that extensible
- babel-plugin-transform-imports - harder to setup, but allows custom rules
Since our components require a bit more setting up, we are recommending using babel-plugin-transform-imports
.
Change your babel config to be javascript config babel.config.js
so you can use JS functions to properly transform your imports.
Not every component has its own directory. You can use mapper to map component name to directory.
const FECMapper = {
SkeletonSize: 'Skeleton',
PageHeaderTitle: 'PageHeader'
};
module.exports = {
presets: [
// your presets go here
],
plugins: [
// your plugins
[
'transform-imports',
{
'@redhat-cloud-services/frontend-components': {
transform: (importName) =>
`@redhat-cloud-services/frontend-components/${FECMapper[importName] || importName}`,
preventFullImport: false,
skipDefaultConversion: true
}
},
'frontend-components'
]
// other plugins, for instance PF transform imports and such as well
]
};
As with direct imports you can choose between esm
and cjs
output.
// cjs
transform: (importName) =>`@redhat-cloud-services/frontend-components/${FECMapper[importName] || importName}`,
// esm
transform: (importName) =>`@redhat-cloud-services/frontend-components/esm/${FECMapper[importName] || importName}`,
This set up should work with most applications but individual apps may have dependency conflicts. In this example Insights-Inventory-Frontend will be used
- In FEC,
npm i && npm run build
-> cd dist/@redhat-cloud-services/frontend-components -> here runnpm link
- In Inventory root, run
npm link @redhat-cloud-services/frontend-components
- Verify it actually linked with
ls -l node_modules/@redhat-cloud-services/frontend-components
- In Inventorys fec.config.js , attach
resolve: { modules: ['...', resolve(__dirname, 'node_modules'), 'node_modules'], },
after module federation (FEC packages are looking for node modules in its own context and not the actual app, this overrides it) npm run build
In Inventorynpm run start:proxy
also in Inventory -> Done