I’d like to discuss the Flutter Atomic Design methodology and explore how to effectively create and manage atoms, molecules, and organisms in a Flutter project.
Here are some key points I’d like to address:
Best Practices:
What are the best practices for building complex UI using Atomic Design while avoiding passing too many properties?
How can we optimize the structure and reusability of components to simplify the process?
Challenges:
I’ve already implemented Atomic Design components (atoms, molecules, and organisms) and used theme extensions to create custom themes for complex organisms. However, I often find myself passing a large number of parameters, which complicates the structure.
Are there better ways to manage these parameters or design components to reduce this complexity?
Tooling:
I’ve used the Widgetbook package and other similar tools to document and manage Atomic Design components, but I feel there’s room for improvement.
Are there any packages, tools, or workflows that can make documenting and managing Atomic Design in Flutter more efficient?
I’d love to hear your insights, experiences, or suggestions to overcome these challenges and enhance the overall workflow.
Super interesting topic. Love to hear from others experiences. Our UI lead introduced it on our code base and I m sometimes wondering if the higher leven of code share isn’t outweighted by more complex indirectuons of your code when you have some template-widget that just wraps other widgets.
I’ve been using Mix for a long time now. It’s a different dialect to learn and with some limitations but for porting a whole design and evolve it in time it’s one of the most original solution.
If you need to use anything related to overlay you’ll loose the original context and so all the design. This can happen quickly like drag and drop (I opened a ticket some times ago)
need to learn another expression language
ideal for basic widgets, lot of integration work when dealing with custom content
you fully commit to the framework or not, there is no between so you need to learn it fully and migrate
I’m probably coming from the completely different direction when I think about creating widgets.
From my experience the number of widgets that are really reused at a lot of places inside an app is limited.
So why deconstruct a complex widgets into atoms and molekules if they are only used at one place?
To me this falls into the trap of dogmatic programming.
I prefer what I call “self-responsible” widgets. These are complex widgets that know where they get their data from using DI (dependency injection). I prefer using DI over passing a value over several levels of widgets via the constructor if these values are not used in all of the widgets. Same goes for callbacks. instead to propagate an event via callbacks over multiple levels I prefer having some Model/Manager/controller object that can be acessed by the widgets via DI.
To my knowledge Mix is the only large tentative in the Flutter verse to implement Atomic Design.
In the world of Atomic Design, Figma practices are king and that’s the methodology that drive the designers. What devs do with that is up to them but mix try to port an implementation that port much more easily than basic and very specific theming.
Difference mainly comes from the much flexible aggregation of configurations that the Design Tokens offers.
Flutter and the related logo are trademarks of Google LLC. We are not endorsed by or affiliated with Google LLC.
Using contents of this forum for the purposes of training proprietary AI models is forbidden. Only if your AI model is free & open source, go ahead and scrape.
