Several weeks ago, I wrote about how closures impact calling asynchronous functions in a loop and several ways of dealing with that problem.
In my recent coding, I’ve discovered an even more simple way of dealing with this problem. In the process, it removes the anonymous function and eliminates the linting error, ‘Don’t make functions within a loop’
bind(). And as it turns out, we can use bind in multiple situations, including dealing with the closure issue I mentioned a couple of weeks ago.
What Is bind()?
bind() that I care to support, so I’m good. Your mileage may vary.
What bind does is that it automatically wraps your function in its own closure so that we can bind the context (the this keyword) and a list of parameters to the original function.
What you end up with is another function pointer.
Notice that we not only bound this to the
foo() function, but we also bound the two parameters. So, when we call
newFoo() the return value will be 7.
But what happens if we change the parameters before calling newFoo?
Changing bind parameters
If we bind parameters to
foo() using variables and then change the variables prior to calling
newFoo(), what do you expect the value to be?
The return value is still going to be 7 because
bind() binds the value of the parameters, not the actual variables.
This is good news and, like I said, we can use this to great advantage in our code. But where I think it will display the most usefulness to me is in my call backs
Bind and callbacks
You should remember from that article that one of our solutions to dealing with callbacks in loops was to create an anonymous function around the function we wanted to call.
But we can greatly simplify this code by using bind instead.
We can do this because each call to bind gives us a new function pointer and the original function remains unchanged.
Meanwhile, we also remove the linting error ‘Don’t make functions within a loop’ because we aren’t creating the function in a loop, we are just pointing to a function that was created outside of the loop.
Bind for Event Handlers
Another place where
bind() will clean up your code is with event handlers. Everyone knows, or should know, that when an event handler is called, the context it is called on is the thing that generated the event and not the object that the event handler was created in. But, by using bind, you can be sure that the function is being called on the correct context.
Not that you would write your code exactly like that, but that is just to get the point across.
OK. I’ll be the first to admit that my functional programming knowledge is limited. But the best definition of Currying I can give you is that it allows you to pass parameters to function in multiple steps.
Using binding, we achieve Currying by writing code that looks something like this:
- WebForms vs MVC–The War Is Over - September 25th, 2014
- Create A Desktop Application using Angular, Bootstrap and C# - October 15th, 2015
- Are You Doing Angular Right? - November 5th, 2015
- Adventures Working With Angular’s $scope - November 26th, 2015
- Using Gulp to Bundle, Minify, and Cache-bust - January 28th, 2016
- Reactions to React JS and Associated Bits - March 17th, 2016
- An Explanation of the Flux Pattern - March 31st, 2016
- Ext JS 6 by Sencha - The Good, The Bad, The Ugly - April 7th, 2016
- Do This To Increase Your Client Side Web Development Speed - April 21st, 2016
- ES2015 Code Coverage and Jest (React JS Unit Testing) - May 5th, 2016
- 4 Reasons To Drop MVVM - July 27th, 2016
- You Can Start Using Node Today - August 2nd, 2016
- TypeScript and Electron The Right Way - September 6th, 2016