-
Notifications
You must be signed in to change notification settings - Fork 2
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
Enhance transition components #996
Changes from 3 commits
32969b1
6cdc2f4
26942cb
dc00fb2
4ab9161
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -194,7 +194,7 @@ export default function UsingComponentsPage() { | |
<Library.Code | ||
size="sm" | ||
content={`type TransitionComponentProps = { | ||
visible: boolean; | ||
direction?: 'in' | 'out'; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we document that default is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
onTransitionEnd?: (direction: 'in' | 'out') => void; | ||
};`} | ||
title="Common transition-component props" | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -7,16 +7,17 @@ import Library from '../../Library'; | |
|
||
const Slider_: FunctionComponent< | ||
ComponentProps<TransitionComponent> & { _transitionStatus?: 'in' | 'out' } | ||
> = ({ children, visible, onTransitionEnd, _transitionStatus }) => { | ||
const [isVisible, setIsVisible] = useState(visible); | ||
const toggleSlider = () => setIsVisible(prev => !prev); | ||
> = ({ children, direction, onTransitionEnd, _transitionStatus }) => { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This typing is a little hard to read (the multi-line wrapping). Is it possible to construct the type elsewhere? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, this is now redundant, and This can be simplified as There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok no, my mistake. Doing that has other side effects. I will extract the type in multiple definitions for better readability. |
||
const [currentDirection, setCurrentDirection] = useState(direction); | ||
const toggleSlider = () => | ||
setCurrentDirection(prev => (prev === 'in' ? 'out' : 'in')); | ||
|
||
return ( | ||
<div className="flex-col w-full space-y-2"> | ||
<Button onClick={toggleSlider} variant="primary"> | ||
{isVisible ? 'Hide' : 'Show'} slider | ||
{currentDirection === 'in' ? 'Hide' : 'Show'} slider | ||
</Button> | ||
<Slider visible={isVisible} onTransitionEnd={onTransitionEnd}> | ||
<Slider direction={currentDirection} onTransitionEnd={onTransitionEnd}> | ||
{children} | ||
</Slider> | ||
<div> | ||
|
@@ -66,7 +67,7 @@ export default function SliderPage() { | |
<Library.Usage componentName="Slider" /> | ||
<Library.Example> | ||
<Library.Demo title="Basic example" withSource> | ||
<Slider_ visible={false}> | ||
<Slider_ direction="out"> | ||
<Card> | ||
<CardContent>This is the content of the Slider</CardContent> | ||
</Card> | ||
|
@@ -76,17 +77,17 @@ export default function SliderPage() { | |
</Library.Pattern> | ||
|
||
<Library.Pattern title="Props"> | ||
<Library.Example title="visible"> | ||
This mandatory boolean prop tells if the Slider is currently | ||
displayed or hidden. | ||
<Library.Example title="direction"> | ||
This prop tells if the Slider is currently expanded (<code>in</code> | ||
) or collapsed (<code>out</code>). It is <code>in</code> by default. | ||
Comment on lines
+87
to
+89
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A task for me, especially now that we have reliable routing and fragment navigation, is to create a better centralized documentation for common component props. That is, this documentation probably shouldn't be necessary specifically for |
||
</Library.Example> | ||
|
||
<Library.Example title="onTransitionEnd"> | ||
Optionally, you can provide a callback that will be invoked once the{' '} | ||
<code>in</code>/<code>out</code> transitions end. | ||
<Library.Demo title="Slider with onTransitionEnd" withSource> | ||
<Slider_ | ||
visible={false} | ||
direction="out" | ||
onTransitionEnd={direction => setTransitionStatus(direction)} | ||
_transitionStatus={transitionStatus} | ||
> | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -31,6 +31,6 @@ export type IconComponent = FunctionComponent<JSX.SVGAttributes<SVGSVGElement>>; | |
* animate the mounting and unmounting of a child component. | ||
*/ | ||
export type TransitionComponent = FunctionComponent<{ | ||
visible: boolean; | ||
direction?: 'in' | 'out'; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this mean that all |
||
onTransitionEnd?: (direction: 'in' | 'out') => void; | ||
}>; |
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.
I'm curious: this
Wrapper
may be a reference to aTransitionComponent
functional component or it might be aFragment
. DoFragment
s happily take any props without grumbling? Presumably typechecking would bark if not...I just haven't thought about it before.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.
Yeah, I thought the same at first, but not only it does not complain when type-checking, but the IDE properly autocompletes valid props, and complains if you set something not valid for
TransitionComponent
.So I guess the type of
Fragment
is defined in a way that it accepts anything, knowing it will be actually "lost".