Sidebar tray #507
Reference in New Issue
Block a user
Delete Branch "sidebar-tray"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Sorry creating a WIP PR, as it make it easier to make inline comments, otherwise they need to be on individual commits.
The sr-only class in tailwind looks pretty similar, definitely not the same though.
https://tailwindcss.com/docs/screen-readers
This open param looks like it wasn't used, so not sure what the plan was with it here, but it smells a little to me, in that this data structure contains with copy/user info, and app state and I think it will be hard to manage like this.
I've made a commit with a demo of the tray being controlled by the app data store, which I think is probably the right approach, even thinking about it abstractly
indicates to me this should be handled through app state
Okay, take a look at
69c83d33b1for a bit of a proposal. I hope I'm being helpful.Love this thank you I will take a look
Yo @Irev-Dev your proposal is so much simpler it's a breath of fresh air. I'll read through it better in a little bit but I definitely think that's the way to go, sorry for leading us astray I hope my approach at least served as a rubber duck for you 🤦🏻♂️. Should we merge your proposal over mine, and then I can do the semantic HTML and CSS fiddling you were talking about, or close mine and replace with yours to do that? Not sure how to wrangle the branches.
The "only one sibling setting open at a time" constraint sounds like a feature as much as a bug, and I don't think it will throw off most users, other than potentially ones with screenreaders but we're gonna need wayy more engineering help than just you and I to get accessibility down on a 3D modeling code editor app 😅.
Ah should've know they'd have a utility for that
Cool glad you like it :)
In terms of branches @franknoirot , I think you should have a go at the wrangling them, that's how you'll get comfortable doing it. Worst thing is you break both you the branches locally in which case you can delete them locally and pull them again from github for another attempt. If you're nervous about it you make a new branch off
sidebar-trayas a dummy to test the sequence, and if it works you can do it for real on your original branch.This is pretty the same situation as with the keyboard shortcuts with the exception that I mergedmain in on my branch (which makes the diff look bigger than it is). You can either cherry-pick
69c83d33b1bb6c2349787983edf37aa55db1f0aeor you can merge my branch into yours. (doing the latter means you will get the merge with main "for free")Alright hell yeah @Irev-Dev on it.
@Irev-Dev I think it's set so that you can't approve / review because you opened the PR, but would you mind reviewing this for me when you're free? I think I got collapsing menus on ancestor menu click working, and I turned on the gear icon buttons in each of the panes, so fun to click around now.
@@ -0,0 +59,4 @@rel="noreferrer">Discord</a>Feels silly to put this here for temporary copy, but I really didn't want to rewrite the Discord link 3 times lol. Should I have done this differently?
@@ -0,0 +136,4 @@key={'settings-tray-' + item.name}open={state.sideTray.slice(-1)[0] === item.name}onClick={(e) => {e.preventDefault()Unsure if
e.preventDefault()on the<details>onClickevent breaks any of the semantic/SR advantages of using it in the first place, but it doesn't appear to hurt keyboard navigation with Tab and Space which is cool.This is how I implemented clicks on the main gear icon closing the whole menu. Does this work for you @Irev-Dev?
Sorry, side effect from me starting the PR. and yup should be able to take a look at this and the user profile PR after work today.
Looks good,

I quickly fixed a double icon that think is from the icon being included in the header when it already existed on some of the other pages.