Another bike to fight callback hell in javascript

It is believed that the JavaScript world is booming: new language standards are regularly published, new syntactic features appear, and developers immediately adapt and rewrite all their frameworks, libraries, and other projects so that all this is used. Now, for example, if you still write in the code var, and not const or let, then this is sort of like a moveton. And if the function is not described using the arrow syntax, then it's a shame ...

However, all these const-s, let-s, class-s and most other innovations are nothing more than cosmetics, which, although it makes the code more beautiful, does not solve really acute problems.

I think that the main problem of JavaScript, which has long been ripe and overripe, and which should have been resolved in the first place, is the impossibility of suspending execution, and as a result, the need to do everything through callbacks.
')

What are good callbacks?

In my opinion, only by giving us eventfulness and asynchrony, which allows us to instantly respond to events, do a great job in one process, save resources, etc.

What are bad callbacks?

The first thing a newbie usually encounters is the fact that as the complexity grows, the code quickly turns into incomprehensible, repeatedly embedded blocks - “callback hell”:

fetch(“list_of_urls”, function(array_of_urls){ for(var i=0; array_of_urls.length; i++) { fetch(array_of_urls[i], function(profile){ fetch(profile.imageUrl, function(image){ ... }); }); } }); 

Secondly, if functions with callbacks are connected to each other by logic, then this logic has to be split up and put into separate named functions or modules. For example, the code above will execute the “for” loop and start the fetch set (array_of_urls [i] ... instantly, and if array_of_urls is too large, then the JavaScript engine will hang and / or crash with an error.

This can be dealt with by rewriting the “for” loop into a recursive function with a callback, but recursion can overflow the stack and also drop the engine. In addition, recursive programs are more difficult to understand.

Other solutions require the use of additional tools or libraries:

• Promises - allows you to write callback code inside certain objects. As a result, these are the same callbacks, but with less nesting and chained together:
  
  

   firstMethod().then(secondMethod).then(thirdMethod); 

  
  In my opinion Promises is a crutch, because
  
  
  1. chains call functions in only one given order,
  2. if the order can change according to some logic, you still have to split the logic in callbacks into separate functions,
  3. to encode logic between functions, you still have to invent something, instead of just using standard if, for, while, etc.
  4. logic with Promises looks obscure.
  
  
• async (library) - allows you to declare an array of functions with callbacks, and execute them one after the other, or simultaneously. The disadvantages are the same as those of Promises.
• async / await - a new feature in JavaScript, based on generators, allows you to stop and resume the execution of a function.

The future, apparently, for async / await, but so far this future has not come, and many engines do not support this feature.

In order to be able to execute code with async / await on JavaScript 2015 engines that are currently relevant, transpilers were created - code converters from new JavaScript to old. The most famous of them, Babel, allows you to convert Javascript 2017 code with async / await in JavaScript 2015 and run it on almost all engines currently used.

It looks like this:

JavaScript 2017 source code:

 async function notifyUserFriends(user_id) { var friends = await getUserFriends(user_id); for(var i=0; i<friends.length; i++) { friend = await getUser(friends[i].id); var sent = await sendEmail(freind.email,"subject","body"); } } 

Converted JavaScript code 2015:


To be able to debug such code, you need to configure and use much of what is listed in this article .

All this in itself requires nontrivial efforts. In addition, Babel draws about 100 kb of the minified code "babel-polyfill", and the converted code works slowly (which is indirectly hinted at by the numerous constructions case number_string in the generated code).

Looking at all this, I decided to write my bike - SynJS. It allows you to write and synchronously execute code with callbacks:

 function myTestFunction1(paramA,paramB) { var res, i = 0; while (i < 5) { setTimeout(function () { res = 'i=' + i; SynJS.resume(_synjsContext); // < –-   ,    }, 1000); SynJS.wait(); // < – ,   console.log(res, new Date()); i++; } return "myTestFunction1 finished"; } 

You can execute the function as follows:

 SynJS.run(myTestFunction1,null, function (ret) { console.log('done all:', ret); }); 

The result will be:

 i=0 Wed Dec 21 2016 11:45:33 GMT-0700 (Mountain Standard Time) i=1 Wed Dec 21 2016 11:45:34 GMT-0700 (Mountain Standard Time) i=2 Wed Dec 21 2016 11:45:35 GMT-0700 (Mountain Standard Time) i=3 Wed Dec 21 2016 11:45:36 GMT-0700 (Mountain Standard Time) i=4 Wed Dec 21 2016 11:45:37 GMT-0700 (Mountain Standard Time) 

Compared to Babel, he:

• lighter (35kb without minimization),
• has no dependencies
• does not require compilation
• executes about 40 times faster (although this may not be so critical when working with slower functions).

SynJS takes a pointer to a function as a parameter, parses this function into individual operators (parses the nested operators recursively, if necessary), wraps them all in a function, and places these functions in a tree structure equivalent to the function code. Then, an execution context is created in which local variables, parameters, current stack status, program counters, and other information needed to stop and continue execution are stored. After that, the statements in the tree structure are executed one by one, using the context as the data store.

The function can be performed via SynJS as follows:

 SynJS.run(funcPtr,obj, param1, param2 [, more params],callback) 

Options:

- funcPtr: a pointer to the function to be executed synchronously
- obj: an object that will be available in the function through this
- param1, param2: parameters
- callback: function to be executed upon completion

In order to wait for the completion of the callback in SynJS, there is a SynJS.wait () operator that allows you to stop the execution of the function launched via SynJS.run (). The operator can take 3 forms:

- SynJS.wait () - stops execution until SynJS.resume () is called
- SynJS.wait (number_of_milliseconds) - suspends execution for the time number_of_milliseconds
- SynJS.wait (some_non_numeric_expr) - checks (!! some_non_numeric_expr), and stops the execution if false.

With SynJS.wait, you can expect the completion of one or more callbacks:

  var cb1, cb2; setTimeout(function () { cb1 = true; SynJS.resume(_synjsContext); }, 1000); setTimeout(function () { cb2 = true; SynJS.resume(_synjsContext); }, 2000); SynJS.wait(cb1 && cb2); 

To give a signal about the completion of the callback in the main thread, use the function

SynJS.resume (context)

The required context parameter contains a link to the execution context that needs to be notified (since each call to SynJS.run creates and runs a separate context, there can be several running contexts in the system at the same time).

When parsing, SynJS wraps each statement into a function as follows:

 function(_synjsContext) { ...   ... } 

Thus, the _synjsContext parameter in the callback code can be used to signal the completion:

 SynJS.resume(_synjsContext); 

Handling local variables.

When parsing the body of a function, SynJS determines the declarations of local variables by the keyword var, and creates a hash for them in the execution context. When wrapping a function, the operator code is modified, and all references to local variables are replaced with references to the hash in the execution context.

For example, if the source statement in the function body looked like this:

  var i, res; ... setTimeout(function() { res = 'i='+i; SynJS.resume(_synjsContext); },1000); 

then the operator wrapped in the function will look like this:

 function(_synjsContext) { setTimeout(function() { _synjsContext.localVars.res = 'i='+_synjsContext.localVars.i; SynJS.resume(_synjsContext); },1000); } 

Some examples of using SynJS

1. Select from the database an array of parent records, for each of them get a list of children .

2. According to the list of URLs, receive them one by one until the content of the URL satisfies the condition.


3. In the database, bypass all children, grandchildren, etc. some parent.


At the moment I use SynJS to write browser tests in which I want to imitate complex user scripts (click "New", fill out a form, click "Save", wait, check what was written through the API, etc.) - SynJS allows you to reduce code, and most importantly, increase its clarity.

I hope that someone will also find it useful until the bright future has come with async / await.

→ Project on githaba
→ NPM

PS I almost forgot, SynJS has an operator SynJS.goto (). Why not?