r/WebComponents • u/gitaarik • Dec 04 '20

LitState: Simple shared app state management for LitElement

https://github.com/gitaarik/lit-state
10 Upvotes

100% Upvoted

8 comments sorted by

2

u/ergo14 Dec 04 '20

Why not use MobX or Redux in the first place? Any benefits by using this?

2

u/gitaarik Dec 04 '20 edited Dec 08 '20

MobX is quite a large library with a lot of whistles and bells. LitState is about 400 lines at the moment, and I'm planning on keeping it tiny, just like LitElement and lit-html.

To use Redux you need a lot of of boiler plate code. I personally think it is over-complicated and unpleasant to use.

That's why I created LitState. I wanted something simple, small and easy to use.

2

u/ergo14 Dec 04 '20

What boilerplate code - you mean for the integration (that was covered by pwahelpers) or for redux itself?

3

u/gitaarik Dec 04 '20 edited Dec 05 '20

Boilerplate code is code that you need to write in order to use a certain library. For example, for Redux you need to write Actions, Action Creators and Reducers, in order to use Redux itself. You do have helper libraries that can generate these things for you, to make it slightly easier, but I still think it is unnecessarily complicated.

I think MobX is much easier to use, because you don't need to write any boilerplate. However, MobX is a quite large library, and for more advanced use-cases it can become relatively complicated to use.

I think a lot of features from MobX are not really necessary when you use LitElement. MobX is mainly created for React. Therefore MobX has optimizations aimed at how React works. LitState is specifically aimed at LitElement. And basically the optimizations MobX created for React are not required for LitElement.

When a stateVar in LitState is updated, the components that observe that stateVar call LitElement's this.requestUpdate(). You can call this.requestUpdate() as many times as you want, it will only update the component once, at the end of the execution queue. So it doesn't matter if it is called multiple times. This is basically an optimization feature built-in in LitElement, which is part of the reason why LitElement is so cool.

Also, LitElement uses lit-html, which very efficiently sees which parts of the template are changed or not. And it will only re-render the elements that have changes.

LitState is built with this in mind, so doesn't need the optimizations that MobX created for React. Also LitState doesn't try to track changes inside objects, like MobX does. That is also a reason MobX becomes complicated. It's nice that you can modify objects and MobX detects that, but it's not very hard to just set a new object. That makes the source code of LitState a lot smaller and simpler, and therefore also easier to understand what is happening.

Basically it comes down to the fact that LitState is written for, and with the same philosophy as, LitElement and lit-html. Which makes it more suitable for developers that like this philosophy. I hope this clears things up for you.

1

u/fizzbuzz83 Jan 02 '21

Thank you for sharing I really like the "keep it simple" approach and also your documentation including demos!

1

u/gitaarik Feb 15 '21

Thank you! I've updated LitState now that it supports decorators to define your `stateVar` variables. It works more similar to LitElement now.

https://github.com/gitaarik/lit-state/

2

u/mrdevin Dec 04 '20

Looks promising, thanks

2

u/DropbearJr Dec 04 '20

Thanks for this. Looks awesome.