Let us show you how adding a style-guide to your app can prevent several issues regarding components in your app.
Have you ever been building duplicate components? Or have you ever joined a team and wondered which components are available to use? All of these issues could’ve been prevented by adding a style-guide to your app! Let me show you an example of how I’ve done this and why it’ll add value to your projects. A simplified example (Flutter) repo can be found here.
Note: The style-guide concept can be applied in any kind of application it’s not only bound to Flutter.
Why using a style-guide?
By adding a style-guide you’ll make it easier for all team members to implement the pages your designer delivers to you. You are creating a ‘reference’ page that contains every component that has been built so far. It gives you visual, and so clear, insights on what components you, as a developer, have available to work with. Let me show you one of our examples!
As you can see it’ll give you an instant overview of all of the components that developers have available and how to relate these components to the design the designer has delivered. As you can see all the components have their class names shown as titles above the presentation of the component itself. This will prevent the developer from having to dive into the source code of the style-guide page to figure out the exact class name of the component he/she wishes to use.
Add it at the start of a project
I would strongly advise adding a style-guide at the start of a project and let it grow as your project grows. This makes it easier as it’ll grow in small bits just like your application does. Plus, it’ll provide you and your team with all of the advantages right from the start. That'll save some time, money, and frustration!
Keeping it up to date
It’s really important to keep the style-guide up to date because what is the point of the style-guide if it is missing some components? If this is the case the developer might build a duplicate component or he/she still needs to track down the right components by navigating through the app and diving into source-code. A waste of time and money!
But I know this can be tricky and easily forgotten. So that’s why I would advise you to add it to a checklist in your pull request (PR) template.
And for those who don’t know what PR’s are please read into what it is as it’s one of the most efficient tools to help you maintain high quality code throughout your applications.
Make it easily accessible
My last tip to you would be to make the style-guide page easily accessible. In most of my projects, I like to make it visible in the hamburger menu. Don’t forget to do this only in debug mode! To give you an example I’ve set up an example (Flutter) repo [here](https://github.com/Baseflow/flutter-style-guide).
Note: The style-guide concept can be applied in any kind of application it’s not only bound to Flutter.
.gif)
So now you know my solution, I bet there are some improvements to be made. If you know some, please share them with me and we can improve this blog post together!
You can also find me on Twitter (@jop_middelkamp) and LinkedIn or even by mail to jop@baseflow.com. Please leave your feedback if you have some!
