-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Mobile Sketch Preview Screen #1467
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
Mobile Sketch Preview Screen #1467
Conversation
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 is looking really great!
I have some comments and questions about the code. If this has been addressed in your next PR (or will be) then feel free to say that. :-D
this.renderSketch(); | ||
} | ||
|
||
if (shouldRenderSketch(this.props, prevProps)) this.renderSketch(); | ||
// small bug - if autorefresh is on, and the usr changes files |
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.
Is this a bug that still exists? Should this comment be removed?
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 think the commend holds, since I merely moved code around. The logic is pretty much the same
</IconLinkWrapper> | ||
<div> | ||
<h2>{projectName}</h2> | ||
<h3><br /></h3> |
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.
What's the purpose of this mark-up?
<h3><br /></h3>
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.
It just heightens the header by an h3
height, to keep the h2
tag aligned with the previous screen - couldn't think of a better way to do this...
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.
We might have to use CSS to add padding to the h2? And maybe set the previous screens header to a know height?
Using h3
is this way is not semantic especially as screen-readers allow the user to list and navigate via the headings in the page, which will be empty.
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 point. I'm fixing this on the next PR, and improving the <Header />
component as well
client/theme.js
Outdated
@@ -88,6 +88,13 @@ export default { | |||
Icon: { | |||
default: grays.middleGray, | |||
hover: grays.darker | |||
}, | |||
Panel: { |
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.
These are same colours as the buttons, so we'll have a problem if someone later puts a Button on top of a Panel as they'll be the same.
Shall we take the colours from the console header component? Cassie made accessibility colour changes a a while back to ensure the contrast worked across all the themes.
So:
Panel.default.foreground
should be the value of console-header-color
Panel.default.background
should be the value of console-header-background-color
Panel.default.border
should be the value of ide-border-color
The colours are here.
I know it's a bit of a pain to do this, but it'll really help with the move to styled-components and away from SCSS and helping to make the design more consistent.
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.
True, but these are the colors that Panels use on the mobile UI (on Headers and Footers at least), so I'm not sure what to do. I wonder if they even mean the same thing on both UIs.
I think I'll create a Panel: { mobile: {} }
attribute and keep these colors there, so the default Panel
colors can be set to those of the default UI. Do you think that makes sense?
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.
If possible, it would be great to have the same set of colours work for mobile and the legacy UI. My feeling is branching the theme into Panel.mobile and Panel.notMobile creates more code for us to maintain.
Your right that maybe this isn't a reusable panel colour, so if it's not possible to find common colours, then my preference is that we name the variable something other than Panel.
@catarak, what do you think?
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 investigated this a bit, and It's an important decision that goes beyond the scope of the PR, so I'll create an issue and we can discuss it there!
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.
Ok, good idea.
So shall we call this MobilePanel or something for now and we can get this merged in?
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 agree with @andrewn, that it would be helpful if possible to not have mobile specific colors.
@ghalestrilo and I talked this over and thought it would make sense to open a new issue/PR with respect to the panel and button color contrasts, see #1484.
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.
Nice! I'll update this :)
const IconButton = props => (<ButtonWrapper | ||
iconBefore={props.children} | ||
kind={Button.kinds.inline} | ||
{...{ ...props, children: null }} |
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.
Do you need to put children: null
here? Isn't children
null here if you just don't put anything in between <ButtonWrapper></ButtonWrapper>
?
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.
Yes, it's null if I don't pass anything, but in this case I wanted to pass children
into the iconBefore
prop, and not into the body of the component.
I thought of a better solution, so I'll change this soon
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 introduced an icon
prop, now it looks a lot cleaner
</IconLinkWrapper> | ||
<div> | ||
<IconButton to="/mobile" aria-label="Return to original editor"> | ||
<ExitIcon viewBox="0 0 16 16" /> |
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.
Are you using viewbox here to change the size of the icon? I would prefer if you explicitly set the width and height, and maybe this needs to be added to client/common/icons.jsx
, which could be done in a separate PR.
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'll remove the viewbox
prop for now, and find a way to resize the icon in a future PR, to minimize conflicts with the other branch
<IconButton to="/mobile" aria-label="Return to original editor"> | ||
<ExitIcon viewBox="0 0 16 16" /> | ||
</IconButton> | ||
<div style={{ marginLeft: '1rem' }}> |
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.
if possible i would prefer to not have inline styles!
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.
The next PR fixes this by improving the structure of the <Header />
component
Part of the Mobile UI project. This PR adds a (working!) Mobile Sketch Preview screen (/mobile/preview), which renders the canvas with the project files and resizes it to properly fit the mobile view.
How to test:
MOBILE_ENABLED
flag set totrue
(MOBILE_ENABLED=true npm start
)/mobile
/mobile
routes should not be accessibleI have verified that this pull request:
npm run lint
)Fixes #123