-
Notifications
You must be signed in to change notification settings - Fork 44
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
[web] Make sidebar an aside
element
#550
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pull Request Test Coverage Report for Build 4913816372
💛 - Coveralls |
dgdavid
changed the title
[web] Change where the Sidebar is mounted
[web] Make sidebar a sibling of content instead of a child of layout.
Apr 26, 2023
dgdavid
changed the title
[web] Make sidebar a sibling of content instead of a child of layout.
[web] Make sidebar an Apr 28, 2023
aside
element
Instead of mounting them as children. Children prop still there because it might be helpful and it allows to keep the Sidebar test simple.
Mount it from App instead.
To limit the width size at the div#root level instead of the layout. This allows better nav positioning now that it is a sibling of the layout and not a child.
No longer needed after dropping the "groups" of actions feature from there.
The main navigation is no longer there, as we thought it would be. Altough there still general or complementary links, we have extracted almost all navigation links to navigate from one page to another into a page-specific dropdown menu (see PageOptions component). If needed, we can add `nav` children to the Sidebar later.
dgdavid
force-pushed
the
change-sidebar-mount-component
branch
from
May 8, 2023 09:52
5c8483d
to
91e9317
Compare
joseivanlopez
approved these changes
May 8, 2023
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.
LGTM
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Until now, we thought that the
Sidebar
behind the hamburger menu icon would be the main Agama navigation. Thus, it was born as aLayout
childnav
element.However, as the project evolves and after relocating the page related options to another place in #545, the content of the sidebar looks more a set of general/complementary links than a navigation.
Solution
To address that new reality, this PR proposes two main changes
To change from
nav
toaside
element, which looks more accurate to the currentSidebar
role.It could hold one or more
nav
children later if needed.To relocate the
Sidebar
as a sibling of theLayout
component instead of a child.At first glance, this can be confusing because we normally think everything must be wrapped inside the Layout. But this is not exactly the case. Now that the sidebar is an aside element, it will be more helpful to have it as a sibling of the content instead of a child. Think that our layout component is a bit special since it is designed to not (un)mount it in each page change. Read A better layout mechanism #216 and https://gregberge.com/blog/react-scalable-layout
Please, bear in mind that this is the proposed change for the current scenario. I.e., it could need to be re-adapted later as the project continues evolving. But fortunately it's not a risky or compromising change.
Testing
Screenshots
Nothing has changed at the visual level. Just a slight difference in the shadow because previous values make too much overflow on the right side with the new flow position. Are you able to spot it? 😉
Notes
It does not affect the rendered UI. So, no entry for the changes files.