wix
Now indicator appears ahead of time when TimelineProps start is not 0
I'm trying to get the Timeline to show only from 8h to 18h. Changing the TimelineProps start variable to 8 causes the now indicator to show 8 hours ahead of time.
It is now 1h:27m and the indicator shows 9h:27m
Resetting it to 0 makes it behave normally. Using v1.1297.0.
I did a bit of digging and it seems that the now indicator offset doesn't take into account the start prop, so its position will always be incorrect when the start is not 0. I was able to fix this with the following code.
-
Inject start prop in the NowIndicator component
{indexOfToday !== -1 && showNowIndicator && <NowIndicator startOffset={props.start} width={width / numberOfDays} left={left} styles={styles.current}/>}File - /src/timeline/Timeline.js Line 89 -
Receive the new prop in the component
const { styles, width, left, startOffset } = props;File - /src/timeline/NowIndicator.js Line 6 -
Calculate the correct offset
if(startOffset){ indicatorPosition = calcTimeOffset(HOUR_BLOCK_HEIGHT) - calcTimeOffset(HOUR_BLOCK_HEIGHT, startOffset) + calcTimeOffset(HOUR_BLOCK_HEIGHT, 0, new Date().getMinutes()); }File - /src/timeline/NowIndicator.js Line 8
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
We are having the exact same issue!
It seems a PR has been submitted that fixes this issue: #2401 Can someone from @wix @contributors please have a look and review.
I had to manually apply the change and patch it until the fix is merged, but thanks for calling out the fix @jerone š
Hello,
Iām working with the TimelineList component and encountered an issue when using the start and end properties in timelineProps.
When I set startHour and endHour to visually trim the calendar (e.g., from 8:00 AM to 8:00 PM), the logic for handling time selection breaks. Specifically, when a user tries to create an appointment by selecting a time(using onBackgroundLongPress), the returned time is shifted several hours earlier than expected. It seems like the start and end settings are impacting the underlying time logic of the TimelineList, which causes a mismatch in the actual time versus what is displayed.
In the screenshots bellow you can see I select an empty cell with start time 12:00 and the calendar returns 05:00.
Interestingly, when the start and end properties are not set, everything works perfectly ā the time from the selected cell matches the expected time when creating appointments, but there are a lot of unnecessary visible hours I want gone. However, when I limit the visible hours, the logic for determining the correct time from a cell breaks.
The ideal solution would be to maintain the ability to trim the visible hours while ensuring that the time selection logic still works as expected. Has anyone experienced this issue or found a workaround?
Fragments of my code : <TimelineList timelineProps={{ start: 8, end: 20, unavailableHoursColor: "rgb(235, 235, 235)", onBackgroundLongPress: handleBackgroundLongPress, unavailableHours: unavailableHours, onEventPress(event) { openEventModal(event); }, renderEvent: renderEvent, theme: customTheme, }} events={events} showNowIndicator scrollToFirst = {true} initialTime={INITIAL_TIME} />
-------------------------------------------------------------------------
const handleBackgroundLongPress = useCallback(
(timeString: string | null) => {
if (!timeString) {
console.error("Received null or undefined timeString:", timeString);
return;
}
const selectedTime = DateTime.fromFormat(timeString, "yyyy-MM-dd HH:mm:ss", { zone: 'utc' });
if (!selectedTime.isValid) {
console.error(`Invalid DateTime after parsing: the input "${timeString}" can't be parsed as ISO 8601`);
} else {
setNewAppointment((prev) => ({
...prev,
start: selectedTime.toISO(),
}));
setDisplayedDate(selectedTime.toFormat("dd MMMM, HH:mm"));
openModal();
}
},
[openModal]
);
Thank you in advance!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
