Many member of classes are private in the KendoReact package.
For example, custom filterCells are "all or nothing", as most of GridFilterCell's members are private.
You cannot change the inputElement, as GridFilterCell.filterComponent (and it's dependencies) are private.
For example, it would be nice to be able to override certain members like this:
The default behaviour should be to use protected members, and make members private only when they do not provide a public API.
What is the motivation or use case for changing the behavior?
Customising some of the deeply embedded parts of composite controls either requires examining the source code and working with "private" APIs, or reimplementing a lot of default, useful behaviour. This is especially true in the Grid, but also other controls like DateRangePicker.
The drawback of this approach is that the public API is massively increased, and there is a reliance on class based components at a time when a lot of React is moving away from them.
Alternative are to break up some of the "inner" components to allow for easier reuse in places like GridFilterCellProps.filter/render, or allow passing various render props.
I think that exposing filterComponent option for the GridColumn is a valid request and will allow reusing the operators DropDown and will make customizing the filter component much more easier
I'm submitting a suggestion for improvement
Current behavior
Many member of classes are private in the KendoReact package. For example, custom filterCells are "all or nothing", as most of GridFilterCell's members are private. You cannot change the inputElement, as
GridFilterCell.filterComponent
(and it's dependencies) are private.For example, it would be nice to be able to override certain members like this:
Expected behavior
The default behaviour should be to use protected members, and make members private only when they do not provide a public API.
What is the motivation or use case for changing the behavior?
Customising some of the deeply embedded parts of composite controls either requires examining the source code and working with "private" APIs, or reimplementing a lot of default, useful behaviour. This is especially true in the Grid, but also other controls like DateRangePicker.
Environment
Package versions:
Browser: N/A
System:
The drawback of this approach is that the public API is massively increased, and there is a reliance on class based components at a time when a lot of React is moving away from them. Alternative are to break up some of the "inner" components to allow for easier reuse in places like GridFilterCellProps.filter/render, or allow passing various render props.