Use FEC toolbar in ListView

[fhlavac]

https://issues.redhat.com/browse/HAC-1714

Replaced custom toolbar used in ListView with one from https://github.com/RedHatInsights/frontend-components to make it easier to be maintained in the future. Also added a possibility to define global toolbar actions using globalActions property

https://github.com/RedHatInsights/frontend-components/tree/master/packages/components/src/PrimaryToolbar

[fhlavac]

/retest

[fhlavac]

/retest

[fhlavac]

/retest

[vojtechszocs]

Both @redhat-cloud-services/frontend-components and classnames are intended as direct (non-peer) dependencies here, so there's no need to add them to root package.json.

Only peer dependencies should have a matching entry in the root package.json under devDependencies.

Looking at @redhat-cloud-services/frontend-components (latest version) regular and peer dependencies:

$ yarn npm info @redhat-cloud-services/frontend-components -f dependencies,peerDependencies
{
  name: '@redhat-cloud-services/frontend-components',
  dependencies: {
    '@redhat-cloud-services/frontend-components-utilities': '^3.2.25',
    'sanitize-html': '^2.7.2',
    '@scalprum/core': '^0.2.3',
    '@scalprum/react-core': '^0.2.4',
    '@redhat-cloud-services/types': '^0.0.10'
  },
  peerDependencies: {
    '@patternfly/react-table': '^4.5.7',
    '@patternfly/react-core': '^4.18.5',
    '@patternfly/react-icons': '^4.53.16',
    classnames: '^2.2.5',
    'prop-types': '^15.6.2',
    react: '^16.14.0 || ^17.0.0',
    'react-dom': '^16.14.0 || ^17.0.0',
    'react-content-loader': '^6.2.0',
    'react-redux': '>=7.0.0',
    'react-router-dom': '^5.0.0',
    lodash: '^4.17.15'
  }
}

The react-router-dom: ^5.0.0 peer dependency doesn't meet our current react-router-dom: ^6.3.0 peer dependency, is that an issue?

Edit: I think it's generally better to treat @redhat-cloud-services/frontend-components as a peer dependency, instead of a regular dependency, can you make this change? (plus add it to root package.json)

Some libraries tend to have very complex dependency trees (oftentimes with more or less outdated dependencies at various levels), which is one of the reason why having it as a peer dependency is preferable.

[vojtechszocs]

If we only intend to consume a couple of React components and types from ^^ library, wouldn't it make more sense to mark this library as non-external? This way, the code we import from it would become part of the generated SDK code (basically treating it as a dev dependency).

[vojtechszocs]

Do we really use this in our code? If not, we can remove this explicit dependency.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: fhlavac
Once this PR has been reviewed and has the lgtm label, please ask for approval from vojtechszocs by writing /assign @vojtechszocs in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@fhlavac: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/all-packages	d1112bb	link	true	/test all-packages

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[fhlavac]

Will prepare a migration PR for HAC infra after openshift/hac-infra#27 is merged and stable. We should merge it all together

[fhlavac]

Closing this until we have a new component repository which should resolve the CI failures