Open gilberto-torrezan opened 3 years ago
The developer is able to create a separate companion file for its view, where he defines mock data needed for the view to be meaningful when presented in the Live View. This file is then stripped out of the production package once the app is build.
This is a bit too prescriptive IMO. I would think it would necessarily need to be a separate file.
Description
When developing data-driven views, such as with grids and charts, the developer is often presented with an empty preview, since there's no data to show.
This goes against the principles of the Live View feature - the preview needs to be accurate, fast and meaningful. An empty grid can be accurate and fast, but it's not meaningful for the development.
The Fixtures feature aims to solve this problem . The developer is able to create a separate companion file for its view, where he defines mock data needed for the view to be meaningful when presented in the Live View. This file is then stripped out of the production package once the app is build.
On top of providing mock data, the fixtures file can also provide specific states for a view, which the developer can then toggle on/off and mix and match states to achieve the desired result. Examples: when developing a button, the developer can define pressed/hovered/disabled states for the button, and select those states in the UI when building the view. In this sense the fixtures file provides a similar feature as Storybook with its stories.
The fixtures file can also be used as is for automated UI tests later on.
Use cases