Scheduler missing 'Adaptive Slot Height' - as with jQuery version

[kachihro]

• Suggestion for improvement

Current behavior

Within the configuration of Scheduler - there is a very useful 'AdaptiveSlotHeight' property for a particular view. This doesn't seem to be included for the REACT version.

Same for the 'eventsPerDay' property (?)
https://demos.telerik.com/kendo-ui/scheduler/adaptive-slot-height

Expected behavior

Can have a Scheduler that re-sizes with more items visible.

Minimal reproduction of the problem with instructions

https://www.telerik.com/kendo-react-ui/components/scheduler/views/month/

Standard for a Scheduler - can't set the HEIGHT of a row

What is the motivation or use case for changing the behavior?

Client/customer is hoping to see more calendar entries, for a specific day.

[simonssspirit]

The item can be found here as well for voting: https://feedback.telerik.com/kendo-react-ui/1451055-scheduler-slot-height-event-height

[Mathdrquinn]

I would also love if this item could be available for the React component.

[kmbro]

As would I. Is there a reason this is closed? the issue that is linked above is also closed -- in fact it is said that it was closed in favor of this issue.

#531 (comment)

[simonssspirit]

@kmbro This issue is not closed, it is still opened and planned.
The linked issue only is closed as they are related and we are closing the duplicate in order to trach the progress at one place: #531

[Mathdrquinn]

@kmbro This issue is not closed, it is still opened and planned.

@simonssspirit by planned do you mean you have a rough delivery date!?!

[simonssspirit]

It is planned for the next release which is May - September.

We have a continuous delivery process and it will be released as soon as it is ready:

https://www.telerik.com/kendo-react-ui/roadmap/

[InaGlushkova]

Requested again under:
1530894

[simonssspirit]

Hello everyone, we would like the apologize and inform you that this item will be delayed and started after the release (mid-September). We planned it for this release, but we also planned the new and very large PivotGrid component which took all of the time for this release cycle. This item is still priority 1 for us and we will start working on it first thing after we release the PivotGrid.

We know that many of you expected this feature and this is why we wanted to inform you early of the delay and apologies for it.

[Mathdrquinn]

Hello everyone, we would like the apologize and inform you that this item will be delayed and started after the release (mid-September). We planned it for this release, but we also planned the new and very large PivotGrid component which took all of the time for this release cycle. This item is still priority 1 for us and we will start working on it first thing after we release the PivotGrid.

We know that many of you expected this feature and this is why we wanted to inform you early of the delay and apologies for it.

Disappointing, but I appreciate the communication. Thank you.

[kspeyanski]

The Scheduler Adaptive Slot Height and Auto Item Height features have been published with 4.10.0@dev version of the @progress/kendo-react-scheduler package.

We will be actively gathering feedback in the next couple of weeks, so please let us know of any concerns might you have.

[Mathdrquinn]

@kspeyanski Thank you for putting this out.

Adaptive Slot Height:
I would love to see the configuration hoisted to the View level like: <WorkWeekView slotDivisions={4} slotHeight="50px" />. Is that possible?

Auto Item Height:
I had expected this to be the enabling native adaptive slot height. So that if slots were in an increments of 30min, a data item beginning at 10min past the hour would shift 1/3 of the way down into the slot. I know there is a hook that can be copied into the project to support this, but native support would be preferred.

These two items together are powerful and would help give my users the most accurate representation of data points within the scheduler.

[kspeyanski]

The Adaptive Slot Height and Auto Item Height features have been released with version v4.10.0 of the @progress/kendo-react-scheduler package.

I'm closing this issue for now. But please let us know if you have any comments/concerns.

[Mathdrquinn]

@kspeyanski ,

Yes my above comment relates that this change is both welcomed and short of expectations.

@kspeyanski Thank you for putting this out.

Adaptive Slot Height: I would love to see the configuration hoisted to the View level like: <WorkWeekView slotDivisions={4} slotHeight="50px" />. Is that possible?

Auto Item Height: I had expected this to be the enabling native adaptive slot height. So that if slots were in an increments of 30min, a data item beginning at 10min past the hour would shift 1/3 of the way down into the slot. I know there is a hook that can be copied into the project to support this, but native support would be preferred.

