(I need to get this out of the way first, why call it stiva? what is with the boat? Stiva is italian for a hold, like a boat or an airplane hold, so stiva is a hold for your data, there ya go.)
Once upon a time I developed apps. I used javascript, html, and css. Then I started dabbling in frameworks and loved some of the advantages to them, such as state management in redux, and then I started using native elements (web components) and really missed that layer that redux gave me. So I created Stiva. It is a layer of state management that is really awesome.
Here lives Stiva: https://github.com/LuceStudio/stiva/blob/master/stiva.js
What is so magical about 358 bytes (yep, that is a 1/3 of a kilobyte) of code?
Stiva works by creating an abstraction to your data stores, it is the single source of truth for your data. Anything can update your data, then anything can be notified the data changed. This is really key because components aren’t the only things that interact with it, your services can update and be updated by it, so real time data flow can occur easily.
This is useful for a lot of things, but it was built for native web components. Let me compare it to a popular combination of React & Redux. The way that React is built is that the top most component has to know what the internal components need. The parents telling the children just what to do. That is how the data flow works.
In the model above the top most component has to know what all containing elements need and it distributes accordingly, but react doesn’t have a Shadow and Light DOM. Having those changes everything.
In the native web component world we have a different diagram.
The blue represents the Shadow DOM and the white represents the Light DOM. Data needs to be fed through the element for immediate children on the Shadow DOM side, but that relationship doesn’t exist on the Light DOM side. The parents don’t tell the component how to behave, only a few very limited exceptions to that.
So then how do we get data to each element? Stiva, that’s how. It uses an observer pattern to get data where it needs to be, and still keep the store separate from the presentation.
The use is very simple.
Each store, in this case ‘myStore,’ can be updated using the update function as above. It gives you the old store as a prop in the function. Each time you use update you give it back a new object. So if you need to update a store you do it like this:
When an update happens stiva pushes an event so if you want to listen to it inside of your component you can do this in you constructor.
The best part about this is that it doesn’t have to be your component, anything can listen, that means your service layer can listen and update the store. When it hears something it can send that back to the server, when it gets something from the server, it can push it into stiva. So you get realtime data to your interface, where ever the data needs to go. Hook that up to web sockets and now you have some pretty cool stuff!
There is just one more part to mention and that is the default state of the store. You can pass in an object that defines your stores on instantiation. Like so:
If you want to do some server-side links on intial page load you can do something along the lines of this, (a node.js example):
I am working on a different utility also that uses indexed DB to store data for the app and has a handshake with the service layer that it only needs to grab the changes of the data between the server and client. Making requests super small and persistent. Perfect for Progressive Web Apps! More on that later, but you can take a sneak peek if you’d like: https://codepen.io/coltpini/pen/OmgZXp?editors=0011
And that is Stiva!
Originally published at medium.com on June 9, 2017.
