-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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 device view: toggling stories panel with ☰ button #3337
Conversation
* add separate Header component * add isMobileDevice helper * initially place addonPanel at the bottom if storybook is open on mobile device * add first part of tests
@@ -0,0 +1,7 @@ | |||
export default userAgent => { | |||
if (/Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(userAgent)) { |
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 we really need javascript for this? Can we just show/hide things using media queries instead?
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 did it to avoid changes to layout in general.
Depending on whether it is mobile device, the header is rendered outside of stories-panel as a standalone component and visibility of stories-panel is just toggled with the existing mechanism (to hide when app first loaded on mobile device) :)
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 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.
I'm in the media query camp as well. If on desktop, a user scales the window smaller so they can code and render in the browser side by side, they should be able to use the mobile view as well.
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.
@danielduan with current version of Storybook there is nothing stopping users from hiding stories-panel on desktop (with shortcuts) and then resize the browser window as it is needed for your particular case. I want to emphasize that this pull request solves the problem with testing components on physical mobile devices :)
And I tried to affect as little of desktop version as possible on purpose. Cause this is a whole separate task related to layouts in general.
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 understand that you don't want to expand the scope of this change so this sounds fine with me.
It's still a broader issue that we'll need to address at some point.
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.
Let's take it 1 step at a time? I don't fancy userAgent sniffing either, but it does solve an issue and down-scopes this PR well.
Let's improve the manager head for desktop after.
<h3 style={headingStyle}>{name}</h3> | ||
</a> | ||
<button style={shortcutIconStyle} onClick={openShortcutsHelp}> | ||
<button style={iconStyle(isMobileDevice)} onClick={openShortcutsHelp}> |
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.
Looks like this button is useless on mobiles, it shows keyboard shortcuts
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 can actually make those things clickable and perform the action.. but once the left panel is gone (either by toggling it, or by going full-screen, you can't go back)
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.
Note that some people use USB keyboards with mobile devices, so I wouldn't necessarily just remove it because of mobile.
@@ -98,7 +98,11 @@ const defaultSizes = { | |||
}, | |||
}; | |||
|
|||
const saveSizes = sizes => { | |||
const saveSizes = (sizes, isMobileDevice) => { | |||
if (isMobileDevice) { |
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.
Please add some inline comment explaining why do we need to skip saving here
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 see two ways of refactoring this part:
Extract the saveSizes
and getSavedSizes
to a separate file and do not change their functionality.
Change only the Layout component to be coupled to the isMobileDevice
.
As an alternative, you can store mobile sizes in a sperate entry of the storage.
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.
@igor-dv I like the second option
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.
Sorry, I don't really get the point of separate storage entries. Different devices cannot share the same localStorage
AFAIK
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.
@Hypnosphi initially I avoided saving dimensions on mobile as the resizing worked not perfectly when I firstly tried it (I did not face issues that you have found later, but still resizing seemed to be a hard task to perform. So I wanted to avoid situations when you somehow resized the pane and did not like the results but the new unwanted sizes are saved in localStorage, so you cannot reset the layout by refreshing the page.
Maybe I misunderstood Igor's comment above about separation of saved dimensions, if it is not needed, but we still want to save sizes on mobile – let's just drop the changes and leave this part as it is in master right now?
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 talked more about the browser emulators. I think in this case the storage is shared.
} = this.props; | ||
const { previewPanelDimensions } = this.state; | ||
|
||
const addonPanelInRight = isMobileDevice ? 0 : this.props.addonPanelInRight; |
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.
Why number not boolean?
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.
missed it, thanks :)
It breaks in a weird manner when I try to resize stories panel on mobile: https://deploy-preview-3337--storybooks-official.netlify.com/?selectedKind=ui%2FAddonPanel&selectedStory=default&full=0&addons=1&stories=0&panelRight=0&addonPanel=storybook%2Factions%2Factions-panel |
@denzenin Thank you for this amazing first PR, thank you! |
const Header = ({ openShortcutsHelp, onBurgerButtonClick, name, url, isMobileDevice }) => ( | ||
<div style={wrapperStyle(isMobileDevice)}> | ||
{isMobileDevice && ( | ||
<button style={burgerIconStyle} onClick={onBurgerButtonClick}> |
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.
Why don't just show this button always? I don't see any cons to it in a web mode, and having it in both modes will reduce complexity.
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.
for me, when I see a ☰ button on mobile websites, I expect it to "always be there for me" :)
in this particular case, if we leave it on Desktop version and have the same behaviour (toggling story-panel, it will be hidden once story-panel is hidden)
but I have no issue with keeping the button, so if you advise to get rid of the check above – I'll remove it
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.
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 assume there is a disadvantage in mobile view with floating button. In case of this floating element you will have to always keep it in mind when writing stories of the components. We would need to add some additional containers/spacing in stories to test the component without visual/touch interference with floating element. In my opinion header is OK and quite simple solution for 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.
👌
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.
@igor-dv I prefer this:
both visually and UX, you should not overlay anything over the preview.
@@ -98,7 +98,11 @@ const defaultSizes = { | |||
}, | |||
}; | |||
|
|||
const saveSizes = sizes => { | |||
const saveSizes = (sizes, isMobileDevice) => { | |||
if (isMobileDevice) { |
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 see two ways of refactoring this part:
Extract the saveSizes
and getSavedSizes
to a separate file and do not change their functionality.
Change only the Layout component to be coupled to the isMobileDevice
.
As an alternative, you can store mobile sizes in a sperate entry of the storage.
@Hypnosphi regarding breaking on resize. yes, it is weird indeed. It seems that resizing of SplitPane works far from smooth on mobile. Tried it on master branch. Even when I had succeeded to resize story-panel I could resize it again (after first resize) only once in a bunch of tries. |
@ndelangen thank you for the kind words :) |
Codecov Report
@@ Coverage Diff @@
## master #3337 +/- ##
==========================================
- Coverage 37.21% 37.19% -0.02%
==========================================
Files 463 465 +2
Lines 10241 10300 +59
Branches 914 923 +9
==========================================
+ Hits 3811 3831 +20
- Misses 5892 5906 +14
- Partials 538 563 +25
Continue to review full report at Codecov.
|
So should we maybe disable resizing on mobile at all? |
Good day to all, could you please advise what changes should I make to my pull request to move it forward? Maybe one step at a time but still I need to know those steps :) |
What do you think about this?
You also need to resolve conflicts, feel free to ask for help if you need one |
@Hypnosphi I am totally ok with that. If it's ok with you and @igor-dv – will do as it was initially in PR:
and will add some inline comments about why the sizes are not saved/loaded for mobile. |
It would be more explicit if we would just pass |
Would love to see this merged soon! 🙇 |
@Hypnosphi good evening. Fixed the resizing as you proposed. |
@@ -130,7 +130,7 @@ class Layout extends React.Component { | |||
constructor(props) { | |||
super(props); | |||
|
|||
this.layerSizes = getSavedSizes(defaultSizes); | |||
this.layerSizes = getSavedSizes(defaultSizes, props.isMobileDevice); |
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.
Looks like this second argument isn't used anymore
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, you are right ) please advise how could I clean it up?
Awesome work @denzenin ! 💪 |
yay! thank you all for your help and support :) |
hi ! in which storybook version this PR has been included ? thanks ! |
@Aarbel try latest alpha, |
Issue:
What I did
Now on mobile devices the layout looks something like this when storybook is rendered:
How to test
Open storybook on mobile device
Is this testable with Jest or Chromatic screenshots?
yes (I added some new tests)
Does this need a new example in the kitchen sink apps?
no
Does this need an update to the documentation?
not sure
If your answer is yes to any of these, please make sure to include it in your PR.