Parket: My take on a State Management Library
Tags: showdev, javascript, webdev, react
Published: 2018-02-05 02:12:56

---
title: "Parket: My take on a State Management Library"
published: true
description: A state management lib heavily inspired by mobx-state-tree
tags: showdev, javascript, webdev, react
---

[![](https://thepracticaldev.s3.amazonaws.com/i/54fet5tddzresi3aoucp.png)](https://github.com/ForsakenHarmony/parket)
<div align="center"><a href="https://github.com/ForsakenHarmony/parket">^ click here to get to the github repo</a></div>

## How would you describe Parket to someone who has never heard of it?

Parket is a state management library, a well known example would be Redux. It's heavily inspired by mobx-state-tree, which I didn't use because of the rather large file size.

Parket lets you create models with state, actions and views, these can later be used by instantiating them and can be nested inside each other.

## How does Parket work?

Parket internally uses Proxies. Proxy is a newish feature which allows you to wrap objects and manage get and set access to it, it's like adding a getter and setter to every property, but also applies to new properties added.

## How does Parket differ from other solutions?

A lot of state management libs seem to focus on immutability a lot, every state update has to return an immutable object. I just manage mutability via the proxies so you can't set anything outside of actions, you also don't have to return anything or call setState and the likes, becuase it's listening to the state changes and sends events based on those.

### A basic example

```js
import model from 'parket';

const Person = model('Person', {
  initial: () => ({
    firstname: null,
    lastname: null,
  }),
  actions: state => ({
    setFirstName (first) {
      state.firstname = first;
    },
    setLastName (last) {
      state.lastname = last;
    },
  }),
  views: state => ({
    fullname: () => `${state.firstname} ${state.lastname}`,
  }),
});

const instance = Person({ firstname: 'Tom' });
```

As you can see, the state gets passed to the actions, which just modify it without doing anything special. The same thing happens with views, but those only read from the state, with the same restrictions as accessing it from the outside. The views get updates on every state change.

Anyone familiar with mobx-state-tree will probably see the similarities. You define a model for the state and can reuse it, which is useful mostly for nested models, i.e. todos in a todo list. I have also adapted the mst todomvc example to parket, which you can find in the repo.

When instantiating the model you can pass an object to get merged into state. (I might change this to just pass it into the initial function, because it can currently override nested objects)

### Async

```js
const Async = model('Async', {
  initial: () => ({
    loading: false,
    result: null,
  }),
  actions: self => ({
    async doSomethingAsync() {
      self.loading = true;
      // be aware that you should handle errors ( /rejections )
      self.result = await somethingAsync();
      self.loading = false;
    },
  })
});
```

As you can see here, parket really doesn't care what your action does or rather what it is, it just listens to state changes.

## Why did you develop Parket?

I found mobx-state-tree a while ago and immediately liked it, but it and the dependency to mobx it's rather big in terms of file size. And being in the preact core team I obviously had to make something smaller, so after failing 2 times, Parket was born (~1.5kB).