These two items together are powerful and would help give my users the most accurate representation of data points within the scheduler.

[kspeyanski]

@Mathdrquinn

Thank you once again for sharing your feedback, and please excuse me for not providing further explanation. I will do my best to explain our decisioning now:

In regards to your comments:
Adaptive Slot Height—height is one of many style properties which can be set to a single slot. Hoisted properties are something we would like to avoid in the future, mainly due to code-duplication and API pollution.
Adding properties is easier than removing them, so we would like to gather more feedback before we hoist the slotHeight property. Additionally, there are both KendoReact users who come from Kendo UI for jQuery and ones who's first interaction with Kendo is with the React version. jQuery as a framework does not allow such integrated customizations like the react render props (e.g. slot or item in the context of the Scheduler) where you can provide complete replacements of the original component— thus the API in the Kendo UI for jQuery might differ from the React one.

Auto Item Height: I do agreed that naming features is not optimal, so let me try to clarify the things here: Auto Item Height is related only to items sizing in vertically-agnostic views&mdash: MonthView, WeekView (all days part only) etc, where the height of the item is not in direct correlation to the items start and end properties, but rather the available vertical space in-between it's siblings. What you are describing is another feature (called proportional positioning), which we've previously opened up for discussion here: #680 , but due to lack of feedback both in the public github issue and our Feedback Portal is still in our parking lot.

As always, we do greatly appreciate your feedback and involvement in this discussion so I want to express my intention to openly communicate such changes, so there is a transparency on why we've decided implementing X instead of Y.

[Mathdrquinn]

Thank you for the response @kspeyanski . I'll go advocate for #680 😄 .

Adding properties is easier than removing them, so we would like to gather more feedback before we hoist the slotHeight property.

What feedback can I provide? I'd like to help.

While the power of integrated customization in react is a nice escape hatch, it is a burden on our codebase to copy and amend components. for a single feature. The hoisted APIs are much more friendly.

[kspeyanski]

What I'm mostly trying to understand is what exactly is preventing you from using a separate component, given you can define it on a single like, in the same file, and even inline it like a regular property if you want to. Is there something else that I'm missing, which will help us find the root of the problem?

Additionally, feature slot-related features would be introduced and providing a hoisted properties would not scale well. Just as an example for one of our other components - the Grid, we have the onRowClick property hoisted to the Grid Component—It is a syntax-sugar, but once more-complex use-cases arise (touch events, async focus), it's no longer viable to hoist all available react synthetic events for all available grid internal components (header, footer, row, cell) etc.

Providing a per-component customization is what we would prefer to do, as it's something that contributes to the customization capabilities of the components.

const AutoHeightSlot = (props) => (
    <SchedulerViewSlot {...props} expandable={false} style={{ ...props.style, height: 95 }} /> 
);

(
 <WorkWeekView slotDivisions={4} slotHeight="50px" viewSlot={AutoHeightSlot} />
)

An alternative approach we're also exploring right now is the Props Through Context feature, which we aim to introduce to most KendoReact components, so I would really love to hear your feedback on it (in the linked issue).
An example of how a SchedulerSlot configuration would look live with it, while still verbose, would require no additional declarations from the user:

<SchedulerViewSlotPropsContext.Provider value={(props) => ({...props, style: { height: '75px' }})}>
  <Scheduler>
   <WorkWeekView slotDivisions={4} slotHeight="50px" viewSlot={AutoHeightSlot} />
  </Scheduler>
<SchedulerViewSlotPropsContext.Provider>

Without any intention to discredit your valuable feedback, we would also like to hear from more users of the Scheduler component before proceeding further.

Thank you for being part of this discussion.

[Mathdrquinn]

@kspeyanski thank you for the detailed response.

My desire for a hoisted API is to minimize the surface area between the functionality of my application and the scheduler. The scheduler is quite complex and the benefit of a paid solution is the assurance that it is battle tested and edge cases are covered. When I override a component with my own, I'm increasing complexity while also potentially introducing errors.

I'll take a look into context.