[WEB-2442] feat: Minor Timeline view Enhancements #5987
Conversation
WalkthroughThe changes in this pull request primarily enhance the functionality and logic of the Gantt chart and timeline components. Key modifications include the addition of a new method in the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant GanttChart
participant BaseTimeLineStore
participant Block
User->>GanttChart: Interacts with Gantt chart
GanttChart->>BaseTimeLineStore: Request position from date
BaseTimeLineStore->>BaseTimeLineStore: Calculate position using getPositionFromDate
BaseTimeLineStore-->>GanttChart: Return calculated position
GanttChart->>Block: Render block at position
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
rahulramesha
changed the title
rahulramesha
added
🌐frontend
🐛bug
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (24)
web/core/components/gantt-chart/constants.ts (1)
9-10: Consider adding documentation and flexibility to the block width constant.While the constant follows the established naming pattern, consider these improvements:
- Add a comment explaining its purpose and unit (pixels)
- Consider making it configurable based on viewport width or content requirements, especially for the new sticky block name feature
+// Default width (in pixels) for timeline blocks. Used for calculating block dimensions and scroll positions. export const DEFAULT_BLOCK_WIDTH = 60;web/core/components/gantt-chart/sidebar/modules/block.tsx (1)
Line range hint
41-47: Consider enhancing date visibility for better UXSince the PR aims to support blocks with either Start or End date, consider enhancing the UI to show which date is available when only one is present. This would improve user understanding of partially configured blocks.
Consider updating the duration display:
<div className="flex-grow truncate"> <ModuleGanttSidebarBlock moduleId={block.data.id} /> </div> - {duration !== undefined && ( + {(block.start_date || block.target_date) && ( <div className="flex-shrink-0 text-sm text-custom-text-200"> - {duration} day{duration > 1 ? "s" : ""} + {duration !== undefined ? ( + `${duration} day${duration > 1 ? "s" : ""}` + ) : ( + `${block.start_date ? "Started" : "Due"}` + )} </div> )}web/core/components/gantt-chart/sidebar/issues/block.tsx (1)
Line range hint
89-95: Consider these enhancements for better maintainabilityThe duration display logic could be improved for better maintainability and accessibility.
Consider these improvements:
+const getDurationText = (days: number) => `${days} day${days > 1 ? 's' : ''}`; {duration && ( <div className="flex-shrink-0 text-sm text-custom-text-200"> - <span> - {duration} day{duration > 1 ? "s" : ""} - </span> + <span aria-label={`Duration: ${getDurationText(duration)}`}> + {getDurationText(duration)} + </span> </div> )}web/core/components/gantt-chart/blocks/block.tsx (2)
52-53: Update comment to match the actual visibility logic.The current comment suggests checking for both dates, but the code actually checks for either date.
- // hide the block if it doesn't have start and target dates and showAllBlocks is false + // hide the block if it doesn't have either start or target date and showAllBlocks is false
67-67: Consider using transform for better performance.Using
marginLefttriggers layout recalculation. For better performance, especially during animations, consider usingtransform: translateX()which leverages GPU acceleration.- marginLeft: `${block.position?.marginLeft}px`, + transform: `translateX(${block.position?.marginLeft}px)`,web/core/components/gantt-chart/chart/views/week.tsx (2)
Line range hint
19-91: Consider breaking down the component for better maintainability.The component has multiple nested sections handling different concerns. Consider extracting these into separate components:
- WeekHeader (lines 25-54)
- WeekDayColumns (lines 71-89)
This would improve readability and make the code more maintainable.
Example structure:
interface WeekHeaderProps { block: IWeekBlock; dayWidth: number; rootIndex: number; } const WeekHeader: FC<WeekHeaderProps> = ({ block, dayWidth, rootIndex }) => { // Header implementation }; interface WeekDayColumnsProps { block: IWeekBlock; dayWidth: number; rootIndex: number; } const WeekDayColumns: FC<WeekDayColumnsProps> = ({ block, dayWidth, rootIndex }) => { // Day columns implementation };
Line range hint
31-33: Consider extracting magic numbers to constants.The hardcoded values in styles could be moved to constants for better maintainability:
h-7for month title heighth-5for days subtitle heightconst MONTH_TITLE_HEIGHT = 'h-7'; const DAYS_SUBTITLE_HEIGHT = 'h-5';Also applies to: 45-47
web/core/components/gantt-chart/sidebar/gantt-dnd-HOC.tsx (2)
37-37: Extract "GANTT_REORDER" into a constant.Consider defining this identifier as a named constant at the module level for better maintainability and reusability.
+const GANTT_REORDER_IDENTIFIER = "GANTT_REORDER"; + // ...inside component -getInitialData: () => ({ id, dragInstanceId: "GANTT_REORDER" }), +getInitialData: () => ({ id, dragInstanceId: GANTT_REORDER_IDENTIFIER }),
47-47: LGTM! Consider using the suggested constant.The additional check for
dragInstanceIdis a good safety measure to ensure only Gantt reordering operations are processed. If you implement the suggested constant from the previous comment, update this line to use it as well.-canDrop: ({ source }) => source?.data?.id !== id && source?.data?.dragInstanceId === "GANTT_REORDER", +canDrop: ({ source }) => source?.data?.id !== id && source?.data?.dragInstanceId === GANTT_REORDER_IDENTIFIER,web/core/components/gantt-chart/views/helpers.ts (2)
104-109: Consider improving width calculation robustness.The width calculation could be enhanced in two ways:
- Add validation to ensure target_date is not before start_date
- Add more descriptive comments explaining the width calculation logic
Consider this improvement:
if (itemStartDate && itemTargetDate) { - // get width of block + // Calculate block width: add 1 to include both start and end dates + if (itemTargetDate < itemStartDate) { + console.warn('Target date is before start date'); + } const widthTimeDifference: number = itemStartDate.getTime() - itemTargetDate.getTime(); const widthDaysDifference: number = Math.abs(Math.floor(widthTimeDifference / (1000 * 60 * 60 * 24))); scrollWidth = (widthDaysDifference + 1) * chartData.data.dayWidth; }
114-131: Consider enhancing function documentation.While the function is well-implemented, its documentation could be improved:
- Add JSDoc explaining the purpose and return value
- Document the offsetWidth parameter's purpose and valid values
Add this documentation:
+/** + * Calculates the pixel position on the Gantt chart for a given date + * @param chartData - The chart configuration and dimensions + * @param date - The date to calculate position for + * @param offsetWidth - Pixel offset to adjust the final position (useful for positioning block endings) + * @returns The pixel position on the chart, or 0 if dates are invalid + */ export const getPositionFromDate = (chartData: ChartDataType, date: string | Date, offsetWidth: number) => {web/core/components/gantt-chart/blocks/block-row.tsx (4)
71-71: Consider renamingtarget_datetoend_datefor consistency.While the logic change correctly implements the requirement to show blocks with either a start or end date, the variable naming (
target_date) doesn't match the terminology used in the PR objectives ("End date"). This inconsistency might cause confusion for future maintainers.
Line range hint
42-63: Consider adding block properties to effect dependencies.The intersection observer effect only depends on
blockbut usesblock.position,block.id, etc. inside. If these properties change but the block reference remains the same, the effect won't re-run. This could lead to stale calculations.Consider updating the effect dependencies:
return () => { observer.unobserve(timelineBlock); }; - }, [block]); + }, [block?.id, block?.position?.marginLeft, block?.position?.width]);
Line range hint
66-66: Fix inconsistent visibility check in early return.The early return condition
(!showAllBlocks && !(block.start_date && block.target_date))requires both dates whenshowAllBlocksis false, which contradicts the new visibility logic that allows either date.Update the condition to match the new logic:
- if (!block || !block.data || (!showAllBlocks && !(block.start_date && block.target_date))) return null; + if (!block || !block.data || (!showAllBlocks && !(block.start_date || block.target_date))) return null;
Line range hint
99-103: Consider using z-index constants.The scroll button uses a hardcoded z-index value (
z-[5]). This could lead to z-index wars if other components need to be layered relative to this button.Consider defining z-index values as constants alongside other UI constants:
// constants.ts export const Z_INDEXES = { SCROLL_BUTTON: 5, // ... other z-index values } as const;Then use it in the component:
- className="sticky z-[5] grid h-8 w-8 translate-y-1.5 cursor-pointer place-items-center rounded border border-custom-border-300 bg-custom-background-80 text-custom-text-200 hover:text-custom-text-100" + className={`sticky z-[${Z_INDEXES.SCROLL_BUTTON}] grid h-8 w-8 translate-y-1.5 cursor-pointer place-items-center rounded border border-custom-border-300 bg-custom-background-80 text-custom-text-200 hover:text-custom-text-100`}web/core/components/issues/issue-layouts/gantt/blocks.tsx (1)
64-65: Consider preventing event propagation for consistencyThe click handler should prevent event propagation like its sidebar counterpart for consistent behavior.
- onClick={handleIssuePeekOverview} + onClick={(e) => { + e.stopPropagation(); + e.preventDefault(); + handleIssuePeekOverview(); + }}web/core/components/gantt-chart/helpers/blockResizables/use-gantt-resizable.ts (3)
Line range hint
74-91: Refactor DOM manipulation for better React practices and reliability.The current implementation has several potential issues:
- Direct DOM style manipulation bypasses React's virtual DOM
- Parsing style strings with
slice(0, -2)is fragile- Reading styles from DOM during mousemove events may impact performance
Consider refactoring to use React state and refs:
-const prevMarginLeft = parseFloat(resizableDiv.style.marginLeft.slice(0, -2)); -const prevWidth = parseFloat(resizableDiv.style.width.slice(0, -2)); +const prevMarginLeft = resizableRef.current?.offsetLeft ?? 0; +const prevWidth = resizableRef.current?.offsetWidth ?? 0; // calculate new width const marginDelta = prevMarginLeft - marginLeft; width = prevWidth + marginDelta; -resizableDiv.style.width = `${width}px`; -resizableDiv.style.marginLeft = `${marginLeft}px`; +const [dimensions, setDimensions] = useState({ width: 0, marginLeft: 0 }); +setDimensions({ width, marginLeft });Then use these values in your component's style prop:
style={{ width: dimensions.width, marginLeft: dimensions.marginLeft }}
Line range hint
112-116: Fix error handling implementation.The current error handling has several issues:
setToastis not properly invoked- The caught error is not being used to provide meaningful feedback
- Generic error handling might hide important issues
Apply this fix:
try { const blockUpdates = getUpdatedPositionAfterDrag(block.id, dragDirection !== "move"); updateBlockDates && updateBlockDates(blockUpdates); } catch (e) { - setToast; + setToast({ + title: "Error updating block dates", + message: e instanceof Error ? e.message : "An unexpected error occurred", + type: "error", + }); + console.error("Failed to update block dates:", e); }
Line range hint
15-124: Consider edge cases and performance optimizations.The current implementation might benefit from additional safeguards and optimizations:
- Mouse events during drag operations could be throttled for better performance
- Event listeners should be cleaned up on component unmount
- Race conditions between mouse and scroll events should be handled
Consider these improvements:
- Add cleanup in a useEffect:
useEffect(() => { return () => { // Cleanup any active listeners on unmount if (ganttContainerRef.current) { ganttContainerRef.current.removeEventListener('scroll', handleOnScroll); } document.removeEventListener('mousemove', handleMouseMove); document.removeEventListener('mouseup', handleMouseUp); }; }, []);
- Throttle the mousemove handler:
import { throttle } from 'lodash'; const throttledMouseMove = throttle(handleMouseMove, 16); // ~60fps
- Add a mounted ref to prevent updates after unmount:
const isMounted = useRef(true); useEffect(() => { return () => { isMounted.current = false; }; }, []);web/core/components/gantt-chart/chart/main-content.tsx (2)
123-124: Document the magic number in scroll position calculationThe scroll position logic has been improved to handle blocks with either start or end dates. However, there's a magic number (-4) in the calculation that should be documented or extracted into a named constant for better maintainability.
- scrollContainer.scrollLeft = updatedPosition.marginLeft - 4 - (scrollToEndDate ? DEFAULT_BLOCK_WIDTH : 0); + // Define constant at the top of the file + const SCROLL_POSITION_OFFSET = 4; // Explain why this offset is needed + scrollContainer.scrollLeft = updatedPosition.marginLeft - SCROLL_POSITION_OFFSET - (scrollToEndDate ? DEFAULT_BLOCK_WIDTH : 0);Also applies to: 138-139
199-199: Consider adding ARIA attributes for better accessibilityWhile the padding adjustment improves visual consistency, consider adding ARIA attributes to help screen readers understand the layout structure better.
<div className="relative h-full" style={{ width: `${itemsContainerWidth}px`, transform: `translateY(${HEADER_HEIGHT}px)`, paddingBottom: `${HEADER_HEIGHT}px`, }} + role="region" + aria-label="Gantt chart timeline content" >web/ce/store/timeline/base-timeline.store.ts (2)
235-242: Consider adding input validationWhile the implementation is clean, consider adding validation for:
- Date parameter validity
- Positive offset width
getPositionFromDateOnGantt = computedFn((date: string | Date, offSetWidth: number) => { if (!this.currentViewData) return; + if (offSetWidth < 0) return; + if (typeof date === 'string' && isNaN(Date.parse(date))) return; return getPositionFromDate(this.currentViewData, date, offSetWidth); });
Line range hint
1-324: Consider implementing a Timeline validation serviceGiven the complexity of timeline calculations and the various edge cases (invalid dates, positions, widths), consider extracting validation logic into a dedicated service. This would:
- Centralize validation rules
- Make edge cases more discoverable
- Simplify testing
web/core/components/issues/issue-layouts/utils.tsx (1)
678-712: Function implementation looks good with room for minor improvementsThe function correctly implements the block view details generation with proper handling of partial dates and visual indicators. A few suggestions to enhance maintainability:
- Add explicit return type interface
- Extract gradient strings as constants
- Enhance JSDoc with parameter descriptions
Consider this refactor:
+ interface BlockViewDetails { + message: string | undefined; + blockStyle: CSSProperties; + } + + const GRADIENT_RIGHT = (color: string) => `linear-gradient(to right, ${color} 50%, transparent 95%)`; + const GRADIENT_LEFT = (color: string) => `linear-gradient(to left, ${color} 50%, transparent 95%)`; + /** * This Method is used to get Block view details, that returns block style and tooltip message + * @param block - The block object containing start and target dates + * @param backgroundColor - The background color to use for the block + * @returns BlockViewDetails object containing message and style properties */ export const getBlockViewDetails = ( block: { start_date: string | undefined | null; target_date: string | undefined | null } | undefined | null, backgroundColor: string - ) => { + ): BlockViewDetails => { // ... rest of the function if (block?.start_date) { message = `From ${renderFormattedDate(block.start_date)}`; - blockStyle.maskImage = `linear-gradient(to right, ${backgroundColor} 50%, transparent 95%)`; + blockStyle.maskImage = GRADIENT_RIGHT(backgroundColor); } else if (block?.target_date) { message = `Till ${renderFormattedDate(block.target_date)}`; - blockStyle.maskImage = `linear-gradient(to left, ${backgroundColor} 50%, transparent 95%)`; + blockStyle.maskImage = GRADIENT_LEFT(backgroundColor); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (16)
web/ce/store/timeline/base-timeline.store.ts(4 hunks)web/core/components/gantt-chart/blocks/block-row.tsx(1 hunks)web/core/components/gantt-chart/blocks/block.tsx(3 hunks)web/core/components/gantt-chart/chart/main-content.tsx(4 hunks)web/core/components/gantt-chart/chart/views/month.tsx(1 hunks)web/core/components/gantt-chart/chart/views/quarter.tsx(1 hunks)web/core/components/gantt-chart/chart/views/week.tsx(1 hunks)web/core/components/gantt-chart/constants.ts(1 hunks)web/core/components/gantt-chart/helpers/blockResizables/use-gantt-resizable.ts(2 hunks)web/core/components/gantt-chart/sidebar/gantt-dnd-HOC.tsx(2 hunks)web/core/components/gantt-chart/sidebar/issues/block.tsx(1 hunks)web/core/components/gantt-chart/sidebar/modules/block.tsx(1 hunks)web/core/components/gantt-chart/views/helpers.ts(2 hunks)web/core/components/issues/issue-layouts/gantt/blocks.tsx(4 hunks)web/core/components/issues/issue-layouts/utils.tsx(3 hunks)web/core/components/modules/gantt-chart/blocks.tsx(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- web/core/components/gantt-chart/chart/views/month.tsx
🔇 Additional comments (27)
web/core/components/gantt-chart/constants.ts (1)
9-9: Verify consistent usage of DEFAULT_BLOCK_WIDTH across components.
Let's ensure this constant is being used consistently for block width calculations throughout the Gantt chart components.
✅ Verification successful
Please update the verification scripts to correctly target TypeScript files.
DEFAULT_BLOCK_WIDTH is used consistently across all components with no hardcoded width values found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check usage patterns of DEFAULT_BLOCK_WIDTH
# Expected: Should be used consistently for block width calculations
# Check for direct usage of the constant
rg "DEFAULT_BLOCK_WIDTH" --type typescript
# Look for any hardcoded values that might need to use this constant instead
ast-grep --pattern 'width: "60px"'
ast-grep --pattern 'width: 60'
Length of output: 147
Script:
#!/bin/bash
# Description: Check usage patterns of DEFAULT_BLOCK_WIDTH
# Expected: Should be used consistently for block width calculations
# Check for direct usage of the constant in TypeScript files
rg "DEFAULT_BLOCK_WIDTH" --glob "*.ts" --glob "*.tsx"
# Look for any hardcoded values that might need to use this constant instead
rg 'width:\s*"60px"' --glob "*.ts" --glob "*.tsx"
rg 'width:\s*60' --glob "*.ts" --glob "*.tsx"
Length of output: 878
web/core/components/modules/gantt-chart/blocks.tsx (5)
8-12: LGTM: Well-organized imports
The new imports are properly organized and documented with clear grouping comments.
34-37: LGTM: Improved block styling logic
The use of getBlockViewDetails centralizes the styling logic and makes it more maintainable.
Line range hint 71-89: LGTM: ModuleGanttSidebarBlock remains stable
The sidebar block component maintains its clean implementation while complementing the main block's enhancements.
59-65: Verify accessibility of the sticky block name implementation
The sticky block name feature has been implemented as requested, but please verify:
- The background overlay's opacity (50%) provides sufficient contrast
- The sticky positioning works correctly across different viewport sizes
#!/bin/bash
# Search for related accessibility tests
rg -g '*.test.*' -g '*.spec.*' 'ModuleGanttBlock.*accessibility'
# Check for other uses of similar overlay patterns
ast-grep --pattern 'className="absolute left-0 top-0 h-full w-full bg-custom-background-100/50"'40-46: Enhanced tooltip content structure
The tooltip now provides better context with a clear hierarchy (name and details).
web/core/components/gantt-chart/blocks/block.tsx (2)
49-50: LGTM! Variables align with Timeline view enhancement requirements.
The new visibility variables correctly implement the requirement to show blocks with either a start date or an end date, while also tracking complete blocks (those with both dates).
92-92: Verify the restriction on block movement.
The change only allows moving blocks that have both start and end dates. Please verify if this restriction aligns with the intended user experience and business requirements.
web/core/components/gantt-chart/chart/views/week.tsx (2)
16-16: LGTM: Improved height management using Tailwind classes.
The change from inline styles to Tailwind's min-h-full class is a good improvement for consistent styling.
13-13: 🛠️ Refactor suggestion
Replace any type with proper interface definition.
Using any as props type reduces type safety and makes the component harder to maintain. Consider defining a proper interface for the component's props.
- export const WeekChartView: FC<any> = observer(() => {
+ interface WeekChartViewProps {
+ // Add required props here based on usage
+ }
+
+ export const WeekChartView: FC<WeekChartViewProps> = observer(() => {Likely invalid or redundant comment.
web/core/components/gantt-chart/chart/views/quarter.tsx (3)
Line range hint 29-46: Well-implemented sticky header with good UX details!
The sticky header implementation is robust with:
- Proper z-index management
- Clear visual hierarchy
- Nice UX touches (current quarter indicator, consistent typography)
Line range hint 82-92: Verify overflow behavior with different content scenarios.
The month columns use overflow-hidden which might clip content in certain scenarios. Consider testing with:
- Long block names
- Multiple blocks in the same time period
- Different zoom levels affecting dayWidth
18-18: LGTM! Verify layout behavior across different viewport sizes.
The switch from explicit minHeight calculation to min-h-full is a good improvement that aligns with modern CSS best practices and makes the height management more flexible.
Let's verify if this change affects other chart views:
✅ Verification successful
Height management changes are consistently applied across all chart views. No issues found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if similar height management is consistent across other chart views
# and if there are any remaining explicit HEADER_HEIGHT calculations
# Search for explicit height calculations in chart views
rg "minHeight.*HEADER_HEIGHT" "web/core/components/gantt-chart/chart/views/"
# Search for min-h-full usage in other chart views for consistency
rg "min-h-full" "web/core/components/gantt-chart/chart/views/"
Length of output: 1540
Script:
#!/bin/bash
# Description: Check if similar height management is consistent across other chart views
# and if there are any remaining explicit HEADER_HEIGHT calculations
# Search for explicit height calculations in chart views
rg "minHeight.*HEADER_HEIGHT" "web/core/components/gantt-chart/chart/views/"
# Search for min-h-full usage in other chart views for consistency
rg "min-h-full" "web/core/components/gantt-chart/chart/views/"
Length of output: 522
web/core/components/gantt-chart/sidebar/gantt-dnd-HOC.tsx (1)
Line range hint 1-108: Verify component usage in sticky block name feature.
The changes look good for improving drag-and-drop safety, but let's verify how this component integrates with the sticky block name feature mentioned in the PR objectives.
web/core/components/gantt-chart/views/helpers.ts (2)
2-2: LGTM! Good practice to centralize constants.
The import of DEFAULT_BLOCK_WIDTH from constants follows good practices for maintainability.
85-95: LGTM! Enhanced date handling aligns with PR objectives.
The changes successfully implement the requirement to support blocks with either start or end date, improving Timeline view flexibility.
Also applies to: 97-97
web/core/components/gantt-chart/blocks/block-row.tsx (1)
Line range hint 1-124: Implementation successfully meets PR objectives.
The changes effectively implement both key requirements:
- Sticky positioning for block names via the scroll button
- Flexible date requirements allowing blocks with either start or end date
The code is well-structured and maintains good separation of concerns.
web/core/components/issues/issue-layouts/gantt/blocks.tsx (4)
7-8: LGTM: Import changes align with new features
The new imports support the sticky block name feature and enhanced block visualization.
Also applies to: 18-19
50-75: LGTM: Improved block visualization with sticky names
The implementation successfully:
- Makes block names sticky using SIDEBAR_WIDTH
- Enhances UX with informative tooltips
- Provides clear visual feedback through block styling
99-103: LGTM: Improved event handling
The click handler correctly prevents event propagation and default behavior before navigation.
45-45: Verify date handling implementation
Let's verify that the getBlockViewDetails utility correctly handles blocks with either start or end dates.
✅ Verification successful
getBlockViewDetails correctly handles blocks with start and/or end dates
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for the getBlockViewDetails implementation
ast-grep --pattern 'export const getBlockViewDetails = $_' -A 20
Length of output: 2704
web/core/components/gantt-chart/chart/main-content.tsx (2)
111-118: LGTM: Enhanced scroll detection logic
The improved scroll handling with dual conditions ensures more reliable detection of when to load additional content, providing a better infinite scrolling experience.
Line range hint 31-199: Well-implemented timeline enhancements
The changes effectively implement the PR objectives:
- Support for blocks with either start or end dates
- Enhanced scroll handling for better user experience
- Consistent layout adjustments
The implementation is clean, maintainable, and follows React best practices.
web/ce/store/timeline/base-timeline.store.ts (3)
8-12: LGTM: Clean import organization
The new imports are well-organized and logically grouped with related functionality.
54-54: LGTM: Well-defined interface method
The new method signature is clear, type-safe, and consistent with the interface's existing pattern.
194-194: Verify edge cases with the relaxed condition
The condition now allows updates when either startDate OR dayWidth is present. While this adds flexibility, please verify:
- That
getItemPositionWidthhandles cases where only one value is present - That this doesn't lead to invalid position calculations
web/core/components/issues/issue-layouts/utils.tsx (1)
36-36: LGTM: Import statement is correctly placed
The import of renderFormattedDate is appropriately placed with other helper imports and is necessary for the new block view functionality.
This PR contains minor enhancements to Timeline layouts along with few fixes, Couple of the enhancements are,
Screen.Recording.2024-11-12.at.5.07.10.PM.mov
Screen.Recording.2024-11-12.at.5.08.31.PM.mov
Summary by CodeRabbit
Release Notes
New Features
Improvements
Bug Fixes
Style