kibana/packages/kbn-ui-framework
Tiago Costa 20bdf7d4a9
Migration to Babel7 and @babel/preset-typescript (#33093)
* chore(NA): first changes on every package.json order to support new babel 7. chore(NA): build for kbn-pm with babel 7.

* chore(NA): patch babel register to load typescrit

* chore(NA): first working version with babel 7 replacing typescript compiler.

* fix(NA): common preset declaration in order to make it work with babel-loader.

* chore(na): organizing babel preset env package json.

* chore(NA): mocha tests enabled.

* fix(NA): typo on importing

* test(NA): majority of x-pack tests ported to use babel-jest

* fix(NA): report info button test with babel-jest.

* fix(NA): polling service tests.

* test(na): fix server plugins plugin tests.

* test(NA): batch of test fixs for jest tests under babel-jest hoisting.

* chore(NA): add babel plugin to hoist mock prefixed vars on jest tests.

* chore(NA): update yarn.lock file.

* chore(NA): tests passing.

* chore(NA): remove wrong dep

* chore(NA): fix tsconfig

* chore(NA): skip babel for ts-jest.

* chore(NA): selectively apply the plugin to strip off namespace from ts files.

* chore(NA): remove not needed changes from ts tests

* chore(NA): removed ts-jest dependency. chore(NA): migrate ts tests on x-pack to use babel-jest with the new pattern.

* chore(NA): migrate kibana default distribution typescript tests to run with babel-jest and the new test mock pattern.

* chore(NA): merge and solve conflicts with master.

* chore(NA): fix problems reported by eslint

* chore(NA): fix license ovveride for babel-plugin-mock-imports

* chore(NA): update jest integration tests for kbn pm

* chore(NA): update babel jest integration tests for kbn pm.

* test(NA): update jest integration snapshot for kbn pm.

* chore(NA): apply changes according to the pull request reviews.

* chore(NA): apply changes according to the pull request reviews.

* refact(NA): migrate jest tests to the new pattern.

* fix(NA): babel 7 polyfill in the tests bundle.

* chore(NA): restore needed step in order to compile x-pack with typescript.

* chore(NA): change build to compile typescript with babel for the oss code. chore(NA): change transpile typescript task to only transpile types for x-pack. refact(NA): common preset for babel 7

* Revert "chore(NA): change build to compile typescript with babel for the oss code. chore(NA): change transpile typescript task to only transpile types for x-pack. refact(NA): common preset for babel 7"

This reverts commit 2707d538f5.

* fix(NA): import paths for tabConfigConst

* chore(NA): fix transpiling error on browser tests

* chore(NA): simplify kbn babel preset package.

* chore(NA): migrate build to use babel transpiler for typescript excluding xpack.

* fix(NA): introduced error on test quick task.

* fix(NA): fix preset for client side code on build.

* fix(NA): build with babel

* fix(NA): negated patterns in the end.

* fix(NA): kbn_tp_sample_panel_action creation.

* fix(NA): babel typescript transform plugin workaround when exporting interface name.

* refact(NA): remove not needed type cast to any on jest test.

* docs(NA): add developement documentation about jest mocks test pattern.

* chore(NA): missing unmerged path.

* chore(NA): fix jest tests for template.

* [CCR] Client integration tests (table lists) (#33525)

* Force user to re-authenticate if token refresh fails with `400` status code. (#33774)

* Improve performance of the Logstash Pipeline Viewer (#33793)

Resolves #27513.

_This PR is a combination of #31293 (the code changes) + #33570 (test updates). These two PRs were individually reviewed and merged into a feature branch. This combo PR here simply sets up the merge from the feature branch to `master`._

Summary of changes, taken from #31293:

## Before this PR
The Logstash Pipeline Viewer UI would make a single Kibana API call to fetch all the information necessary to render the Logstash pipeline. This included information necessary to render the detail drawer that opens up when a user clicks on an individual vertex in the pipeline.

Naturally, this single API call fetched _a lot_ of data, not just from the Kibana server but also, in turn, from Elasticsearch as well. The "pro" of this approach was that the user would see instantaneous results if they clicked on a vertex in a pipeline and opened the detail drawer for that vertex. The "cons" were the amount of computation Elasticsearch had to perform and the amount of data being transferred over the wire between Elasticsearch and the Kibana server as well as between the Kibana server and the browser.

## With this PR
This PR makes the Kibana API call to fetch data necessary for **initially** rendering the pipeline — that is, with the detail drawer closed — much lighter. When the user clicks on a vertex in a pipeline, a second API call is then made to fetch data necessary for the detail drawer.

## Gains, by the numbers

Based on a simple, 1-input, 1-filter, and 1-output pipeline.

* Before this PR, the Elasticsearch `logstash_stats` API responses (multiple calls were made using the `composite` aggregation over the `date_histogram` aggregation) generated a total of 1228 aggregation buckets (before any `filter_path`s were applied but across all `composite` "pages"). With this PR, the single `logstash_stats` API response (note that this is just for the initial rendering of the pipeline, with the detail drawer closed) generated 12 buckets (also before any `filter_path`s were applied). That's a **99.02% reduction** in number of buckets.

* Before this PR, the Elasticsearch `logstash_stats` API responses added up to 70319 bytes. With this PR, the single `logstash_stats` API response for the same pipeline is 746 bytes. That's a **98.93% reduction** in size.

* Before this PR, the Elasticsearch `logstash_state` API response was 7718 bytes. With this PR, the API response for the same pipeline is 2328 bytes. That's a **69.83% reduction** in size.

* Before this PR the Kibana API response was 51777 bytes. With this PR, the API response for the same pipeline is 2567 bytes (again, note that this is just for the initial rendering of the pipeline, with the detail drawer closed). That's a **95.04% reduction** in size.

* [Maps] split settings into layer and source panels (#33788)

* [Maps] split settings into layer and source panels

* fix SCSS import

* [env] exit if starting as root (#21563)

* [env] exit if starting as root

* fix windows

* s/--allow-root

* Typescript sample panel action (#33602)

* Typescript sample panel action

* Update EUI version to match main cabana version

* update yarn.lock

* add back typings include

* use correct relative path

* Home page "recent links" should communicate saved object type #21896 (#33694)

* adds object type for screen order
* adds object type for pointer hovering
* Update src/legacy/ui/public/chrome/directives/header_global_nav/components/header.tsx

Co-Authored-By: rockfield <philipp.b@ya.ru>
2019-03-26 20:44:03 +00:00
..
components Apache 2.0 license headers (#19383) 2018-05-28 20:06:30 -07:00
dist Eui/9.2.1 + better dark mode (#32728) 2019-03-11 12:36:06 -07:00
doc_site Migration to Babel7 and @babel/preset-typescript (#33093) 2019-03-26 20:44:03 +00:00
generator-kui Apache 2.0 license headers (#19383) 2018-05-28 20:06:30 -07:00
src Fixes focus state issue around EUI combo boxes in kibana (#33073) 2019-03-13 11:58:00 -07:00
Gruntfile.js KUI Dark mode (#28975) 2019-01-22 13:26:49 -08:00
package.json Migration to Babel7 and @babel/preset-typescript (#33093) 2019-03-26 20:44:03 +00:00
README.md Point to EUI for SASS/CSS guidelines (#27415) 2018-12-18 14:39:38 -05:00

Kibana UI Framework

The Kibana UI Framework is a collection of React UI components for quickly building user interfaces for Kibana. Not using React? No problem! You can still use the CSS behind each component.

Using the Framework

Documentation

Compile the CSS with ./node_modules/grunt/bin/grunt uiFramework:compileCss (OS X) or .\node_modules\grunt\bin\grunt uiFramework:compileCss (Windows).

You can view interactive documentation by running yarn uiFramework:start and then visiting http://localhost:8020/. This will also start watching the SCSS files, and will recompile the CSS automatically for you when you make changes.

You can run node scripts/jest --watch to watch for changes and run the tests as you code.

You can run node scripts/jest --coverage to generate a code coverage report to see how fully-tested the code is.

See the documentation in scripts/jest.js for more options.

Creating components

There are four steps to creating a new component:

  1. Create the SCSS for the component in packages/kbn-ui-framework/src/components.
  2. Create the React portion of the component.
  3. Write tests.
  4. Document it with examples in packages/kbn-ui-framework/doc_site.

You can do this using Yeoman (the easy way), or you can do it manually (the hard way).

Using Yeoman

Create a new component

From the command line, run yarn uiFramework:createComponent.

First, you'll be prompted for what kind of component to create:

Choice Description
Stateless function A stateless functional React component
Component class A class-based React component

Next, you'll enter a series of prompts.

"What's the name of this component?"

Yeoman will ask you what to name the file. It expects you to provide the name in snake case. Yeoman will automatically add file extensions and a "kui" prefix so you should leave those out.

"Where do you want to create this component's files?"

This defaults to the last directory you specified for this prompt, or to the UI Framework's components directory if you haven't specified one. To change this location, type in the path to the directory where the files should live.

If you want Yeoman to automatically generate a directory to organize the files, that directory will be created inside of the location you specify (see next prompt).

"Does it need its own directory?""

This defaults to YES. This will automatically generate a directory with the same name as the file, but without a "kui" prefix.

Done!

Yeoman will generate the files you need in your project's folder system.

For your convenience, it will also output some snippets you can tweak to import and re-export the generated JS and SCSS files.

Manually

Create component SCSS

  1. Create a directory for your component in packages/kbn-ui-framework/src/components.
  2. In this directory, create _{component name}.scss.
  3. Optional: Create any other components that should be logically-grouped in this directory.
  4. Create an _index.scss file in this directory that import all of the new component SCSS files you created.
  5. Import the _index.scss file into packages/kbn-ui-framework/src/components/index.scss.

This makes your styles available to Kibana and the UI Framework documentation.

Create the React component

  1. Create the React component(s) in the same directory as the related SCSS file(s).
  2. Export these components from an index.js file.
  3. Re-export these components from packages/kbn-ui-framework/src/components/index.js.

This makes your React component available for import into Kibana.

Test the component

  1. Start Jest in watch mode by running node scripts/jest --watch.
  2. Create test files with the name pattern of {component name}.test.js.
  3. Write your tests and see them fail or succeed.

To see how well the components have been covered by tests, you can run node scripts/jest --coverage and check the generated report in target/jest-coverage/index.html.

Document the component with examples

  1. Create a directory for your example in packages/kbn-ui-framework/doc_site/src/views. Name it the name of the component.
  2. Create a {component name}_example.js file inside the directory. You'll use this file to define the different examples for your component.
  3. Add the route to this file in packages/kbn-ui-framework/doc_site/src/services/routes/Routes.js.
  4. In the {component name}_example.js file you created, define examples which demonstrate the component and describe its role from a UI perspective.

The complexity of the component should determine how many examples you need to create, and how complex they should be. In general, your examples should demonstrate:

  • The most common use-cases for the component.
  • How the component handles edge cases, e.g. overflowing content, text-based vs. element-based content.
  • The various states of the component, e.g. disabled, selected, empty of content, error state.

Creating documentation

You can use the same Yeoman generator referenced above to create documentation.

From the command line, run yarn uiFramework:documentComponent.

First, you'll be prompted for what kind of documentation to create:

Choice Description
Page A page for documenting a component(s) with multiple demos
Page demo An individual demo of a particular component use case
Sandbox An empty document where you can do pretty much anything

Just follow the prompts and your documentation files will be created. You can use the snippets that are printed to the terminal to integrate these files into the UI Framework documentation site.

Principles

Logically-grouped components

If a component has subcomponents (e.g. ToolBar and ToolBarSearch), tightly-coupled components (e.g. Button and ButtonGroup), or you just want to group some related components together (e.g. TextInput, TextArea, and CheckBox), then they belong in the same logical grouping. In this case, you can create additional SCSS files for these components in the same component directory.

Benefits

Dynamic, interactive documentation

By having a "living style guide", we relieve our designers of the burden of creating and maintaining static style guides. This also makes it easier for our engineers to translate mockups, prototypes, and wireframes into products.

Copy-pasteable UI

Engineers can copy and paste sample code into their projects to quickly get reliable, consistent results.

Remove CSS from the day-to-day

The CSS portion of this framework means engineers don't need to spend mental cycles translating a design into CSS. These cycles can be spent on the things critical to the identity of the specific project they're working on, like architecture and business logic.

If they use the React components, engineers won't even need to see CSS -- it will be encapsulated behind the React components' interfaces.

More UI tests === fewer UI bugs

By covering our UI components with great unit tests and having those tests live within the framework itself, we can rest assured that our UI layer is tested and remove some of that burden from our integration/end-to-end tests.

Why not just use Bootstrap?

In short: we've outgrown it! Third-party CSS frameworks like Bootstrap and Foundation are designed for a general audience, so they offer things we don't need and don't offer things we do need. As a result, we've been forced to override their styles until the original framework is no longer recognizable. When the CSS reaches that point, it's time to take ownership over it and build your own framework.

We also gain the ability to fix some of the common issues with third-party CSS frameworks:

  • They have non-semantic markup.
  • They deeply nest their selectors.

For a more in-depth analysis of the problems with Bootstrap (and similar frameworks), check out this article and the links it has at the bottom: "Bootstrap Bankruptcy".

Examples of other in-house UI frameworks