react-create-view
provides a utility to standardize creating views that go through different states:loading
, success
, empty
, error
.
A View
is just a generic term for a UI that renders some stuff.
We’re used to building a view that makes an api call and can render something different depending if api call is loading, a success, errors out, or provides an empty list.
Like many of you, I work on a team and each team member handles this use case differently. The goal here is to standardize how a team builds these sort of views.
The createView
utility helps change code from something like this:

to something like this:

You have to use some imagination, but you may be able to tell which code example is easier to comprehend. I mean both examples technically work in the end. They render a different view based on the current state (success
, loading
, empty
, error
). However the first example requires a bit more mental jujitsu as there is a combo of if
conditions and the ternary operator to determine which UI to render.
The createView
utility however cleanly breaks these UI conditions into definitive components.
Essentially, you provide some TS generic types to createView
which represent a SuccessModel, FailureModel, LoadingModel, or EmptyModel
and write the component code for each state of the view where the props correspond to the provided model.
How do we provide the models to the view? The answer is a hook
.
Use the provided ViewModelProps
type to build your hook. The ViewModelProps
type is a TS union with a status
enum and a model
for each possible status
. When the status
is success
, the Success
component in createView
is rendered and so on.


Once you have your custom ViewModelProps
type, set it as the return value of a hook.

After that combine the hook and the view returned from createView
utility and viola

This also helps developers separate their View/UI from the business logic.
The view can easily be tested in something like Storybook and use mock data, while the hook can be responsible for actual business logic.
Power your hook with something like react-query
to handle api call states and you’re good to go.
The last thing to note is to create your models based on what the UI requires, not what the API supplies! The client should own its models, not the API. This way when API v2 comes out, you are not changing any logic in the view layer, but in the business logic layer or the hook.