Ideas on how to organise the UI code in a Flutter application
This post is aimed at capturing thoughts I have had on how to approach organising UI code for a Flutter application. With some other frameworks, the UI may be written through another syntax such as through markup language. However, toolkits like Flutter have developers write "UI as code". Here the code for building user interfaces is written using the same programming language as the business logic.
When writing code in general, you and/or your team may be have a rule whereby the body of a method must fit within the bounds of your screen. Yet, a problem that developers may encounter during the course of building out their user interfaces is that code for a page can become large and difficult to follow, resulting in the infamous "bracket hell" problem. To combat this, you can refactor out your code into separate widgets as covered in the previous link that leads a post by Iiro Krankka. With the "UI as code" approach, the IDE will be able to assist refactoring very easily. Whilst refactoring though, it may be easy to lose sense of the big picture and miss out on the fact that there are repeatable patterns within an application that are larger than a component like a button.
One way to look at the UI to identify these patterns is to apply the Atomic Design methodology by Brad Frost. I won't be describing it here but it applies a scientific analogy to break user interfaces into hierarchies and you can open the link for more details. This aligns with Flutter's approach of creating user interfaces via composition. If you're working with dedicated designers, there's a chance they're already building a design system or a style guide of sorts for your application. Applying the methodology could thus help designers and developers communicate with the same terminology. Having identified the patterns at various levels (with or without the help of a designer), developers could then structure the application such that there are folders for the atoms, molecules, organisations and templates. This can help accelerate the addition of new pages to an application by looking at the building blocks that already exist and mixing them together to get the desired outcome.
Note that what I'm proposing here isn't new like as seen in examples like this React Native boilerplate. However, what would be interesting to see is if teams use Flutter for not only building applications but to also document their design system through something like a pattern lab. Given that Flutter can target the web and DartPad can be used as an online editor to run Flutter code, it's not entirely unreasonable to think that will happen in the foreseeable future. Each pattern in a lab is typically accompanied with some sample code. If a pattern lab was built using Flutter and embedded DartPad within it, tweaks could be made on the fly if needed as well. Tools like Supernova Studio could also assist with this process by translating designs into code. If anyone ends up doing this, I would love to hear about it. If you're interested in reading more about design systems, I suggest reading Brad Frost's book on Atomic Design and Design Systems by Alla Kholmatov. Feel free to drop a comment if you have other resources that you recommend as well.