Skip to content

useWindowDimensions hook for Artboard viewport #501

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
merged 11 commits into from
Apr 21, 2020

Conversation

macintoshhelper
Copy link
Contributor

@macintoshhelper macintoshhelper commented Apr 19, 2020

Not sure if it's worth having context feature detection? Or just require people to run recent React versions, rather than have the hook act as a stub on earlier versions.

fixes #414

Copy link
Collaborator

@mathieudutour mathieudutour left a comment

Choose a reason for hiding this comment

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

That look amazing. Just a couple of comments

src/context.tsx Outdated

type ArtboardProps = PropTypes.InferProps<typeof ArtboardPropTypes>;

export const ArtboardProvider = ({ children, viewport }: ArtboardProps & { children: any }) => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

So I'm not sure it's enough to only consider the viewport. Most of the time people won't specify it, and only use the style's width (like in the basic example https://github.com/airbnb/react-sketchapp/blob/master/examples/basic-setup/src/my-command.js#L45-L51).

So IMO it'd be useful to fallback to the style dimension if we have no viewport (even if we have only the width because it's probably the main use case).

Copy link
Contributor Author

@macintoshhelper macintoshhelper Apr 20, 2020

Choose a reason for hiding this comment

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

Good point, am falling back to style.width and style.height now. Is it worth doing a console.warn in the hook, if the viewport is missing, prompting them to use the <Artboard viewport={} prop? Incase they get confused about why the height is the full page height rather than viewport height?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Nah I think that what you actually expect: just the size of the artboard. I actually didn't even think about the viewport prop before your PR.

viewport: PropTypes.shape({
width: PropTypes.number,
height: PropTypes.number,
name: PropTypes.string,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do you think it'd be useful to add scale and fontScale here? Even if it doesn't change the sketch output, it could be a nice way to provide a hook for people to change those values and control the context

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, would be great to pass a custom scale and fontScale to artboards, to better replicate React Native device-specific behaviour. Do you think this should be added to the viewport prop, rather than create a new prop? Not sure if it could create confusion if people think that the scale/fontScale is supposed to be handled by Sketch viewports?

Copy link
Collaborator

Choose a reason for hiding this comment

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

It feels natural in viewport and I guess with some docs it would be ok.

Copy link
Contributor Author

@macintoshhelper macintoshhelper Apr 20, 2020

Choose a reason for hiding this comment

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

I've filtered out scale and fontScale from ArtboardRenderer.tsx so they don't pollute the generated file. Does this look good/readable?

...(props.viewport && {
presetDictionary: {
allowResizedMatching: 0,
offersLandscapeVariant: 1,
...{
name: props.viewport.name,
width: props.viewport.width,
height: props.viewport.height,
},
},
}),

Updated the docs in API.md (note after the props table).

Would be really useful for testing/visualising conditional image quality based on device pixel density, etc.

Copy link
Collaborator

@mathieudutour mathieudutour Apr 20, 2020

Choose a reason for hiding this comment

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

why not just

presetDictionary: { 
     allowResizedMatching: 0, 
     offersLandscapeVariant: 1, 

     name: props.viewport.name, 
     width: props.viewport.width, 
     height: props.viewport.height,      
},

?

The doc is good for me 👍

docs/API.md Outdated

render(
<Page>
<Artboard viewport={{ width: 360, height: 640 }}>
Copy link
Collaborator

Choose a reason for hiding this comment

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

it could be interesting to add 2 Artboard with different viewports and show what useWindowDimensions will be in both cases (as a comment below it) - and perhaps showing an additional div in case the width is bigger than a certain breakpoint

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've added a devices array and am mapping through that, and created a conditional View for tablet/desktop.

I've created a useBreakpoint hook that returns a getStyle function, like this: getStyle(['column', 'row']) – for column on mobile and row on tablet/desktop. Might be worth featuring in a new doc file, probably overkill for API.md example though.

Copy link
Collaborator

@mathieudutour mathieudutour left a comment

Choose a reason for hiding this comment

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

That's perfect, well done 👏

@mathieudutour mathieudutour merged commit 3f1910c into airbnb:master Apr 21, 2020
@mathieudutour
Copy link
Collaborator

I'm going to publish it, feel free to tweet about it if you want - it's a really cool feature and could make for a really visual tweet

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.

"How to" create UI variations based on screen width
2 participants