Just as a first note, the documentation on how to write a custom `messagesMap` function for use in the `Pager` component is extremely vague. Without access to the KendoReact source code, it would have been near impossible.
First request: on the `GridProps` API page, the `pager` prop is defined as being the type "null" or `ComponentType<PagerProps>`. Please convert the text "ComponentType<PagerProps>" into a link to the `PagerProps` page. This will greatly aid in quickly linking to the appropriate documentation.
Second request (and the bulk of the feature request): please make (at least) the pager-related constants and default messages (string templates) available to consuming components. As of v5.4.0 of `@progress/kendo-react-data-tools`, the constants are exported from {kendo-react-private}/packages/datatools/src/messages/index.ts and they are consumed within the `Pager` (and subcomponents), but are not re-exported.
Not having access to the pager-related constants (`pagerInfo`, `pagerFirstPage`, `pagerPreviousPage`, `pagerNextPage`, `pagerLastPage`, `pagerItemPerPage`, `pagerPage`, `pagerOf` and `pagerTotalPages`) means it's a complete shot in the dark at how to write an override function to supply as the `messagesMap` prop. Not only that, but without access to the pager-related default messages (string templates) and given the way the `Pager`'s `render` method is written, we are unable to change just one or just a couple messages; we have to address all nine.
Right now in v5.4.0, the way the `Pager`'s `render` method is written, it simply checks to see if `messagesMap` is non-null (lines 214 through 223 of Pager.tsx, lines 38-43 of PagerInput.tsx and lines 36 and 37 of PagerPageSizes.tsx). This means that if we pass in a custom function for `messagesMap`, the custom function will be used to evaluate the message/string-template for `pagerFirstPage`, `pagerPreviousPage`, `pagerNextPage`, `pagerLastPage`, `pagerInfo`, `pagerPage`, `pagerOf`, `pagerTotalPages` and `pagerItemPerPage` (just in those three, aforementioned files). This means that we have to somehow know that `pagerInfo`, for example, will come through to the custom function as the string "pager.info" or that `pagerPage` will come through as "pager.page" so that the custom function knows which `messageKey` it's being passed so it can send out the object with the appropriate message/string-template as the object's `defaultMessage` property.
Instead, if the pager-related constants and default messages were exposed, we could very easily write a custom `messagesMap` function that could address any number of the nine default messages.
As an example, the Telerik/Kendo default string template for `pagerInfo` is "{0} - {1} of {2} items" that could be better scoped to the type of data the grid shows. Let's say the grid displays products and we'd like the pager to show "Displaying products 5 - 10 of 302" in the bottom right. If the pager-related constants and messages were exposed, this becomes a very simple task while not disturbing all other Telerik/Kendo default messages:
import React from 'react';
import { Grid, GridColumn, GridNoRecords, GridColumnMenuFilter } from '@progress/kendo-react-grid';
import { pagerInfo, pagerOf, messages as defaultPagerMessages, Pager } from '@progress/kendo-react-data-tools';
export default function MyComponent() {
const customMessagesMap = messageKey => {
switch (messageKey) {
case pagerInfo: return { messageKey, defaultMessage: 'Displaying products {0} - {1} of {2}' };
default: return { messageKey, defaultMessage: defaultPagerMessages[messageKey] };
}
};
const CustomPager = () => (
<Pager
skip={...}
take={...}
total={...}
buttonCount={...}
type="numeric"
info={true}
pageSizes={[...]}
messagesMap={customMessagesMap}
);
return (
<div className='my-component'>
<Grid data={[...]} pager={CustomPager}>
<GridColumn ... />
</Grid>
</div>
);
};