2020 Roadmap

[snide]

Our 2019 roadmap #1398

This roadmap includes known and approved projects we're committing to build. Over time it will likely grow.

Core themes

✅ DONE We want EUI to be a 100% TypeScript project #1557

Mostly there. But we'd like to get EUI to become a full TypeScript project early in the year. We're still up in the air for how we should present our docs.

🚧 We want EUI on more platforms with better testing #2760

We're seeing EUI get used beyond Kibana / Cloud and need better tooling and tests to make sure it runs on popular environments like Gatsby and React create app. While we're doing this we'd like to automate how EUI updates in Kibana and provide better ways to test changes on our internal platforms.

🚧 We will continue to play with CSS in JS solutions

Currently, EUI is Sass based, which works fine, but causes some issues for modularization, scoping and theming. We will continue to evaluate the JS solutions and see where it makes sense. The end goal is for EUI to be completely customizable through a web driven interface.

We would like to deliver EUI in a modular fashion

Currently, EUI's footprint is quite large. This is due more to it's legacy as a replacement for Kibana's angular views where we needed a CSS layer to live outside of the JS components. In the future we'd like to deliver EUI as a smaller core package that allows you to individually import additional components. Likely this will lead to EUI becoming a mono-repo of separate packages. This is highly coupled to the CSS in JS initiative listed above.

✅ DONE We are committing to building more features into EuiDataGrid #2504

We see DataGrid as a key part of Kibana over the next year and are planning to add a lot more features to its default kit.

✅ DONE We are building a pluggable markdown editor #3522

We'd like to build a markdown editor and formatter that can be extended with plugins so that each one of our products can include custom embeds that match their needs.

✅ DONE, BUT WORK REMAINS We will focus more on improving our docs

Now that EUI is so large we need to focus on how people find the components they need and how they can use them together. In general we've done a good job at providing examples, but a poor job at providing guidelines. We'd also like to add better search and exploration tools.

We will focus more on accessibility (issues)

There's room for improvement with EUI's accessibility, especially on the larger controls. We will continue to take on accessibility issues over the year and factor accessibility review into everything we build.

Upcoming components and reworks

• Sticky on scroll
• ✅ Resizable pane EuiResizableContainer #2701
• ✅ Expand and integrate EuiSelectable
• ✅ EuIcon runtime caching Add caching layer to EuiIcon #3404
• Better responsive handling in our components

[kenny-f]

any plans for adding storybook? It could help with discoverability.

[cchaos]

@kenny-f No, sorry, there are no plans to use Storybook. We are looking into integrating Elastic App Search though which should help with your concern of discoverability.

[flaviolivolsi]

Hi,
do you know how much focus there will be on EUI's modularization? Is there any plan or any specific measures in mind for it? The bundle size is quite big (over 700k compressed) and I think there could be even just some baby steps to be made to start (for example, the bundle comes with icons that I'll never use, probably the case for many other people).

[snide]

@flaviolivolsi Modularization is roughly tied to our CSS in JS item on the list. We're aware of the bundle size and would like to get to a modular system. That said we're in the exploration stage at the moment and don't have any concrete plans as of yet.

[ryankeairns]

+1 for the sticky component. This came up today while reviewing/planning improvements to Dashboard.

[anishagg17]

@snide can you give some example preview of Eui MDX-style editor or some reference to it. I am interested in building it

[chandlerprall]

@anishagg17 because of the size and complexity of that component's design & implementation, we are building it internally (already in progress, behind the scenes).

[anishagg17]

@chandlerprall is there any component that I could work upon?

[chandlerprall]

@anishagg17 unfortunately we don't have anything else ready to go; however, if you're looking for more than the existing issues we have, there is a lot of room to improve our coverage of our unit tests. Most of our components have a basic "is rendered" snapshot, without checking any functionality and I'm sure many are missing a lot of different input prop permutations. If you want to go really crazy, checking out react-test-renderer as a replacement for enzyme has been on my list for a while - I'd be happy to review anything you may find in that area.

[seeruk]

I've been thinking about the CSS-in-JS part of this a fair bit, wouldn't CSS modules also work, along with CSS variables? That way there's no need to pull in another library, and it would work well out of the box with create-react-app. You'd still get scoping and modularisation with it too.

[chandlerprall]

A key requirement we have is supporting multiple themes and allowing overriding/customizing those in applications. Today this is solved by shipping full, static builds for each theme and those can be overridden by the application by doing a custom build (not great, but it supports the requirement). We have a lot of layers of SCSS variables / mixins which adds that dynamism (at build time), and are looking to maintain that kind of dependency behaviour.

A few issues:

• CSS Modules does not (to my knowledge) provide this level of configurability
• Our browser support includes IE11 which means we cannot rely on CSS variables
• Even if we had CSS variables, a lot of our theming is based on color-space math & manipulation, which I don't believe is replicatable in CSS

[bkniffler]

Is there any news about CSS in JS? I know this will be tough to tackle, but I can't wait for this to happen.

Also, in terms of bundle size, moving away from momentjs would reduce the size drastically. MomentJS is around 250kb in bundle size, while a library like dayjs is around 6kb. Yes, sure, you can do some hacky stuff through Webpack to reduce locale support of momentjs, but still.

[chandlerprall]

Is there any news about CSS in JS? I know this will be tough to tackle, but I can't wait for this to happen.

We are proceeding with a trial around Emotion, and expect to start rolling out changes starting in the next few months. We have been experimenting with the best way to set up our theming, while still allowing applications to modify/overwrite those values. The next testing step will take place in a couple of weeks.

Also, in terms of bundle size, moving away from momentjs would reduce the size drastically. MomentJS is around 250kb in bundle size, while a library like dayjs is around 6kb. Yes, sure, you can do some hacky stuff through Webpack to reduce locale support of momentjs, but still.

👍 while this isn't part of our roadmap, I don't think anyone disagrees. Unfortunately we cannot take this on right now.

[ndt94]

Maybe take a look at styled-jsx, i'm using eui w next and think it's great

[fongfai]

Is there anything news about modularization?

[cchaos]

Hi @fongfai , The modularization effort is dependent on our switch to using Emotion (CSS in JS). This is a long-haul effort that most likely will take the better half of 2021. You can track the progress here: #3912

[chandlerprall]

Closing this for the 2021 roadmap in #4054, which we will fill out more over the next week or two. The uncompleted items are in progress, with CSS-in-JS + Emotion as our focus right now.