Widgetbook Cloud Reviews
We are already saving 20% of time for our designers and developers.
– 1KOMMA5° (source)
Widgetbook Cloud Reviews not just helps you introduce a "Design Review" in your workflow, but also helps you to detect UI regressions automatically with a zero-configuration setup (i.e. without writing any golden tests). It provides a structured review process to ensure that all UI changes are intentional and match the design expectations.
Code Review vs Design Review
In a code review, you are looking for bugs, performance issues, and code quality. In a design review, you are looking for visual differences between the design and the implementation. It is important to have both types of reviews to ensure that the code is correct and the design is implemented as expected.
Design reviews does not only help designers to ensure that the design is implemented correctly, but also help developers to detect UI regressions automatically.
Code Review | Design Review | |
---|---|---|
Purpose | To find bugs, performance issues, and code quality | To find visual differences between the design and the implementation |
Comparison | Code changes between base and head commits | Visual differences between base and head builds |
Reviewer | Developers | Designers and Developers |
Tool | Version Control Systems (e.g. GitHub, GitLab) | Widgetbook Cloud |
Design Review Workflow
Prerequisite: Make sure you have finished the setup of Widgetbook Cloud for GitHub, GitLab or Azure DevOps.
- Submit a PR with your changes using your version control system (e.g. GitHub, GitLab).
- Widgetbook Cloud will automatically create a review for your PR and post the URL in your git PR as a commit status.
- Designers and Developers should review the visual differences (if any), and either approve the changes or request changes.
- The review status will be reflected in the commit status of your git PR.
- If changes are requested, the commit status will block your PR from getting merged until the requested changes are applied. (you can disable this behavior from your project settings)
Empower Design Reviews
To give the reviewer more power, you can use the following features:
- Figma Reviews: Compare the implementation with the Figma design.
- Multi Snapshot Reviews: Generate snapshots for each use-case in multiple configurations (i.e. themes, locales, devices, etc.); to ensure that the UI is consistent across all configurations.
Animations
If your use-cases have any animations (e.g. CircularProgressIndication
), then the visual comparison might not work as expected. This is because the visual comparison algorithm is not able to compare animations.
We suggest using one of the following workarounds:
-
Adaptive animations: you might want to still enjoy your animations while running Widgetbook, but you just need to disable them when the use-case is being used in a Widgetbook-Cloud-context. To do so, you can use the following
extension
, to make your use-cases adaptive to the Widgetbook Cloud Reviews and disable the animations during the visual comparison.extension WidgetbookContext on BuildContext { /// The `preview` query parameter is used while taking snapshots of the /// use-case for Widgetbook Cloud Reviews. This getter can be used to /// customize the behavior of the use-case while taking the snapshots, /// it can be used to disable animations for example. bool get isInWidgetbookCloud => WidgetbookState.of(this).previewMode; } @UseCase(name: 'Default', type: CircularProgressIndicator) Widget adaptiveAnimationUseCase(BuildContext context) { return CircularProgressIndicator( value: context.isInWidgetbookCloud ? 0.5 : null, ); }
-
Starting animations on-demand: you can use a
boolean
knob to start your animations. This way, you can disable the animations during the visual comparison but you can still see the animations in the Widgetbook.@UseCase(name: 'Default', type: CircularProgressIndicator) Widget onDemandAnimationUseCase(BuildContext context) { return CircularProgressIndicator( value: context.knobs.boolean(label: 'Static') ? 0.5 : null, ); }
Random values
If your use-case displays random values (e.g. dates), that can be different across different builds, the visual comparison might not work as expected.
We suggest using one of the following workarounds:
-
Use a constant value for the random value.
@UseCase(name: 'Default', type: Text) Widget constantValueUseCase(BuildContext context) { return Text(Random().nextInt(10).toString()); return Text('10'); }
-
Use Knobs with a default value.
@UseCase(name: 'Default', type: Text) Widget constantValueUseCase(BuildContext context) { return Text(Random().nextInt(10).toString()); return Text( context.knobs.string(label: 'value', defaultValue: '10'), ); }