Promise: how JavaScript describes a future result

Useful to know

Some operations in the program do not produce results immediately. A request to a server, for example, must go through an exchange before the application receives a response. Promise is an object that represents the future completion or failure of an asynchronous operation and the associated result. This allows the code to describe what happens after completion, rather than assuming that the value is already available. However, the mere presence of Promise does not explain what task the application performs. [1]

The object has states that distinguish waiting, successful execution, and rejection. Processing functions can be connected to it. The then method allows to set the next step, and catch is used to process a rejection in the chain. [1] It is useful to link these concepts to a specific result: the program expects data, receives it, or has to explain that the operation has not finished in the expected way. This is clearer than remembering only the names of the methods.

Let's take a look at a fictional exhibition selection application. It first receives a list of halls, and after selecting a hall it asks for its program. The second step depends on the result of the first. To correctly describe the flow, we can draw the sequence of words: receiving, selecting, re-receiving, displaying. Then for each step, we ask what the visitor sees if it is not yet finished. Thus, the technical sequence remains related to the actual operation of the interface.

The Promise circuits help pass the result of one operation to the next. Returning Promise from a processing function is important when the next step is to wait for this operation. [2] If this attitude is not described correctly, the code may appear to be arranged on the screen without presenting the required dependency. Therefore, when reviewing, it is useful to indicate which value is needed at each step, rather than just tracking the visual indentation of the lines.

Error handling is also part of the flow. In the learning example, a missing hall program, an unsuccessful exchange, and an unexpected data format can be distinguished. Not all cases need to be shown with the same message. The important thing is that the application has a clearly expected behavior for each selected scenario. We check to see if the wait indicator is ending and if the visitor understands what they can do next.

When writing a small function, it is useful for its name to suggest what value it promises to provide. The test scenario can then check exactly this value and the failure response. Promise provides the general model for the asynchronous result, while the quality of the program depends on precisely described dependencies, meaningful messages, and the predictable completion of the task for which the person has opened the page.