Skip to content

[Security Solution] Analyze existing security_solution common components and identify the list we can move to packages #144944

Open

Description

The goal of this issue is to walk through the common components which belong to the Explore are code ownership according to https://github.com/elastic/kibana/blob/main/.github/CODEOWNERS and build the list of the components for potential moving to the packages.
According to general Kibana guidelines about components architecture:

  • to avoid a circular dependancies between plugins, we should prefer the components as a package, then exposing with the plugin interface.
  • components should remain stateless until they are composed into a rendered React tree.
  • components should define their own contextual API for external services.
  • We should be able to develop, test, fix, and showcase components without running Kibana
    The criteria for deciding that component should be moved from the security_solution to packages:
  1. Component is used by more than one place.
  2. Component is stateless or easily could be transformed to the stateless. By stateless here is meant no ReactContext or Redux dependancies.
  3. We should check if the similar component is not exposed in packages by the other teams in shared-ux (Discover, Lens, others) and if it is this will be a possibility to reuse the package which is already exist instead of building the duplication version.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions