Fixtures support for the Live View

[gilberto-torrezan]

trafficstars

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

• When developing data-driven views, the fixture file can provide mock data, so the data-drive components wouldn't appear empty in the Live View;
• When developing forms, the fixture files can provide data in different states, such as complete, incomplete, erroneous and so on, so the client-side validation can be easily visualized and tested;
• When developing components, the fixture file can provide multiple states for the component, so the developer can easily toggle and mix and match those states in the Live View UI for quick prototyping;
• The same fixtures used for development of the UI can be used later on for automated UI tests.

[jouni]

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.