-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Carousel: Sliding window #31806
base: master
Are you sure you want to change the base?
Carousel: Sliding window #31806
Conversation
📊 Bundle size report✅ No changes found |
width: '100%', | ||
height: '100%', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love how clean this file is 👨🍳
<div style={{ overflow: 'hidden' }}> | ||
<Carousel circular={true} peeking={true} defaultValue={'test-1'} {...props}> | ||
<Carousel circular={true} peeking={true} defaultValue={'test-1'} {...props}> | ||
<CarouselSlider cardWidth={'50%'}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
slick - I like that this is optional.
Curious - when does DOM get rendered? Thinking ahead to Wizard scenario where future steps change based on users settings AND are heavy on DOM.
Obviously this is a-okay for OOBE type stuff, but just thinking of edge cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call, yeah if we have things that aren't yet rendered in DOM but need to be represented in nav we would likely have to take an approach more similar to Virtualizer, where the object has knowledge of steps etc. ahead of time.
The other option is to follow a similar path to this, and render all steps in the DOM but have any inactive steps be set to inert/hidden.
*/ | ||
export type CarouselSliderProps = Partial<ComponentProps<CarouselSliderSlots>> & { | ||
/** | ||
* Used to define the carousel card size, can be any css metric i.e. 100% / 100px / 100vw |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment and variable name are a little unclear to me? Does it control the peak amount?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will control how large each carousel card is in proportion to the viewport, so if you want each card to take up the full width it would be '100%', if you want the other cards to peek in ~10% then the value would be 80%
to leave space on each side - users could also enforce a pixel width of cards if desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Coolio - it might be worth adding to the comment to help others understand.
/** | ||
* CarouselSlider Props | ||
*/ | ||
export type CarouselSliderProps = Partial<ComponentProps<CarouselSliderSlots>> & { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding props to toggle between vertical and horizontal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A vertical carousel would be interesting, we haven't seen this spec'd but can definitly add if we have consumer interest.
What would the animation look like if your got to the end of a non-cyclical carousel? That sounds a fun delightful way to remind the user they've reached the end of the list. |
WIP exploration of sliding carousel movement.