Understanding of JS messaging and event mechanisms _ javascript skills

The Message Event mechanism is available in almost all development languages. It is not the originality of deviceone. in some languages, it is called Message, and in some places it is called Message ). next, I will introduce you to the understanding of JS events and messaging mechanisms through this article. If you need to learn it together, the message/event mechanism is a mechanism that is available in almost all development languages, not the originality of deviceone, in some languages, it is called Message, and in some places it is called Message ). in fact, the principle is similar, but some implementation methods need to be more complex. The deviceone is called a message.

Basic Concepts

Some beginners are not familiar with this mechanism. First, let's briefly introduce some basic concepts. If you are familiar with it, you can skip this part.
A message can be understood as a data structure, which includes the following basic parts:

1. Message Source: the source of the message, the object that sends the message.

2. Message name: uniquely identifies a message.

3. Message data: the data attached to the message after it is sent. The data may be empty.

There are two types of messages:

1. system message: a message sent by the operating system or deviceone system. The message name is fixed.

2. Custom message: the message is defined by the developer and sent by the developer. The message name is random and can be defined at will.

Example:

For example, if you click a do_Button, a system message is triggered, which includes three parts:

1. Message Source: The button object in the user point

2. Message name: touch

3. Message data: the message has no attached data.

For example, a user triggers a custom event through the do_Button button, which contains three parts:

1. Source: button Object

2. Message name: User-defined message names, including aaa, bbb, and ccc.

3. Message data: The included data is set when the trigger message is sent.

Publishing/subscription Mode

The publishing/subscription mode is one of the most common design modes, and is the core of the message mechanism. It is characterized by reducing coupling and keeping two independent objects independent from each other. For a brief introduction, you can skip this step.

Let's first explain this problem from a simple example. For more information, see:

From this figure, we can see that

1. consumers and publishers do not know each other. consumers do not need to know which publisher the magazine they want. Publishers do not need to know which one has decided on the books published by their publishers.

2. Consumers and publishers must both know the post office.

3. The consumer needs to tell the post office consumer's name and address and the name of the magazine to be subscribed

4. Multiple consumers can subscribe to the same magazine.

5. After receiving the magazine, the Post Office will notify the consumer one by one and send the magazine to the consumer at the same time.

After reading the above example, let's take a look at the abstract description to make it clearer:

One-to-one correspondence with the above actual example:

1. The system/developer and function object do not depend on each other. The system/developer only triggers a message and does not care who will accept it.

2. the system/developer and function object must be able to obtain the message source object.

3. When a function object subscribes to a message, it must mark the message name and reference of the function object.

4. Multiple function objects can subscribe to messages with the same name from the same message source.

5. When the source message is sent, all subscribers are notified one by one, and data is transmitted to the callback function object.

After reading the abstract description, let's look at the actual example of deviceone development, or the do_Button example.

1. when a user clicks a button, the system will obtain the button object as the message source, and a "touch" message for the fire, any function object that subscribes to the "touch" message will receive the message and cause function execution.

// Obtain the button object var btn_hello = ui ("btn_hello"); // define the function object function f () {// when the btn_hello button receives a finger click, the following code deviceone will be executed. print ("f function receives trigger message")} function f () {// when the btn_hello button receives the finger click, the following code deviceone will be executed. print ("f function receives the trigger message")} // f, f subscribes to the touch message btn_hello.on ("touch", f) of the button; btn_hello.on ("touch ", f );

2. We can define two custom messages "message1" and "message2" for the button object. Two Function objects subscribe to the two messages respectively. However, the developer must call the fire function to trigger the message, which is different from the system message.

// Obtain the button object var btn_hello = ui ("btn_hello"); // define the function object function f (d) {// when the btn_hello button receives the message triggered by the developer, the following code is executed: deviceone. print ("f function receives the message. The message data is:" + d)} function f (d) {// when the btn_hello button receives the message triggered by the developer, the following code is executed: deviceone. print ("f function receives the message. The message data is:" + d)} // f. f subscribes to the touch message btn_hello.on ("message", f) of the button ); btn_hello.on ("message", f); // trigger message btn_hello.fire ("message", "data"); btn_hello.fire ("message", "data ");

