search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.62k stars 8.22k forks source link

[META] Moving Kibana off Less and using EUI global CSS scope #19748

Closed snide closed 5 years ago

snide commented 6 years ago

This will be a meta issue for tracking conversion of Kibana's 307 Less files to Sass.

Primary goals

  1. Convert all non-dependency (non node-modules) less files to sass.
  2. Import the EUI global variable scope into those new Sass files. This includes
    • EUI sizing
    • EUI colors
    • EUI breakpoints
    • EUI mixins for things like shadows...etc.
  3. Remove bootstrap.
  4. Remove KUI.
  5. Convert everything to BEM standards of EUI.

Why are we doing this?

  1. Kibana's current styling pipeline is a mess.
  2. We want Kibana to be themable.
  3. We want Kibana and EUI to talk to each other.
  4. We want plugin authors to have a nice, easy way to build frontend that matches our look and feel.

Staged approach

Because of the size of the changes we should consider staging this out. I could see us doing the following...

  1. Convert from Less to Sass, change the selectors to EUI's BEM format and utilize EUI's global scope.
  2. Reorganize the stylesheet locations.
    • Make all plugins follow a known tree pattern for stylesheet usage.
    • Move all vendor / legacy files (like bootstrap) into a known legacy folder structure.

After the above is done

  1. Remove the pieces of bootstrap, KUI that are not in use in the codebase out.
  2. Remove the EUI K6 theme and use EUI native. Make a decision on font-family.
  3. Provide an audit meta issue of legacy usage (KUI and bootstrap) that require conversion. This should be targeted towards operational teams.
  4. Convert any style usage in the templating itself.

Patterns we'll want to follow during conversion

These are simple examples, not meant to be full code methodologies and pathing scenarios.

File organization

Kibana is made up of three major parts: The inherited EUI components, the global Kibana global blob, and individual Kibana plugins.

Kibana global blob would look like this

// kibana_global.scss

// EUI global scope
@import 'node_modules/@elastic/eui/src/themes/k6/k6_globals';
@import 'node_modules/@elastic/eui/src/themes/k6/k6_colors_light';
@import 'node_modules/@elastic/eui/src/global_styling/functions/index';
@import 'node_modules/@elastic/eui/src/global_styling/variables/index';
@import 'node_modules/@elastic/eui/src/global_styling/mixins/index';

// This should be a one liner to import all of EUI's actual component css
@import eui/components

// This would be all kibana components that are considered core to Kibana, hopefully living in the same directory structure somewhere in Kibana.
@import 'kibana_global/variables'
@import 'kibana_global/mixins'
@import 'kibana_global/components'

// For all the stuff we can't get rid of yet
@import 'kibana_global/hack'

Then Kibana's core global scope includes/inherits EUI and builds beyond it with it's own global mixins and components in a single css blob. Anything in this file would be considered usable UI for all of Kibana. We'll have better control over the load order and be able to run proper trash tests as we remove code over time.

Plugins would be separated into their own css files (as shown earlier) and loaded only within their plugin scope.

Plugins

Kibana is mostly made up of plugins. We should aim to move all styling to match the below structure.

src/some_plugin/

+-- public
|   +-- components
|   |   +-- componentName
|   |   |   +-- _index.scss
|   |   |   +-- _component.scss
+-- index.scss

Sass

// Should import both the EUI constants and any Kibana ones that are considered global
@import '_kibana_styling_constants';

// Temporary hacks
@import 'hacks';

// Monitoring plugin styles

// Prefix all styles with "mon" to avoid conflicts.
// Examples
//   monChart
//   monChart__legend
//   monChart__legend--small
//   monChart__legend-isLoading

@import 'components/chart/index';
@import 'components/no_data/index';
@import 'components/sparkline/index';
@import 'components/summary_status/index';
@import 'components/table/index';
@import 'components/logstash/pipeline_viewer/views/index';
@import 'directives/chart/index';
@import 'directives/elasticsearch/shard_allocation/index';

Then in the files themseslves

// ./plugin_component_one.scss
// Use a prefix for the file being built, let's use "mon" for "monitoring"
.monChart__legend--small {
  color: $euiColor;
  width: $euiSize;
}

@euiBreakpoint("xs", "s") {
  ...
}

Sections to convert

For an example conversion, along with some tips please look at https://github.com/elastic/kibana/pull/20995

Xpack plugins

Kibana OSS

Kibana core + Bootstrap

Kibana core work is blocked by https://github.com/elastic/kibana/issues/20859

Kibana core is essentially everything in src/ui/ (which is a lot of files)

KUI

KUI (aka ui_framework) should be audited for unused components. Existing, in use ones should import the EUI global scope so that it matches EUI theming as much as possible.

snide commented 6 years ago

Kibana packages

Core

UI

@cchaos :

25333

Xpack

cchaos commented 6 years ago

Note ---DONE

We also need to remove any .LESS file references to removed files in here: https://github.com/elastic/kibana/blob/95edbcdfbf6d3358bd50d6802859966639c29c46/src/dev/precommit_hook/casing_check_config.js#L106

snide commented 5 years ago

Closing this issue. Outside of some hanger on issues, it's complete and would be better served by smaller, clean up issues.