Some Thoughts On The Return Statement

First of all, the javascript return is a statement. Not a function.

On the surface statements and functions are commands for the javascript engine to ‘does something’. Technically however they are different. A statement is a command that doesn’t return a value.

A function can be called from anywhere in the javascript environment -no matter where it is defined- and it is often used to return a value. A function in a program is a subroutine.

A subroutine is a sequence of program instructions that perform a specific task, packaged as a unit. This unit can then be used in programs wherever that particular task should be performed.

-Wikipedia

The return statement ends the execution of a function in a JS environment and its used to specify a value (object, array, variables) to be returned to the function’s caller scope.

Above here what happens?

Especially with our return statement.

Pseudo-code explaining the function

1. We initialise the user variable , declare it as an array of users. These elements are objects themselves with props.
2. Line two is a counter set to start at zero
3. A filter function that will create a new array based off the condition we have defined in the function.
4. Notice the arrow function ? Collapses our function and makes it easy to read(If our conditional in the function was to be simpler using arrows would have been at least two lines shorter ). Not only that, it has been able to handle those weird .bind(this) situations.

Lets have a little discussion about arrow functions

What are some things you can see? The code is shorter and the this ‘works’ without a bind call.

I have written a short note on ES6 arrow functions at the end of this post.

TL;DR The ES6 arrow function syntax will always override any previously bound or dynamically determine the value of “this” and its awesome for the engine and for the code.

**

5. Finally, our iterator steps through our array based off our condition and returns the few elements who pass the “test”. On line return which is our focus. We see two values being returned to the filter method. The user gets returned. But state is “dropped”

‘State’ is not necessarily dropped, more like it is ignored. Why does the JS engine do this? Well the engine expects the element ‘e’ to be returned to the filter method, so as a matter of fact when you write some value or expression, declaration with the return statement, the return statement has no business with this value, it will however continue to just return the elements that have passed the specified condition.

This is the particular behaviour for unique ES6 methods and this behaviour will not hold for traditional functions.

As per this code below.

When the code is run. The value of this.test is “World” Why?

Ignores all the statements(runs them of course), expressions after the return but then picks the last value stated and returns that value.

At the end of the function we return every “user” in the range that fulfils the condition however state doesn’t get returned. If you are not surprised it is probably because you understand that functions return explicitly a single variable.

NB: The ‘this’ context works by lexical scoping. The JS engine running the code will look into the scope containing the function and use the ‘this’ context of that scope in the function. An interesting thing to note is that the ‘this’ context of an arrow function cannot be overwritten. You can’t bind it to an object you want to bind the function to. Some developers see this as a bad thing. But that’s disturbing because JS is meant to be a dynamic and strict language at the same time to really realise the potential of the language. In environments like React, the use of the arrow function really helps to avoid awkward binds between components, binding this in the **render **_function a_nd other things the arrow functions does dynamically. All these add up to improve the performance of the app.