Skip to content

improvement: add resizer component #1538

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

Merged

Conversation

harshithpabbati
Copy link
Contributor

@harshithpabbati harshithpabbati commented May 19, 2020

This PR adds a new Resizer component. So we will be able to resize the editors. We can simply wrap the editor with resizer component like this

<Resizer
  border="bottom"
  handlerStyle={{ backgroundColor: 'rgba(0, 0, 0, 0.2)' }}
>
  <main>{`Main content`}</main>
</Resizer>

This above example will add a resizer option below the main tag and we can also pass the required styles to it.

@acao can you review this

@acao
Copy link
Member

acao commented May 19, 2020

great!

I've configured netlify actions for feat/use-context-hooks, so if you push another commit, it should trigger a netlify deploy preview!

@acao
Copy link
Member

acao commented May 21, 2020

@harshithpabbati
Copy link
Contributor Author

https://deploy-preview-1538--graphiql-test.netlify.app/storybook check it out!

Yeah, I saw it. Can you review the PR @acao

@acao acao changed the title feat: add resizer component [RFC] add resizer component May 21, 2020
@acao
Copy link
Member

acao commented May 22, 2020

@harshithpabbati still reviewing!

className={className}
style={{
cursor: `${dir}-resize`,
...style,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a) should we use style here or _css or sm?
b) would it make more sense to just spread rest props instead of a style prop?
c) should we be using a different component if we want to allow theme-ui props?

@jxnblk

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally, the style attribute is good to use for dynamic styles, but it doesn't look like that's really the case here, unless dir changes frequently. If dir is changing based on mouse events, etc., then style is fine to use here. For passing through style as props, it's sort of the same thing, but I haven't looked at where that's coming from. Does that make sense?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes! ok good, just wanted to make sure we weren't baking in anything that would "break" theme-ui implementations or user extensibility

const { dir, onStart, onEnd, onUpdate, className, style, children } = props;

const [isDragging, setIsDragging] = useState(false);
const listenersRef = useRef<ResizeHandlerData['listenersRef']>(null);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would we want to use forwardRef here to allow users to pass ref? or do we only need it internally?

className={className}
style={{
position: 'relative',
...containerStyle,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, maybe shouldn't spread style props instead of just spreading props

@acao
Copy link
Member

acao commented May 22, 2020

@harshithpabbati most of my review questions are related to extensibility. so for now, I think this looks great overall for the firs tpass. as we begin to implement it in our own components, we will probably find ways we need to extend it for our purposes and for the purposes of plugin developers

(this includes my comments about forwardRef, etc)

@acao acao changed the title [RFC] add resizer component improvement: add resizer component May 22, 2020
@acao acao merged commit 32594e2 into graphql:feat/use-context-hooks May 22, 2020
@harshithpabbati
Copy link
Contributor Author

@harshithpabbati most of my review questions are related to extensibility. so for now, I think this looks great overall for the firs tpass. as we begin to implement it in our own components, we will probably find ways we need to extend it for our purposes and for the purposes of plugin developers

(this includes my comments about forwardRef, etc)

Yeah sure, we can extend it when we begin implementing that into our components.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants