StateController. Event model in the development of interfaces. Part 2

Part 1

In this article, we will look at the basic concepts of the StateController event model.

Event distribution areas

In the selective application model, work is carried out with those elements that were previously selected for work. In a pure event model, the event should extend to all elements of the DOM tree. This is completely irrelevant on small volumes, but with an increase in the number of nodes, the degradation of speed will not even be linear. Imagine that a click event must go through all the nodes to determine exactly which elements it will work on. There is an assumption that the pseudo-class :hover in IE6 did just that, which is why it slowed down so much.
')
In order to somehow speed up the work of the event generator, without forcing it to constantly bypass the entire node tree, the best solution is to limit the distribution of events. In fact, we use a selective model inside the event, but with some limitations.

Event propagation zones allow you to solve another problem - you can skillfully manipulate the result, which is obtained after crawling all the nodes. To better understand this, I will give a simple example.

For example, you have a team of programmers whose skills you do not know. Someone can write well in certain languages, someone copes better with database queries, someone creates great architecture, and someone can be a born team leader. You have the task to write a project in a specific language, without using a database. What are you doing? You go and generate two events.

1. Anyone who can write in X, a step forward
2. To form a team of the released.

In such a simple way, we drastically reduced the distribution area of ​​the event in the second paragraph to certain developers.

Let me give you another example that shows a bit more precisely how the result can be manipulated through the event distribution zones.
Suppose you have two buttons: “Save” and “Clear”.
The behavior of the "Clear" button

1. Clear all form elements ( clear_form event)
2. Hide validation error messages that may remain from previous data clear_form ( clear_form event)
3. Return dynamically created form elements to their original form ( clear_form event)

Behavior of the Save button

1. Hide validation error messages ( clear_form event)
2. Send data to server ( submit_form event)

As you can see, we have at least one action that is the same for both buttons: hide validation error messages. But if we run the clear_form event on the save button without specifying the event propagation zone, we will get erroneous behavior — our form will be cleared and returned to the pristine form before being sent. We need to run a cleaning event on all form elements when clicking on the “Clear” button, and only on error message elements, if clear_form generated by the “Save” button.

StateController restrictions

The framework intentionally does not use complex selectors, limited to the following list.

• parent
• childNodes
• nodeName

This is done intentionally to keep under control the number of items that fall within the event distribution area. The restriction played an excellent service, forcing a more organized approach to the structures of HTML, at the same time reducing the number of potential errors.

By default, the event applies to all elements within the container ( container.getElementsByTagName(*) ).

The container from which the start of the event begins is always within the visibility of the handlers. You can combine parameters, indicating, for example, the distribution zone: p: "childNodes,A,SPAN" , which means distributing events to a container, its children, as well as elements A and SPAN inside this container.

Handlers

As I wrote in the first part, the process of hanging handlers was transferred directly to the structure of HTML. From the point of view of the classical scheme of unobtrusive JS, this is considered to be a terrible sin and for this, at least, an exorcism ceremony is laid. However, it is worth looking at this solution from the other side. Every time additional content is loaded (do not forget that I have one-page applications), I would have to hang handlers on all nodes for a long time and persistently. And imagine what an unobtrusive JS code will look like.

The JavaScript part of the module is usually a set of scripts, so the developer rarely drops in there while working on the code. Much more time is spent working with the final HTML structures: templating and describing the logic of the code. Well, why not add handlers there?

StateController uses a special attribute SC , which contains a list of handlers for certain events and parameters for them. The attribute contains plain text directives that are parsed once when the event is first launched in this visibility zone. The event event crawler already works with the object structure, due to which approximately fivefold acceleration is achieved compared to the first launch.

Handler code is registered separately, and in general the process is similar to adding plug-ins in any framework.

Running and event handling

After triggering the event, the StateController selects a certain array of nodes, taking into account the distribution zone filter. Further, only those nodes that contain the SC attribute are selected from this array. Among these nodes are selected those that have handlers that respond to this event. And after that, handlers are run for each of the remaining nodes. It is worth remembering that the movement on the node tree is carried out from the last node to the first.

Event parameterization

Unlike the standard browser event model, StateController has several useful tweaks. Events can be parameterized, i.e. represent not just the name of the event, but a key / value pair. This is necessary when generating events like “activated third tab”, “error No. 38”, “sending block data with contact data”, “reloading block with list of users”.

Additional data

Additional data can “travel” with each event. This is a regular container object. Handlers can modify the fields in this container as they perform some actions. Often it is used to collect some data. For example, we often use the collection of the contents of form fields directly in JSON.

Event levels

Event levels provide additional flexibility, allowing you to create a local event distribution area. For example, in the example with the “Save” button described above, you can fire up the clear_form event with a certain trigger level, thereby allowing the developer and the nodes to decide who will perform what actions.

Documentation and examples

Framework code
Documentation
How it works
Examples of using

The following article will look at an example of using

Thanks for attention!