-
Notifications
You must be signed in to change notification settings - Fork 0
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
Feature/fds navigation mobile version #40
Conversation
… selected primary nav on small screen size
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.
Lähinnä tohon style guideen ja muihin käytäntöihin liittyviä muutos toiveita. Päivitä myös tämä uusi mobileWidth
property tonne storybookkiin!
Pyysin tähän myös Roopelta katselmointia kun hän on enemmän lähiaikoina tehnyt Litin kanssa hommia ja osannee arvioida näitä ratkaisuja sikäli paremmin.
Huomiona myös, että pidetään jatkossa PR:t englanniksi, kun meillä on nyt suomea puhumattomia kehittäjiä myös mukana.
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.
Tuosta primary-tyyppisessä navigaatiopalkista puuttunee jokin margin/padding jostain. Storybookista näkee, että oikeanpuoleisin nav-item (Settings) on kiinni navigaatiopalkin reunassa. Vertailukohtana voi käyttää tätä: https://fintraffic-design.github.io/coreui-components/?path=/docs/navigation--docs
Totta! Hyvin hoksattu. Pitääpä käydä lisäämässä. En ole ennen tuota Storybookkia käyttänytkään missään muussa projektissa, niin pitä vähän siihen tutustua kans tässä. |
…to the style guide.
…ly on mobile view.
…navigation height to desktop view so that the navigation renders correctly on different browsers. Add 'mobile-width' to storybook.
Tuli vielä mieleen, että meidän käytössä tuo navigaatiopalkki on leveydeltään pienempi kuin tuo 768px, vaikka kyseessä on desktop-selaimessa käytettävä sovellus. Eli jos ei halua tuota kollapsointia niin onko oikea tapa antaa |
Juu eli, jos haluaa, että kollapsointi tapahtuu vaikkapa 1000px kohdalla, niin siitten näin:
Tosiaan, myöhemmin javascriptillä tuon propertyn muuttaminen ei vaikuta mitään. |
…t from using code. Change hover color
Hey, I'm new in the project but will be working on this actively for now. I'd just want to know what is the state of this PR so we can get this moving? Seems like Roope already approved this but Nino's previous request for changes is still active/blocking. If this is ready for merge, we can just dismiss Nino's review (or he can add approval) so we can get this merged. @ninopenttinen are we ready to merge here or do you still want some changes here first? |
Personally I would like to take the use case that Sabina mentioned into consideration on the component API, by renaming the Also I want to note that I don't really have any authority over this repo, so this is just my suggestion, not a demand, you may dismiss my review if you disagree with it. |
Thanks for clarification, I still do think though, that using "mobile" in the properties is a bit misleading, as it is not a mobile only feature, but rather a responsiveness thingy. However I'm fine with either. |
Yup, I agree, that "mobile"-looking layout can still be useful for non-mobile scenarios as well |
If we want to this to be a "mobile only" feature, then I think rather than using a pixel threshold for changing the navbar, I would just add a boolean property that decides if we should render this component in "mobile" or "desktop" mode. |
Although if we were to go with that (separate mobile/desktop modes) I would then rather have entirely different components for those to keep the code cleaner. |
Thanks for the quick replies. I'll need to familiarize myself with this component code and API to have a more informed opinion on the changes. Sounds like naming could be improved. Generally for component responsiveness and toggling between display modes based on available space I'd prefer container queries (if CSS is enough) or JS (e.g. ResizeObserver) if needed, preferring to make it automatic without need for manually toggling modes by user (app developer). Breakpoint may be configurable if necessary but it would be better if mode can be automatically deduced based on container and content size.
I don't assume any authority either (at least so far). Just going to try my best to make things better. This should be a productive collaboration between interested/related parties. 🙂 |
Hi, sorry for not getting back to this earlier. So there are two changes that need to be made
|
The filenames and structure changed a bit in main since #59 was merged. I can help merge the changes into this branch. |
Nuo muutokset on tehty, mutta tämä "change requested" tässä vielä jostain syystä roikkuu.
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.
Found couple of minor things but otherwise looks good to me.
Co-authored-by: Kari Söderholm <kari.soderholm@solita.fi>
@ninopenttinen if this looks ok to you now, let's squash and merge 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.
👌
Elikkäs pyrin olemaan rikkomatta mitään. Nyt tuo navigaatio menee navigaationapin taakse, kun ruudun koko on tarpeeksi pieni. Lisäsin myös tuommoisen
mobileOrder
propertyn, jonka avulla navigaation itemejä voi järjestellä haluamaansa järjestykseen mobiilinäkymässä. Tämä sen takia, että näyttäisi Fintrafficin projekteissa olevan sellainen tapa, että hakukenttä on sijoitettu navigaation oikeaan nurkkaan desktopilla, mutta mobiililla se on listan ensimmäisenä.