This is going to be an unpopular one but here goes...
I have been finding that writing my React applications using the MVVM pattern has been preeeetty pretty nice.
Let me explain.
The Problem
I know, I know.
Functional programming is the best programming.
React is functional by design so you should never do something different.
MVVM is the pattern used by Angular 🤮 and Vue 🤮.
Mutating variables is for plebs.
Yeah I know.
But have you ever;
had to migrate between an older version of React to a newer one and be a little stuck because your business logic depended on React features that had breaking changes? (e.g. class components -> functional components)
had performance issues tied to React's rendering cycle and struggle to address them because your business logic was tied to your presentation logic?
wished you could use use async/await in your components but are instead forced to thunk promises through a colossal state management digest cycle?
been stuck on testing React components, not exactly sure how to mock things?
gotten dizzy trying to think through functional components?
Yeah... Probably just me
Traffic Light
This is a super simple example but imagine a basic traffic light component.
You want the traffic light to start at green, stay green for 3000ms, transition to yellow for 500ms then red for 4000ms.
A likely conventional approach to this would be something like this:
const states = {
green: { duration: 3000, next: 'yellow' },
yellow: { duration: 500, next: 'red' },
red: { duration: 4000, next: 'green' },
}
function TrafficLight(props) {
const [color, setColor] = useState('green')
setTimeout(() => setColor(states[color].next), states[color].timeout)
return <div>{color}</div>
}
You might put the setTimeout in a useEffect to ensure you can cancel the timer but you get the point
LGTM, what's wrong here?
It's my view that the best projects are those that are accessible to engineers of all experience levels and that are architecturally resilient to lower quality contributions. After all, not everyone is a 10x developer with 20 years experience and that's okay, we can just factor that in.
For that to be the case; code needs to be plain, obvious and, unless required, avoid the use of clever framework-specific magic.
In the above example, the business logic is itself is tied to the render cycle of the framework. This has the effect of limiting the pool of contributors to "framework" engineers / React specialists.
In my travels I have seen many applications do this sort of thing, perhaps at a higher level of abstraction (embedded within state management solutions and so on), but when boiled down practically operating like this.
Alright, so what are you suggesting then?
Let's separate this problem into two halves.
- Represent the state for the view
- Render the state for the view
The View Model
Lets make a basic container for the view state.
const sleep = duration => new Promise(res => setTimeout(res, duration))
const states = {
green: { duration: 3000, next: 'yellow' },
yellow: { duration: 500, next: 'red' },
red: { duration: 4000, next: 'green' },
}
class TrafficLightView {
@reactive color = 'green'
#active = true
async onInit() {
while(this.#active) {
await sleep(states[this.color].duration)
this.color = states[this.color].next
}
}
onDestroy() {
this.#active = false
}
}
I know, I know, I am using a disgusting class 🤮.
Don't worry, as long as you never use extends, it's just a convenient way to group state and associated functions together. Composition over inheritance ✨
So why is this good?
Firstly, it doesn't matter if you're a React developer, Angular developer, C++ developer, functional programmer, non-functional programmer - you understand what's going on here.
Secondly, you can use async/await, which is pretty nice IMO
Lastly, while testing this still requires mocking a global variable (we can fix that), you can assert success against object properties rather than against DOM changes.
Quick Note on Reactivity
I don't want to dive deeply into this but let's assume you're using something like Mobx where you can decorate class properties to trigger renders when properties change.
If people are interested, I'll write another article on how reactivity works.
import { reactive, subscribe, useViewModel } from './rx.ts'
class TrafficLightView {
// Converts "count" into a getter/setter
@reactive
count = 0
// Called by "useViewModel" hook
async onInit() {
this.count = 1
}
// Called by "useViewModel" hook
async onDestroy() {
console.log('bye')
}
}
const tlv = new TrafficLightView()
subscribe(tlv, () => console.log(tlv.count))
tlv.onInit()
The Presentation Layer
So how do we consume this in React?
Let's use the useViewModel hook from our library
import { reactive, subscribe, useViewModel } from './rx.ts'
import { sleep } from './utils.ts'
const states = { /* ... */}
class TrafficLightView {
@reactive
color = 'green'
#active = true
async onInit() {
while(this.#active) {
await sleep(states[this.color].duration)
this.color = states[this.color].next
}
}
onDestroy() {
this.#active = false
}
}
function TrafficLight() {
const vm = useViewModel(() => new TrafficLightView())
return <div>{vm.color}</div>
}
A Real Use Case
I know the above implementation is more verbose when compared to the more conventional React approach - however the benefits start to shine through when applied to something less trivial.
Say we have a REST API we want to talk to that has paginated results and we want to ensure that the API layer is abstracted away such that it can be tested without the framework.
This is just plain, framework agnostic, TypeScript:
export type Gif = {
id: string
url: string
image: string
}
class GiphyService {
async *getTrending(): AsyncIterableIterator<Gif[]> {
let offset = 0
while (true) {
const response = await fetch(
`https://api.giphy.com/v1/gifs/trending?offset=${offset}&limit=20`
);
if (!response.ok) {
throw new Error("Request failed")
}
yield (await response.json()).data
offset += 20
}
}
}
This service provides you the trending gifs in the form of an async iterator where pagination is automatically handled when the iterator is advanced
const giphyService = new GiphyService()
const pages = giphyService.getTrending()
const page1 = await pages.next()
const page2 = await pages.next()
const page3 = await pages.next()
Let's write a View Model + Component
class HomePageViewModel {
#pages: AsyncIterableIterator<Gif[]>
@reactive gifs: Gif[]
constructor(giphyService: GiphyService) {
this.gifs = []
this.#pages = giphyService.getTrending()
this.loadMore()
}
async loadMore() {
// Mutation triggers a re-render
this.gifs.push(...await this.#pages.next())
}
}
function HomePage({ giphyService }) {
const vm = useViewModel(() => new HomePageViewModel(giphyService))
return <div>
<div>
{vm.gifs.map(gif => <img
key={gif.image}
src={gif.image} />)}
</div>
<button
onClick={() => vm.loadMore()}>
Load More
</button>
</div>
}
Notice how the template now only contains logic to handle presenting the data rather than managing presentation and state.
This also enables us to use async/await to drive React rendering, something that is otherwise a little annoying.
Now the GiphyService can be tested by itself and the component can be tested by itself.
Other Advantages, Forms
class HomeViewModel {
@reactive
input = new FormField('')
}
function Home(props) {
const vm = useViewModel(() => new HomeViewModel())
return <div>
<input {...vm.input} />
</div>
}
Where FormField looks like:
class FormField {
@reactive
value
constructor(defaultValue) {
this.value = value
}
onChange = (event) => {this.value = event.target.value}
}
Now we can expand this field type with validation, validation states and even create larger abstractions like FormGroup which composes multiple FormField objects.
class HomeViewModel {
@reactive
form = new FormGroup({
name: new FormField({
placeholder: 'Enter your name',
defaultValue: '',
}),
email: new FormField({
placeholder: 'Enter your email',
defaultValue: '',
validators: [emailValidator]
})
})
async submit() {
if (!this.form.isValid) {
alert('Form not valid!')
}
await submitToApi(this.form.toJSON())
}
}
function Home(props) {
const vm = useViewModel(() => new HomeViewModel())
return <div>
<input {...vm.form.name} />
<input {...vm.form.email} />
</div>
}
Perhaps even generating forms directly from the state
function Home(props) {
const vm = useViewModel(() => new HomeViewModel())
return <div>
{vm.form.fields.map(field => <input {...field} />)}
</div>
}
Again, the objective is to keep the component code minimal, focused as much as possible on presentation whist the view model can be groked with eyes that are not specialized to React.
Closing Thoughts
It's a bit unconventional, but I feel that the intersection of the MVVM/MVC worlds of Angular and Vue with the React world has the potential to improve the readability, testability and portability of React projects.
It doesn't require anything fancy to implement and, though unconventional, it feels like it naturally fits within React
Top comments (0)