bi-st - Vaadin Add-on Directory
Manage binding between UI elements and history.state[![Published on webcomponents.org](https://img.shields.io/badge/webcomponents.org-published-blue.svg)](https://www.webcomponents.org/element/bi-st)
# bi-st
bi-st **bi**nds elements to the window.history.**st**ate object. Its purpose is to take the long, drawn-out 99% unambiguously unidirectional markup [seen here](https://github.com/bahrus/purr-sist#example-a1----time-travel-support-aka-back-button), and roll it up into a nice compact sushi roll. To help visualize this analogy, see Figure 1 below.
![](https://media.giphy.com/media/RO023EYTyk5yg/giphy.gif "Figure 1")
**Figure 1**
What we get is more compact and more flexible, which is good, but less clearly unidirectional, and a little less declarative, which, in my book, is not so good.
## Syntax:
The syntax for binding a UI element is shown below.
```html
```
The demo shown [here](https://bahrus.github.io/bi-st-demos/index.html) does the following:
1. Allows the user to enter arbitary key value pairs into an object.
2. The data the user enters is put into history.state.
3. History.state is persisted to a remote datastore.
The total number of lines of markup is [only slightly fewer](https://bahrus.github.io/bi-st-demos/index.htm) than the example shown [here (view source)](https://bahrus.github.io/purr-sist-demos/Example3.html), that does the same thing without the benefit of this component. In particular, the number of lines drops from 129 lines to 110 lines.
However, as a page increases in complexity, with large numbers of UI elements, this component should help significantly reduce the amount of boilerplate. Markup shown below.
## What's so great about history.state?
One of the trappings of a component library, like Vueactulitymber, is that each such library ships with a state manager / render binding. But what if you want to combine components together using different libraries? A tempting choice is to say "use Redux, or MobX, or RxJs, or CycleJS" to unify the state management. But this tends to enforce a "library / framework" choice of its own. For small applications / teams this may be fine, but what if you are working with a large application, that spans multiple generations of component libraries, involving loosely coupled teams?
Why not use the platform, and utilize something that will forevermore (?) ship with every browser? That supports time travel, and routing?
It should be noted that AMP components (like amp-bind) seem to ba based on the same principle.
```html
Example 1
```
View on NPMView on GitHub
bi-st version 0.0.0
### Dependencies
bi-st version 0.0.1
### Dependencies
* xtal-latx#0.0.60
* xtal-state#0.0.55
bi-st version 0.0.2
### Dependencies
* xtal-latx#0.0.88
* xtal-state#0.0.67
bi-st version 0.0.3
### Dependencies
* xtal-latx#0.0.88
* xtal-state#0.0.67
bi-st version 0.0.4
### Dependencies
* xtal-latx#0.0.88
* xtal-state#0.0.67
bi-st version 0.0.5
### Dependencies
* xtal-state#0.0.84
* xtal-element#0.0.58
* trans-render#0.0.110
bi-st version 0.0.6
### Dependencies
* xtal-state#0.0.84
* xtal-element#0.0.58
* trans-render#0.0.110
bi-st version 0.0.7
### Dependencies
* xtal-state#0.0.85
* xtal-element#0.0.59
* trans-render#0.0.111