justoverclockl / justoverclockl/react-fast-scheduler
Implement different views (week, list...)
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
# Add multiple calendar views (`day`, `week`, future extensible views)
## Summary
The scheduler currently behaves as a day-view resource calendar. We should introduce support for multiple calendar views so consumers can switch between different time scopes, starting with `week` and keeping the API extensible for additional views later.
## Goal
Allow the scheduler to render the same appointment/resource model in different calendar views, while preserving the current day view as the default and avoiding breaking changes for existing users.
## Proposed scope
Initial scope:
- Keep current behavior as `day` view
- Add `week` view
- Make the view controlled through props
- Keep drag, resize, date navigation, and custom render hooks working consistently across views
Possible future views:
- `work-week`
- `multi-day`
- `month`
- `agenda`
## Proposed API direction
Example:
```tsx
```
## Potential API additions
- `view`: `"day" | "week"`
- `onViewChange`: optional callback if a built-in view switcher is introduced
- `availableViews`: optional list for toolbar view switching
## Expected behavior
- `day` remains the default view for backward compatibility
- `week` shows the full week relative to `selectedDate`
- Navigation adapts to the selected view
- In `day` view, previous/next controls move by one day
- In `week` view, previous/next controls move by one week
- Date picker and toolbar remain usable across views
- Appointment rendering remains customizable
- Move/resize behavior continues to work correctly in each supported view
## Implementation considerations
- Avoid coupling layout logic to a single-day assumption
- Separate date-range calculation from rendering
- Make layout and presentation logic view-aware
- Preserve type safety for current adapter and callbacks
- Ensure collision/layout calculations scale for multi-day rendering
- Decide how resources and time axes should behave in `week` view
- Define whether `week` is:
- A single horizontal week grid
- A per-day grouped layout
- A resource x day matrix
## Open questions
- What should the default week start be: Monday, Sunday, or configurable?
- Should `week` view support both all-day and timed appointments, or timed only for now?
- Should the built-in toolbar include a view switcher in the first release?
- Should `week` view collapse or scroll on smaller screens?
## Acceptance criteria
- Existing day-view integrations continue to work without code changes
- Scheduler supports `view="week"` with correct date-range rendering
- Navigation logic changes according to active view
- Drag and resize still emit correct `onAppointmentChange` payloads
- Custom appointment rendering continues to work
- Documentation includes examples for at least `day` and `we
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at the Scheduler entry point and trace the current day-view date navigation, rendering, drag, and resize behavior. Resolve the open questions around week layout, week start, appointment types, toolbar switching, and responsive behavior before implementation. Done means day remains the default without breaking existing integrations and week view meets the listed acceptance criteria.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, typescript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100