Add Typescript type definitions for all components and services #256
Comments
|
I started some work to write Flow library definitions for EUI. Would that be of any interest too? |
|
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. |
|
I did wonder. We're using Flow in Cloud UI, so I'd half-expected we'd keep the libdefs there. |
|
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? |
|
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 ;) |
|
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. |
|
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. |
|
I see no reason not to have flow type definitions here as well |
|
@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. |
|
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. |
|
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. |
|
Maybe something like this could work. cc @mattapperson who brought it up in channel. https://www.npmjs.com/package/react-to-typescript-definitions |
|
IMO that will do injustice to the ts definitions. With ts you can be much more expressive than with propTypes. (Eg. use generics) |
|
@uboness propTypes can be more expressive then generics as well. Is there something you could point to as an example of an ideal with react components having a definition? |
|
I need to be clearer with my comments :)
declare module '@elastic/eui' {
export type ItemCallback<Item, Return> = (item: Item) => Return;
export type ItemValueCallback<Value, Item, Return> = (value: Value, item: Item) => Return;
export namespace EuiBasicTable {
export type ColumnDataType = 'string' | 'number' | 'boolean' | 'date';
export interface FieldDataColumn<Item> {
field: string;
name: string;
description?: string;
dataType?: ColumnDataType;
width?: string;
sortable?: boolean;
align?: HorizontalAlignment;
truncateText?: boolean;
render?: ItemValueCallback<any, Item, ReactNode>;
}
export interface ComputedColumn<Item> {
render: ItemCallback<Item, ReactNode>;
name?: string;
description?: string;
width?: string;
truncateText?: boolean;
}
export interface DefaultItemAction<Item> {
name: string;
description: string;
onClick: ItemCallback<Item, void>;
type?: 'button' | 'icon';
available?: ItemCallback<Item, boolean>;
enabled?: ItemCallback<Item, boolean>;
icon?: IconType | ItemCallback<Item, IconType>;
color?: ButtonIconColor | ItemCallback<Item, ButtonIconColor>;
}
export interface CustomItemAction<Item> {
render: (item: Item, enabled: boolean) => ReactNode;
available: ItemCallback<Item, boolean>;
enabled: ItemCallback<Item, boolean>;
}
export type ItemAction<Item> = DefaultItemAction<Item> | CustomItemAction<Item>;
export interface ActionsColumn<Item> {
actions: ItemAction<Item>[];
name?: string;
description?: string;
width?: string;
}
export type Column<Item> = FieldDataColumn<Item> | ComputedColumn<Item> | ActionsColumn<Item>;
export type ItemId<Item> = string | ((item: Item) => string);
export interface Selection<Item> {
itemId: ItemId<Item>;
onSelectionChanged?: (selection: Item[]) => void;
selectable?: ItemCallback<Item, boolean>;
selectableMessage?: ItemValueCallback<boolean, Item, string>;
}
export interface Sorting {
sort?: PropertySort;
}
export interface Pagination {
pageIndex: number;
pageSize: number;
totalItemCount: number;
pageSizeOptions?: number[]
}
export interface DataCriteria {
page?: {
index: number;
size: number;
},
sort?: PropertySort
}
}
export interface EuiBasicTableProps<Item> {
items: Item[];
columns: EuiBasicTable.Column<Item>[];
pagination?: EuiBasicTable.Pagination;
sorting?: EuiBasicTable.Sorting;
selection?: EuiBasicTable.Selection<Item>;
onChange?: (criteria: EuiBasicTable.DataCriteria) => void;
error?: string;
loading?: boolean;
noItemsMessage?: string;
className?: string;
}
export class EuiAbstractBasicTable<Item> extends React.Component<CommonProps & EuiBasicTableProps<Item>, {}> {}
export class EuiBasicTable extends EuiAbstractBasicTable<any> {}
}So restating my previous comment - If we can use an automated tool to convert prop-types to TS definitions, that'd be great... but with that, we'll need to make sure we have an escape hatch to override it and create our own definitions for any component we see fit. |
|
@uboness ah I see what your saying now. Thanks for the additional detail :) I think I see the options as:
In sounds like you @uboness favor option 4? Did I forget an option or did I misstate any of the above? |
|
@mattapperson I think you're pretty much spot on.
In a way... I do hoping that most of the low level components will be auto-synced and for the HoC we'll be responsible enough to update it occasionally (I don't think it's the end of the world if the type defs are a bit behind, as long as when ppl pick up on missing defs/props, they'll go and add them... yes, it requires discipline)
we've discussed this in the past, and I think the general direction is that eventually we would want to move to TS across the board. But that will take time, and at this point, there's so much (more important) work to be done in EUI that it's really not a high priority now. That said, I would agree that it'll be great if the EUI engs will start looking and learning TS and maybe even try to use it and build a few components in TS... they might like what they'll see and before you know it, TS will be the new default. |
|
Closing this. The component list&progress is out of date, and EUI now supports authoring components in TypeScript - we are starting to convert components over. |
We use this issue to keep track of the components and services that require Typescript type definitions.
Components
AccessibilityEuiKeyboardAccessibleEuiScreenReaderOnlyEuiAccordionEuiAvatarEuiBadgeEuiBottomBarEuiButton(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)EuiCallOutEuiCodeEditorEuiCodeEuiCodeBlockEuiContextMenuEuiContextMenuItem(Initial commit of typescript type definitions for EUI components & services #252)EuiContextMenuPanel(Initial commit of typescript type definitions for EUI components & services #252)EuiDescriptionListEuiErrorBoundaryEuiExpressionEuiExpressionButtonFlex(Initial commit of typescript type definitions for EUI components & services #252)EuiFlexGroupEuiFlexItemEuiFlexGridEuiFlyoutEuiFlyoutBodyEuiFlyoutHeaderEuiFlyoutFooterFormEuiFormEuiFormRowEuiCheckbox(Initial commit of typescript type definitions for EUI components & services #252)EuiCheckboxGroup(Initial commit of typescript type definitions for EUI components & services #252)EuiFieldNumberEuiFieldPasswordEuiFieldSearch(Initial commit of typescript type definitions for EUI components & services #252)EuiFieldTextEuiRangeEuiRadioGroupEuiSelectEuiSwitchEuiTextAreaFilter GroupEuiFilterButtonEuiHeaderEuiHeaderBreadcrumbEuiHeaderBreadcrumbCollapsedEuiHeaderSectionEuiHeaderSectionItemEuiHeaderSectionItemButtonEuiHeaderLogoEuiHealthEuiHorizontalRuleEuiIcon(Initial commit of typescript type definitions for EUI components & services #252)EuiImageEuiKeyPadMenuEuiKeyPadMenuItemEuiKeyPadMenuItemButtonEuiLink(Initial commit of typescript type definitions for EUI components & services #252)Loading...EuiLoadingKibanaEuiLoadingChartEuiLoadingSpinnerEuiModalEuiModalBodyEuiModalFooterEuiModalHeaderEuiModalHeaderTitleEuiConfirmModalEuiOutsideClickDetectorEuiPageEuiPageBodyEuiPageContentEuiPageContentBodyEuiPageContentHeaderEuiPageContentHeaderSectionEuiPageHeaderEuiPageHeaderSectionEuiPageSideBarEuiPagination(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)EuiPopoverTitleEuiProgressEuiSideNavEuiSpacer(Initial commit of typescript type definitions for EUI components & services #252)EuiStepsEuiTable(Initial commit of typescript type definitions for EUI components & services #252)EuiTableBodyEuiTableHeaderEuiTableHeaderCellEuiTableHeaderCellCheckboxEuiTablePaginationEuiTableRowEuiTableRowCellEuiTableRowCellCheckboxEuiTableOfRecords(coming soon...)EuiTableOfRecordsDS(coming soon...)ValueRenderers(coming soon...)EuiTabsEuiTabEuiTextEuiTextColorEuiTitleEuiToastTooltipTriggerEuiOverlayMaskServices
alignment.js(Add Typescript type definitions for all components and services #256)visualization_colors.jsaccessible_click_keys.jscombo_box_key_codes.jshtml_id_generator.jspager.jsThe text was updated successfully, but these errors were encountered: