StateController. An event model in the development of interfaces. Part 2

Part 1

In this article we will consider the basic concepts of the StateController event model.

Event Distribution Zones

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 absolutely not important at small volumes, but with an increase in the number of nodes, the degradation of speed will not even be linear. Imagine that an event clickmust go through all the nodes to determine which elements it will work on. There is speculation that the pseudo-class :hoverin IE6 did just that, so it slowed down so much.

In order to somehow speed up the work of the event generator, without forcing it to constantly go around the entire tree of nodes, the best solution is to limit the distribution zones of events. In fact, we use a selective model inside the event model, but with some limitations.

Event propagation zones allow solving another problem as well - you can skillfully manipulate the result that is obtained after traversing 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 knows how to write well in certain languages, someone copes best with database queries, someone perfectly creates architectures, and someone is given to be a native team leader. You have the task of writing a project in a specific language, without using a database. What are you doing? You go and generate two events.

1. Everyone who can write in X is a step forward
2. Form a team of those who have left.

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

I will give one more example, which shows a little more precisely how the result can be manipulated through the zones of event distribution.
Suppose you have two buttons: Save and Clear.
The behavior of the Clear button

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

Save Button Behavior

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

As you can see, we have at least one action that is the same for both buttons: hide validation error messages. But if we start the event clear_formon the save button without specifying the zone of distribution of the event, then we will get erroneous behavior - our form will be cleaned and returned to a virgin state before sending. We need to trigger a cleanup event on all elements of the form when we click on the "Clear" button, and only on the elements of error messages, if clear_formgenerated by the "Save" button.

StateController Limitations

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

• parent
• childNodes
• nodeName

This is done intentionally in order to control the number of elements that fall into the zone of distribution of the event. The restriction played an excellent service, forcing a more organized approach to HTML structures, while reducing the number of potential errors.

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

The container, from which the event starts, always falls into the scope of handlers. It is possible to combine parameters indicating, for example a spread area: p: "childNodes,A,SPAN"that is - to distribute the event to the container, its child elements, as well as the elements Aand SPANinside the container.

Handlers

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

The JavaScript part of the module is usually a set of scripts, so the developer rarely looks 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 a handler hook there?

StateController uses a special attribute SCthat contains a list of handlers for certain events and parameters for them. The attribute contains regular text directives that are parsed once at the time the event is first triggered in this visibility area. Repeatedly, the event handler already works with the object structure, due to which approximately five-fold acceleration is achieved compared to the first run.

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

Event triggering and handling

After the event is fired, the StateController selects a certain array of nodes, taking into account the filter of the distribution zone. Further, only those nodes that contain the SC attribute are selected from this array. Among these nodes, those are selected that have handlers that respond to this event. And after that, handlers are launched 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 event browser model, StateController has several useful tweaks. Events can be parameterized, i.e. They are not just the name of the event, but a key / value pair. This is necessary when generating events of the type “activated third tab”, “error No. 38”, “sending block data with contact data”, “reloading the block with the list of users”.

Additional data

With each event additional data can "travel". This is a regular container object. Handlers can modify the fields in this container as some actions are performed. Often it is used to collect some kind of 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 zone. For example, in the example with the “Save” button described above, you can trigger an event clear_formwith a certain trigger level, thereby allowing the developer and the nodes to decide for themselves who will perform what actions.

Documentation and Examples

Framework code
Documentation
How it works
Examples of use

The next article will consider an example of use

Thank you for your attention!