You may wonder why we need to customize the object on the button? What is the significance of this? In fact, it is meaningless and unnecessary. Here we just use the button as an example. In normal development, this is basically not used.

Message usage

As mentioned above, deviceone messages are used now. The above example shows how to use system events and custom events.

I have several concepts to explain.

1. All deviceone objects, including UI, MM, and SM objects, can be message sources.

// The SM object can be the message source var page = sm ("do_Page"); page. on ("loaded", function () {// This is the system message of the page object. This message does not need to be manually triggered and the system will automatically trigger} page. on ("message", function (d) {// This is the custom message of the page Object} page. fire ("message", "data"); // The MM object can be the message source var http = mm ("do_Http"); http. on ("result", function () {// This is the system message of the http object. This message does not need to be manually triggered, received feedback from the http server will be automatically triggered} http. on ("message", function (d) {// This is the custom message of the http object} http. fire ("message", "data"); // The UI object can be an event source var alayout = ui ("alayout_id"); alayout. on ("touch", function () {// This is the system message of the alayout object. This message does not need to be manually triggered and will be triggered when clicked on the mobile phone} alayout. on ("message", function (d) {// This is the custom message of the alayout object} alayout. fire ("message", "data ");

2. The source object has a scope, so the subscribed and triggered sources must be the same object with a scope. Here we will use the data sharing and data transfer documents for your understanding.

As shown in the following example, test1.ui and test2.ui may be in a page scope or not in a job domain. Only messages in a fire scope can be correctly delivered to the callback function.

You can print the page address page. getAddress ().

// In test. ui. subscribe to messages in js var page = sm ("do_Page"); deviceone. print (page. getAddress (); page. on ("message", function (d) {deviceone. print (d);} // In test. ui. js trigger message var page = sm ("do_Page"); deviceone. print (page. getAddress (); page. fire ("message", "data ");

If the message is not in the same page scope, you can subscribe to the app scope that can be shared by two pages.
The code above is changed:

// In test. ui. subscribe to messages in js var app = sm ("do_App"); app. on ("message", function (d) {deviceone. print (d);} // In test. ui. js trigger message var app = sm ("do_App"); app. fire ("message", "data ");

3. The same function object can subscribe to messages from an object source repeatedly. When a message is sent, the function is executed multiple times. This is a common mistake for beginners.

Var page = sm ("do_Page"); var count =; function f () {deviceone. print ("execution times" + (count ++);} page. on ("message", f); page. on ("message", f); page. fire ("message ");

Looking at the example above, if it is executed, it will print 2. Because the subscription is made twice, maybe you will say who will write the code like this? The actual situation is certainly not so easy to see that repeated on functions are executed. In actual situations, for example, when you click an event to execute the on function, each time you click a button, you will subscribe to it again.

4. Message subscription must be performed before the message is triggered. This is a common mistake made by beginners.

Var page = sm ("do_Page"); var count =; function f () {deviceone. print ("execution times" + (count ++);} page. fire ("message"); page. on ("message", f );

Looking at the example above, if it is executed, it will be ineffective. Maybe you will say who will write the code like this? The actual situation is certainly not so easy to see that the order is reversed. The actual situation is often that, for example, when the on function is executed in a callback function of a function, you cannot determine when the callback function will be executed, whether to execute before the fire. In this case, you can add several deviceone. print to see if it is on or fire first.

5. If you have a subscription, You can unsubscribe. The function of unsubscribe is off. This function is rarely used because the current page scope subscription message is automatically released during closePage.

However, if the message subscription is in the app scope, you must note that you may need to manually cancel the subscription. Otherwise, the function will be executed multiple times during message trigger.

Var page = sm ("do_Page"); var count =; function f () {deviceone. print ("execution times" + (count ++);} page. on ("message", f); page. fire ("message ");. page. off ("message"); page. fire ("message ");

As shown in the preceding example, printing is executed only once, because the subscription is canceled once after the fire is executed.