A community contribution from Cavin Macwan 🎉
Disclaimer: This article is about Widgetbook 2.0 Parts of the content may be out of date.
If you’re into Flutter development for some time then I’m sure you must have heard about WidgetBook at some point. But do you know what actually is a WidgetBook and why do you need it?
In this blog, I’m gonna walk through all of the terminologies along with the practical example. So without further a do, let’s get started 😉
Before understanding what WidgetBook is, let’s first discuss the current scenario in the Software development industry to better figure out why do you need WidgetBook.🤔
Suppose you’ve to build one application in Flutter💙 Normally, all of the designs will come in Figma to the developer. And then you start making the app by following the Figma designs and you basically copy each and every single attribute of design from Figma to Flutter. And then you submit that for design reviews either to the client or testers.
But sometimes what happens is customer feels like this is not exactly what they wanted after the app gets into their hand. But it’s not a problem with the client or with the developer. But it basically doesn’t fit in the App itself.
Then the client shares the feedback and the back and forth continues till the client gets satisfied.
You see the problem now. There’re also other problems such as
Now that you know all of the problems, let’s talk about the solution now.💡
If I have to define WidgetBook in one sentence then it’s a Flutter package that helps to speed up the development process by cataloging their widgets that you can test on multiple devices and themes.
WidgetBook is built to solve all the problems which I described earlier.
With WidgetBook, you can catalog all components of your App. It enables developers to test widgets across different devices, themes, locales, text scales and more, thus ensuring adaptability and responsiveness.
Now that you know what problems WidgetBook is aimed to solve, let’s get into the programming part 👨💻
I’ll be using the new beta release of the WidgetBook since I found it stable throughout my testing 🧪
You can set up a WidgetBook via 2 methods: By doing it Manually and by using Code Generation. In this part, we will look at the manual setup.
flutter run -d macos -t lib/app.widgetbook.dart
Now that you’ve learned how to set up the WidgetBook. Let’s see how you can structure your widgets in WidgetBook. But before that, let’s learn one important concept.😉
Now that you know how you can add components and use cases inside your WidgetBook. What will happen when you want to organize different kinds of components inside WidgetBook?
WidgetBook has covered that one for you too😉 Let’s see how can you organize components inside a folder like this:
Consider the below snippet:
This one is by far the most liked feature of mine in WidgetBook🤩 Knobs allows developers to change widget’s parameters in real-time. Changing the parameters helps developers and designers to better understand the functionality of a component.
But what do I mean by changing parameters in run-time? For that, let’s look at the demo first:
Now, consider this widget:
It’s a basic widget that accepts title from the constructor and shows inside the AppBar. Nothing fancy, right?🤔
Now let’s see how can we change the title in the run-time inside WidgetBook. For that, consider this snippet:
WidgetBook provider different types of knobs like:
I have created a GitHub repo of the demo of WidgetBook in which you can check out different types of use cases of knobs and add-ons which we will talk about now.
Till now, we were exploring the directories inside Widgetbook.material, but there’s also one other property called addons which we kept empty from the beginning. It’s time to explore them now😉
In the beginning, we talked about changing themes and text scale factors in real-time inside WidgetBook. This is achievable through add-ons. WidgetBook comes with a bunch of add-ons that you can use. Let’s discuss them one by one.
The theme Add-on provides theming for previewing your use cases in WidgetBook. Thus, you can check and verify your themes in real time.
As the name suggests, this Add-on allows you to change the text scale for previewing your use cases. By adding this, you can check if your layout is going to break or not when the scale of the text changes.
Let’s see the code for it:
As you can see in this GIF, this add-on provides you the ability to view and test all of your use cases on different scree-sizes along with the frames of those devices.
WidgetBook gives you a bunch of Android, iOS and Desktop devices that you can use directly. You can also create your own custom device if you want.
You can use this add-on like this:
You can also define your own devices by extending the Device like this:
If you want to try this on your own then you can check out my GitHub repository:
https://github.com/Cavin6080/Widgetbook-demo
I hope you learned something new from this blog. If you didn’t understand any of this part or have any doubts, then you can ask me in the comments, or on my LinkedIn and Twitter.
In the next part, we’ll learn how can we automate the whole process of defining use cases and other things by leveraging code generation😉