Genstyl — Design System tool | Responsive breakpoints management
#DesignSystems #UIUX #FrontEnd #BuildInPublic #WebDesign #DesignToCode
Genstyl's waitlist 👇🏻
https://genstyl.ovidiu.works/?utm_sou...
These past few days I’ve been working on the responsive breakpoints management feature, which initially I categorised as “straightforward”. Well, it turns out that it’s not that complicated, and at the same time definitely not trivial!
New breakpoints can be added from presets or you can add your own custom breakpoint (when I’m able to resize the viewport manually, that’s the value that will be used).
Simple add, edit (display name or width), remove operations and persistence when hitting the Save button. All pretty clear.
Then the edge cases start to crop up!
Maintain width uniqueness, avoid overlaps (breakpoints cannot share the same pixels, otherwise things get really hairy and confusing when we export to CSS). Archiving a breakpoint doesn’t mean the settings associated with it are lost, so that also means we can bring them back!
If you add a new breakpoint with a width that matches an archived breakpoint, we don’t create a new one, but actually reinstate the original archived breakpoint. This allows us to keep settings associated with it at the surface without getting lost by the ID reference.
Another important rule that guards against losing changes is to disable Layout and Component editing when there are pending changes to Breakpoints. Similar to my last point, but if a user tweaks some properties targeting a non-committed breakpoint and then decides to discard it after, those changes are lost forever (they’re still there saved in the history, but there’s no way of resurfacing them in the UI, at least not for now).
Then there’s also making it clear, in the UI, which properties have been overridden for the current breakpoint. I’m also considering a “Clear all” button to remove all properties for a node in a Layout or Component for the current breakpoint. Is that worth the effort?
Breakpoints are associated per Style, and all Layouts and Components belonging to that Style have access to them. Per Layout custom breakpoints did come to mind, but I’ll skip that for now (I do see a valid use case there, though).
These are not universal rules, instead they’re constraints I landed on for Genstyl throughout planning and development. Can you think of anything else that’s worth adding? Please let me know!
Next step: exporting breakpoint-associated properties into CSS!