Add Typescript type definitions for all components and services

[uboness]

We use this issue to keep track of the components and services that require Typescript type definitions.

Components

• Accessibility
  • EuiKeyboardAccessible
  • EuiScreenReaderOnly
• EuiAccordion
• EuiAvatar
• EuiBadge
• EuiBottomBar
• EuiButton (Initial commit of typescript type definitions for EUI components & services #252)
  • EuiButtonEmpty (Initial commit of typescript type definitions for EUI components & services #252)
  • EuiButtonIcon (Initial commit of typescript type definitions for EUI components & services #252)
• EuiCallOut
• EuiCodeEditor
• EuiCode
  • EuiCodeBlock
• EuiContextMenu
  • EuiContextMenuItem (Initial commit of typescript type definitions for EUI components & services #252)
  • EuiContextMenuPanel (Initial commit of typescript type definitions for EUI components & services #252)
• EuiDescriptionList
• EuiErrorBoundary
• EuiExpression
  • EuiExpressionButton
• Flex (Initial commit of typescript type definitions for EUI components & services #252)
  • EuiFlexGroup
  • EuiFlexItem
  • EuiFlexGrid
• EuiFlyout
  • EuiFlyoutBody
  • EuiFlyoutHeader
  • EuiFlyoutFooter
• Form
  • EuiForm
  • EuiFormRow
  • EuiCheckbox (Initial commit of typescript type definitions for EUI components & services #252)
  • EuiCheckboxGroup (Initial commit of typescript type definitions for EUI components & services #252)
  • EuiFieldNumber
  • EuiFieldPassword
  • EuiFieldSearch (Initial commit of typescript type definitions for EUI components & services #252)
  • EuiFieldText
  • EuiRange
  • EuiRadioGroup
  • EuiSelect
  • EuiSwitch
  • EuiTextArea
• Filter Group
  • EuiFilterButton
• EuiHeader
  • EuiHeaderBreadcrumb
  • EuiHeaderBreadcrumbCollapsed
  • EuiHeaderSection
  • EuiHeaderSectionItem
  • EuiHeaderSectionItemButton
  • EuiHeaderLogo
• EuiHealth
• EuiHorizontalRule
• EuiIcon (Initial commit of typescript type definitions for EUI components & services #252)
• EuiImage
• EuiKeyPadMenu
  • EuiKeyPadMenuItem
  • EuiKeyPadMenuItemButton
• EuiLink (Initial commit of typescript type definitions for EUI components & services #252)
• Loading...
  • EuiLoadingKibana
  • EuiLoadingChart
  • EuiLoadingSpinner
• EuiModal
  • EuiModalBody
  • EuiModalFooter
  • EuiModalHeader
  • EuiModalHeaderTitle
  • EuiConfirmModal
• EuiOutsideClickDetector
• EuiPage
  • EuiPageBody
  • EuiPageContent
  • EuiPageContentBody
  • EuiPageContentHeader
  • EuiPageContentHeaderSection
  • EuiPageHeader
  • EuiPageHeaderSection
  • EuiPageSideBar
• EuiPagination (Initial commit of typescript type definitions for EUI components & services #252)
• EuiPanel (Initial commit of typescript type definitions for EUI components & services #252)
• EuiPopover (Initial commit of typescript type definitions for EUI components & services #252)
  • EuiPopoverTitle
• EuiProgress
• EuiSideNav
• EuiSpacer (Initial commit of typescript type definitions for EUI components & services #252)
• EuiSteps
• EuiTable(Initial commit of typescript type definitions for EUI components & services #252)
  • EuiTableBody
  • EuiTableHeader
  • EuiTableHeaderCell
  • EuiTableHeaderCellCheckbox
  • EuiTablePagination
  • EuiTableRow
  • EuiTableRowCell
  • EuiTableRowCellCheckbox
• EuiTableOfRecords (coming soon...)
  • EuiTableOfRecordsDS (coming soon...)
• ValueRenderers (coming soon...)
• EuiTabs
  • EuiTab
• EuiText
  • EuiTextColor
• EuiTitle
• EuiToast
• TooltipTrigger
• EuiOverlayMask

Services

• alignment.js (Add Typescript type definitions for all components and services #256)
• colors
  • visualization_colors.js
• accessibility
  • accessible_click_keys.js
  • combo_box_key_codes.js
  • html_id_generator.js
• paging
  • pager.js

[pugnascotia]

I started some work to write Flow library definitions for EUI. Would that be of any interest too?

[weltenwort]

In general, sure. But putting the burden on the EUI devs to keep both up-to-date might be inappropriate. 🤔

My expectation was that we would at some point completely convert EUI to typescript.

[pugnascotia]

I did wonder. We're using Flow in Cloud UI, so I'd half-expected we'd keep the libdefs there.

[weltenwort]

Hm, I did not know about that. But given that they have to be maintained anyway, they could just as well live here. I know the feature sets of the two languages are not equivalent, but maybe there is some way to automate this for a subset of features?

[weltenwort]

There is https://github.com/joarwilk/flowgen, but the longer I think about it, the less convinced I am that automation can produce sufficient quality ;)

[pugnascotia]

From the bit of work I've done so far, the types were pretty easy to write, so it might not be so onerous to have both. The risk is that they'd drift, but maybe at some point we could have some automation to check that both TS and Flow definitions change in sync. I'm just thinking out loud.

[weltenwort]

I agree, writing the type definitions is not hard. Making small adjustments for maintenance should be even easier. Noticing that these adjustments are necessary seems to be the biggest challenge.

[uboness]

I see no reason not to have flow type definitions here as well

[snide]

@epixa Can you chime in on here to let us know where typescript support should fit in the priorities for EUI. It's not something @cjcenizal, @cchaos or I consider day to day and if it's a priority for the organization I wanna make sure we have a clear owner of responsibility here. Right now it's pretty much just being done by @uboness and @weltenwort as they need it.

[epixa]

Let's separate short and long term for a moment:

Short term: From a tactical standpoint, the absolute priority right now for EUI should be rapidly building out the missing components, and it seems that is best accomplished using native ecmascript for now. I think it's great that @uboness and @weltenwort are building out typescript definitions in parallel because that will be really helpful to Kibana down the line, but if it is slowing us down in rolling out EUI more extensively, we should shut it down for the time being. I don't think that's the case, though.

Long term: It looks like most of Kibana will be moving to typescript, and we'll be encouraging the community to develop plugins with typescript because we'll be providing type definitions for our plugin contracts. Since we also want plugin developers to make extensive use of EUI, it makes sense for us to support typescript definitions as a first-class feature of EUI. Since contributions from the community are going to increase significantly as this is rolled out more in Kibana, it's likely we'll want to require typescript definitions for all contributions down the line.

We won't be encouraging people to use flow, and there won't be any unique benefits for doing so in our Kibana developer community, so putting the burden on the whole of EUI to maintain them seems heavy handed. The cloud codebase is an exceptional case - it's closed source and is being developed strictly by an internal group of developers, so if that specific team wants to maintain flow definitions for the components they use from EUI, they can without any fragmentation in usage of EUI in our developer community.

If there's enough demand from the developer community for flow definitions, then that's a different story. Then it's just a feature prioritization issue just like any other.

[uboness]

Makes sense... For me.. I just needed a reassurance that we continue moving forward with typescript in kibana. I think for the time being it makes sense that typescript users will update/maintain the type definition as they go. Once kibana moves UI to type script it'd be a good time to officially move this responsibility to the UI team.