State and rendering

The state of HtmlElements are always specified by their attributes (see Featuring HtmlElements). Some HtmlElements have more sophisticated features than standard HtmlElement: the Custom Elements. Those need to render and use javascript to keep up to date. Yet they still they have their state at the attributes (see i-tags).

The state of application-data can be represented with views (see i-views). Here, the state is to complex to set on the attribute, but the i-view always is a representation of the data.

Featuring HtmlElement need no custom rendering. The state is set at the attributes. Modules who can add this extra functionality, do this by setting additional attributes on the HtmlElement. After this is set, the HtmlElement has its extra features, but needs no rendering. All logic is delivered by the module and operates using delegated dom-events.

Example of modules that add functionality to HtmlElements:

• itsa/drag
• itsa/drag-drop

Example of modules that deliver featured HtmlElements:

• itags/fonts

i-tags is ITSA's implementation of Custom Elements. They are new created HtmlElement, that may look like this:

    <i-checkbox></i-checkbox>

i-tags differ from featured HtmlElements in a way that they need to render to get their final form. They do hold their state inside their attributes, meaning that they will re-render when one of their attrubite changes. All logic is delivered by the module and operates using delegated dom-events and monitoring state-change of the element.

i-tags are made in a way that they always can be rendered serverside. In order to do so, they never use any clientside specific features that custom elements offer (templates and shadow-dom).

Example of modules that add functionality to HtmlElements:

• itags/checkbox
• itags/slider
• itags/form
• itags/scroller
• itags/table

i-views is ITSA's implementation of MVC. An i-view is a part of the screen (mostly a div-element) which renders its content.

List of features:

• The state of all -or part- of the application-data is represented by the i-view. The state is not set on the attributes.
• Use unidirectional flow of data: the screen is a faithful representation of the state of the data in the application. i-views will auto-render on initialisation and with any application state-change.
• In order to render efficiently, they make use of a vDOM.
• Initial state of i-views can be rendered serverside.
• State can be bound to routing, so they will update based upon routing.

Example of i-view modules:

• itsa/iview