Repository navigation
feat(app): add focus trap to main nav and QuestionsSidebar; add small fixes to lockScroll - #489
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
| Device | URL |
|---|---|
| mobile | https://devfaq-ck1f6nfzr-typeofweb.vercel.app |
Not what you expected? Are your scores flaky? GitHub runners could be the cause.
Try running on Foo instead
📦 Next.js Bundle AnalysisThis analysis was generated by the next.js bundle analysis action 🤖
|
| Page | Size (compressed) |
|---|---|
global |
83.31 KB (🟡 +2 B) |
Details
The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!
| export const unlockScroll = ({ mobileOnly }: { mobileOnly: boolean }) => { | ||
| document.body.style.paddingRight = ""; | ||
| export const unlockScroll = ({ mobileOnly, preventLayoutShift }: PropsType) => { | ||
| if (preventLayoutShift) { |
There was a problem hiding this comment.
Po co jest ta opcja i kiedy chcemy ustawić ją na false? Wydaje mi się, że nigdy.
There was a problem hiding this comment.
W przypadku kiedy otwieramy menu mobilne dodawanie padding-right do body nic nie zmienia, ponieważ i tak nie widać tego przesunięcia strony spowodowanego usunięciem scrollbarów. Podobnie sprawa ma się w przypadku QuestionsSidebara w widoku mobilnym - cała strona jest zakryta po jego otwarciu
Natomiast dodanie tego odstępu może powodować w niektórych sytuacjach problemy np:
- otwieram menu mobilne:
- przekręcam widok na widok horyzontalny i oczom ukazuje się niepotrzebny odstęp od scrollbara:
Ta dodatkowa opcja została dodana właśnie z myślą o tym przypadku.
Faktem jest również to, że dodawanie odstępu od prawej po ukryciu scrollbara ma znaczenie tylko w przeglądarkach, gdzie on jest cały czas widoczny, czyli najczęściej na desktopowych urządzeniach / przeglądarkach. Na smartfonie tego niepożądanego efektu nie dostrzeżemy.
There was a problem hiding this comment.
To nie prościej byłoby po prostu usunąć ten padding przy obracaniu ekranu? :)
There was a problem hiding this comment.
Opisany wyżej przypadek można by było wyeliminować również w ten sposób, że w zależności od wartości isAboweBreakpoint, czyli krótko mówiąc w momencie przechodzenia z widoku mobilnego na desktopowy i odwrotnie jeśli menu było by otwarte to należało by dodać ten odstęp lub go zabrać, lecz problem jest taki że, jak scrollbary są widoczne to można sobie obliczyć ile tego odstępu dodać, ale jak chcę przywrócić ten odstęp i mieć nadal zablokowaną możliwość scrollowania to nie ma skąd tego odstępu obliczyć. Gdyby tak na przykład dać w useEffect warunek, że jeśli np sidebar jest otwarty i isAboreBreakpoint === true to dodaj scrollbary i usuń odstęp to by załatwiło sprawę, ale wpływ na to czy maja być widoczne scrollbay mają również inne elementy np menu i modale i dodatkowo to wszystko się jeszcze zmienia w zależności od szerokości viewportu. To często generowałoby konflikty i doprowadzało by do sytuacji, że np menu mobilne ma widoczne scrollbary, a nie powinno.
Krótko mówiąc ta dodatkowa właściwość eliminuje konflikty w bardzo specyficznych sytuacjach.
There was a problem hiding this comment.
Najprościej by było, gdyby sidebar i menu było zamykane przy przejściu z widoku mobilnego na desktopowy i ponowne przejście w drugą stronę (deskop -> mobile) nie powodowało odtworzenia poprzedniego stanu tj. na mobile menu było otwarte czy nie tylko zawsze takie przejście zamykało by czy to menu czy sidebara.
There was a problem hiding this comment.
To nie prościej byłoby po prostu usunąć ten padding przy obracaniu ekranu? :)
załóżmy że usunę ten parametr prewentLayoutShift z pageScroll.ts, a do HeaderNavigation dodam coś takiego co pozornie rozwiązuje problem:
useEffect(() => {
if (isAboveBreakpoint) {
document.body.style.paddingRight = "";
}
}, [isAboveBreakpoint]);i teraz:
- w widoku mobilnym otwieram menu mobilne
- zmieniam widok na desktopowy
- otwieram modal np. 'dodaj pytanie'
- wracam do widoku mobilnego
- wracam do widoku desktopowego
- ...strona nie posiada scrollbarów, nie posiada odstępu - zamykam modal i w trakcie tego zamykania, strona przesuwa się...
a to jeden z przypadków, nie mówiąc już o tym, że mając otwarte menu mobilne w widoku desktopowym ciągle działa useEffect w tle i modyfikuje style body
There was a problem hiding this comment.
#484 (comment) spełnienie wymagania z tego komentarza, generuje najwięcej problemów
There was a problem hiding this comment.
@mmiszy tak z ciekawości zerknąłem, jak to jest rozwiązane na allegro.pl. W wersji mobilnej, jak otworzę sidebar 'FIltry i kategorie' to do body jest dodawana klasa css z overflow: hidden; , ale jak z otwatym sidebarem zmienie szerokość viewportu do rozmiaru desktopowego to nadal mam zablokowaną możliwość scrollowania 😁
Zawsze jakieś kompromisy...
There was a problem hiding this comment.
ale przedstawię zaraz jeszcze jedna wersję chyba ostateczną, jeśli nie ona to już sam nie wiem...
There was a problem hiding this comment.
Dobra, próbowałem przygotować inną wersję, w której stan czy menu jest otwarte, czy zamknięte oraz funkcje zmieniające ten stan znajdowałyby się w UIProvider, ale kod zaczyna wyglądać strasznie, a każdy element: menu, modale, sidebar ma funkcjonalność opisywaną praktycznie w sposób okropny, bo trzeba np. w modalu brać pod uwagę czy menu jest otwarte / zamknięte tak samo z sidebarem....nie dobrze to wygląda
Ja mam taką propozycję:
- zostaje taka wersja jaka jest - wiem są kompromisy, ale nie da się ich w 'sensowny' sposób przeskoczyć (przez sensowny mam na myśli nie opisywać, jak dany element ma się zachować dla każdego szczególnego przypadku w zależności od stanu innego elementu na stronie),
- idziemy na kompromis i każde przejście z mobile na desktop bądź na odwrót powoduje 'wyzerowanie' stanu tego elementu do ustawień początkowych np. otwarte menu mobilne przy przejściu do widoku desktopowego jest zamykane i po ponownym powrocie do widoku mobilnego nadal będzie zamknięte, w ten sposób można bardzo łatwo uniknąć konfliktów.
Na chwilę obecną przetestowałem już tyle wersji, podpatrywałem, jak sobie z tym radzą inne serwisy i nie da się tego zrobić inaczej. Zawsze jest jakiś kompromis, chyba że ręcznie rozpiszesz i obsłużysz wszystkie możliwe kombinacje otwarcia i zamknięcia menu, modali, sidebarów. Współczuję jednak jak postanowisz dodać kolejny element...
There was a problem hiding this comment.
| Device | URL |
|---|---|
| mobile | https://devfaq-26gsrrx2x-typeofweb.vercel.app |
Not what you expected? Are your scores flaky? GitHub runners could be the cause.
Try running on Foo instead
There was a problem hiding this comment.
| Device | URL |
|---|---|
| mobile | https://devfaq-hjb4llv27-typeofweb.vercel.app |
Not what you expected? Are your scores flaky? GitHub runners could be the cause.
Try running on Foo instead
|
Uprościłem kod dodając do Właściwość scrollbar-gutter wydaje się być jak najbardziej uzasadniona, ponieważ rozmiar scrollbara jest inny w różnych przeglądarkach, a w przypadku kiedy go usuniemy i ponownie chcielibyśmy dodać margines od prawej, aby zapobiec przesunięciu strony to nie ma na jakiej podstawie wyznaczyć ile ten margines ma wynosić, ponieważ nie mamy scrollbara, wiec naturalne wydaje się, że ten problem trzeba scedować na przeglądarkę. |
| type PropsType = { | ||
| mobileOnly: boolean; | ||
| }; |
There was a problem hiding this comment.
Wcześniej w typie PropsType było więcej propsów, a teraz uznałem, że skoro wykorzystuje w 2 fukcjach takie same propsy to postanowiłem to pozostawić. Rozumiem że lepiej wrócić do:
export const lockScroll = ({ mobileOnly }: { mobileOnly: boolean }) => {Co-authored-by: Michał Miszczyszyn <michal@mmiszy.pl>
Co-authored-by: Michał Miszczyszyn <michal@mmiszy.pl>
…nto fix-main-menu
There was a problem hiding this comment.
| Device | URL |
|---|---|
| mobile | https://devfaq-qpu3k31i5-typeofweb.vercel.app |
Not what you expected? Are your scores flaky? GitHub runners could be the cause.
Try running on Foo instead
Co-authored-by: Michał Miszczyszyn <michal@mmiszy.pl>
There was a problem hiding this comment.
| Device | URL |
|---|---|
| mobile | https://devfaq-rgo4ccyhz-typeofweb.vercel.app |
Not what you expected? Are your scores flaky? GitHub runners could be the cause.
Try running on Foo instead
There was a problem hiding this comment.
| Device | URL |
|---|---|
| mobile | https://devfaq-3sbz2w1i8-typeofweb.vercel.app |
Not what you expected? Are your scores flaky? GitHub runners could be the cause.
Try running on Foo instead
|
Kudos, SonarCloud Quality Gate passed!
|
There was a problem hiding this comment.
| Device | URL |
|---|---|
| mobile | https://devfaq-1mafmwms7-typeofweb.vercel.app |
Not what you expected? Are your scores flaky? GitHub runners could be the cause.
Try running on Foo instead
… fixes to lockScroll (#489) * feat(app): add 'useIsAboveBreakpoint' hook * refactor(app): refactor 'pageScroll' utility file * feat(app): add focus lock in HeaderNavigation * fix(app): changes in BaseModal to reflect changes in pageScroll * feat(app): add focus trap in 'QuestionsSidebar' * fix(app): fix hamburger button position * fix scrollbar gutter * Update apps/app/src/utils/pageScroll.ts Co-authored-by: Michał Miszczyszyn <michal@mmiszy.pl> * Update apps/app/src/utils/pageScroll.ts Co-authored-by: Michał Miszczyszyn <michal@mmiszy.pl> * refactor(app): change types declarations in 'pageScroll' * refactor(app): refactor styles related to scrollbar on page * Update apps/app/src/components/Header/HeaderNavigation.tsx Co-authored-by: Michał Miszczyszyn <michal@mmiszy.pl> * refactor(app): refactor 'HeaderNavigation' * fix(app): fix typo Co-authored-by: Michał Miszczyszyn <michal@mmiszy.pl>










useIsAboveBreakpoint, który zwracatruekiedy szerokość viewportu przekroczy przekazaną wartość, w przeciwnym wypadku zwracafalse,pageScroll.ts- dodawanie padding-right po ukryciu scrollbarów, działa tylko dla użytkowników przeglądarki Safari, ponieważ na ten moment nie wspierascrollbar-gutterz css.PS. prace nad rozwiązanymi problemami prowadzone były również w PR #484, jednak nie chciało mi się już rozwiązywać konfliktów i postanowiłem dodać nowy PR 😆