data-tier relies on an
Observable-driven event cycle, having an embedded
object-observer as the default
It is highly advised to briefly review the library's Lifecycle documentation for a main concepts. Once ready,
data-tier's approach to client app architecture will also have a bunch of useful information on when and how to employ data binding in a modern client applications in a non-intrusive, non-prisoning, managable and extensible way.
61+ | 60+ | 79+
- updated dependencies
- added release automation
- removed Travis CI (in favor of GitHub actions)
Loading the library
There is a growing number of examples and ready to run tutorials in the repo self (
docs/tutorials), but even more convenient is to play with the
CodePen snippets below:
- DataTier binding with regular DOM elements - simple
spanreflecting the changed value
- WebComponent scoped binding - this time we have
inputtied to the reflecting
inputevent (immediate changes), while all of those scoped within a
web-component, each instance if which has its own encapsulated model
- ... more to come :)
As many similar libraries do,
data-tier also employes the two:
- declarative part of binding views to model found in HTML
Let's see how it plays in the code.
functional (JS) part
Having data model defined, for example, as:
let bands =id: 1234name: 'Dream Theater'since: 1985albums:id: 2345 year: 1988 name: 'When Dream and Day Unite'id: 2346 year: 1991 name: 'Images and Words';
one can create a
tie keyed, say, 'bandsTie', having its data set to the bands array:
const bandsModel = DataTierties;
create API returns an
Observable clone of the provided
If no model provided,
data-tierwill create an empty object model by default.
bandsModel from our example may be operated on as a usual JS
array, but it is also being observed by
data-tier for any (deep) changes.
Any direct (JS driven) change will be reflected in the tied views.
Also, any relevant changes from the views will be reflected in the
declarative (HTML) part
Any UI element may be tied to the model using the key and the path:
For more details see API reference.
I believe, that
data-tier as a framework should serve a single purpose of tying the model with the view in its very basic form: propagating the changes/values to the relevant recipient/s (more conceptual details and examples here).
router and other well known UI paradigms should be provided by a dedicated components, probably, yet not necessary, built on top of
data-tier or any other framework.
Me myself investing some effort in building
data-tier oriented components. I'll maintain the list below, updating it from time to time (please update me if you have something to add here).
data-tier-list- repeater-like component to render a list of a similar items based on a single template
i18n- internationalization library, mostly concerned with translation, where dynamic replacement of the localized texts upon active locale change is driven by