Component Cutter

Using

ES2015, Gulp & Webpack

We have components everywhere. Our software is no exception. We have them in cutting edge stuffs like React, Bower, NPM, Web Components, Ember, and now in Angular 2. Components are like building blocks in Lego game which does one thing and does it very well. And they’re so generic/reusable that we can fit them together to build stuffs that we want.

Now think about them other way around. We can split our huge application into smaller, independent, reusable and testable components based on their functionality which can then be packaged together to build the entire application. These components can be business objects like product, user, shopping cart, etc. or even technical things like header, footer, menu, etc. These can then be reused in other applications of similar nature requiring similar business and technical components.

With ES2015 and component router in Angular 1.5 coming soon which is going to ease the transition to Angular 2, it’s worth exploring the newest way of writing Angular apps using this super awesome combo and component mindset. And then we can take it to next level by automating component making process and make it as simple as a cookie cutter.

Here are the 2 tools that we need:

1. Webpack:

• Transpiles ES2015 (ES6) to ES5 (JavaScript that current browsers know).
• Loads HTML files and dependent files as modules.
• Transpiles stylesheets and appends them to HTML.
• Bundles the entire app.
• Loads the modules on demand to keep initial load time low.

2. Gulp:

Gulp is used as orchestrator for

• Starting and calling Webpack.
• Starting a development server.
• Refreshing the browser and rebuilding on file changes.

File Organization of Angular App:

With components in mind, let’s have file organization as show below:

client
⋅⋅app/
⋅⋅⋅⋅app.js * app entry file
⋅⋅⋅⋅app.html * app template
⋅⋅⋅⋅common/ * functionality pertinent to several components
⋅⋅⋅⋅components/ * where components live
⋅⋅⋅⋅⋅⋅components.js * components entry file
⋅⋅⋅⋅⋅⋅home/ * home component
⋅⋅⋅⋅⋅⋅⋅⋅home.js * entry file (routes, configurations, declarations)
⋅⋅⋅⋅⋅⋅⋅⋅home.component.js * home "directive"
⋅⋅⋅⋅⋅⋅⋅⋅home.controller.js * home controller
⋅⋅⋅⋅⋅⋅⋅⋅home.styl * home styles
⋅⋅⋅⋅⋅⋅⋅⋅home.html * home template
⋅⋅⋅⋅⋅⋅⋅⋅home.spec.js * home specs

Let’s look at how home component can be implemented in these individual files using new features like import, export, class, object shortcut notation, arrow function from ES2015:

home.js:

This is the first file we should look at as it holds the definition of the component, what url it is reachable at and what’s its template which acts as skin cover for the component. The template (line 15) should use a custom directive, home in this case (line 19), which is imported as homeComponent from home.component.js file (line 3).

Note: Above is the only component file that has angular in it. The following files have plain JavaScript making Angular’s footprint smaller in our code base. Thanks to ES2015's import/export feature to make this possible.

home.component.js:

This is the center piece that imports and knits the component’s HTML, controller and stylesheet together. Since this custom directive is used in the template of home component, home.html gets rendered on the screen with home.styl applied to it.

home.controller.js:

Next comes the controller that makes all the JavaScript properties and methods defined on HomeController class accessible in the home.html template via controller’s alias name vm declared in above file.

home.styl:

Stylesheet written using Stylus gets converted to CSS using Webpack’s stylus loader.

home.html:

This holds the UI of the component, binding the data and methods defined in the controller class via vm object.

home.spec.js:

With spec file for individual components, we can write well focused and isolated test cases for all the features we add in our component. Also packing spec file in here ensures that it will always move along with the component if it is reused in other applications.

Webpack Config:

It’s worth mentioning about Webpack module loaders configuration that makes importing .html, .styl, .css, .js and even .png, .jpg, .jpeg possible at component level. Here is how loaders are configured:

webpack.config.js:

Automation of Component Creation:

Writing these individual files for creating components is tedious. How about automating it? Let’s take copy of all the home component files and name them as temp and parameterize name of the component in these files for automating component creation.

temp.js:

temp.component.js:

temp.controller.js:

temp.styl:

temp.html:

temp.spec.js:

Command To Cut A Component:

gulp component --name componentName

And you get a brand new component cut out with the given name. Isn’t this as simple as a cookie cutter? This is all it takes to setup this command as a gulp task in gulpfile.js:

We need to have all the temp files listed above inside a directory and point paths.blankTemplates variable to it to seed all these files in this task. It will take name parameter that we will enter in the command after — name and use it to replace name and upCaseName in all these files that we have parameterized between <%= and %>

That’s is it! If you want to try this out yourself, fork and play around with this tiny seed called NG6-starter.

Bake some cookies the way you like. Enjoy.

to

JumpStart

with

JavaScript

Do you feel like making a start with something new? Are you lost as there is so many things to learn? Your battery has drained out and not giving you a start anymore? You need a Jumpstart.

Inspiration

I was working on mainframe for 7 years. It was like fixing bulbs and doors in an old mansion to keep it going. There was no major engineering as the mansion was built already. I wanted to do more but couldn’t afford a mainframe of my own. It was time to start something new by stepping out of the safe mansion. I started with JavaScript and now I don’t have word ‘mainframe’ in my profile. I rewrote it. And so can you. And trust me, there is no looking back thereafter.

JavaScript has grown so much (web, desktop, mobile, TV, hardware, server) that it is now called Universal JavaScript. The language once known as toy language is now not just a language but also known as an Ecosystem.

Here is must watch video on JavaScript is Everywhere by Douglas Crockford, father of JSON (JavaScript Object Notation).

You can do so many things with one single language. You can even step out of your usual app dev mode to programming anything mode, if you like to. Samsung is banking on JavaScript as language for IoT (Internet of Things).

Path to JumpStart with JavaScript:

The first month or two can be very daunting. And if you have put all your money into it (like me dumping my 7 years of mainframe experience), you might ask yourself what am I doing with my career (like I did that time). Just hang onto it and you will pass this phase. Change is Good.

Here is my attempt to JumpStart you with JavaScript using my battery.

1. Learn JavaScript:

JavaScript is a tiny language. Learn it instead of just using it. Because of its syntax similar to other languages, developers just start using it without feeling the need to learn it. In last 4 years of my interviews with JavaScript developers, I have heard only a few saying that they are learning the language besides using it. Please don’t take it for granted. JumpStart learning JavaScript with this list by Eric Elliot.

2. Don’t Take Shortcuts:

Don’t jump onto frameworks/libraries to make your life easier. You will miss a lot of skills that the language is offering in its vanilla form. Frameworks and libraries hide away complex problems and their solutions in them and leave little for us to learn from the language. Frameworks/libraries come and go. What stays around is the language.

3. Grok Frameworks And Libraries Source Code:

Don’t ignore frameworks/libraries altogether. They solve complex problems in best possible ways. They are written by experts and so reading their source code is one of the best ways to learn the language.

4. Contribute To Frameworks/Libraries:

While you are at it, grokking the language more and more, you should start contributing to the frameworks and libraries. Some day you might write frameworks or libraries of your own.

5. Learn ES.Next:

ECMAScript 2015 (also called ES2015 or ES6) is the next and the most awaited version of JavaScript coming this year. With year in its name, we will get more such updates every year from now on. Guess what, ES2016/ES7 is already work in progress. Upcoming versions that are lining up are called ES.Next. These are coming one after the other with bigger and wider impacts. Most of the projects/frameworks/libraries will be written in ES.Next. So catch it before it catches you some day.

6. Pair With Other JavaScript Enthusiasts:

Though at #6, this has the most impact. This will keep you motivated all the time and will never let you drain away your battery. Strive to make a high velocity team explained here. Ultimately, it’s all about teamwork.

7. Run Pet Projects:

Convert your ideas into reality. Pet projects will help you learn what you want to learn very quickly. So don’t wait until your regular project is over. Make them open source on Github for others to contribute. It’s time for your repos to get forked and receive pull requests.

8. Follow Tech And People On Twitter:

Follow technology and the people who are shaping the technology on Twitter. Get into network of people who are into what you are. This will keep you up to date on what’s latest and what’s happening around the world in things that you are interested in so that you can become part of it. This will keep you inspired and on track all the time.

9. Write Blogs:

Four years back, I was asked to write blog on JavaScript and I believed there was nothing to write about it. After following the language for some time, I realized there is so much to write. Get into habit of jotting down what you learn everyday and then converting them into blogs for others to learn from.

10. Prepare Monthly Study Calendar:

Mark your calendar with what you want to study in each week for next 4 weeks and stick to it. Repeat this every month. You need to set some time out for doing this. Start with an hour a day on weekdays and few more hours on weekends and see how it goes.

11. Run Meetups:

Now you are reaching there with packets of knowledge to deliver. Meetup is a really good platform to share you knowledge and learn from others. Monthly meetups will help you set your monthly study calendar well and stick to it. Here is a meetup that I started recently.

12. Speak At Conferences:

Once you are on track, this will happen naturally. Aim to speak at conferences. And then, you will find yourself starting from step 1 and repeating all these over and over again.

Don’t feel left behind. All you need is a JumpStart. Hang onto it and you will ride on it.

- Long Live Locals

Googling ‘closure’ gives you this TLDR version:

In programming languages, a closure (also lexical closure or function closure) is a function or reference to a function together with a referencing environment — a table storing a reference to each of the non-local variables (also called free variables or upvalues) of that function.

More often, it is also DFDC version (Didn’t Follow, Don’t Care) for folks new or not sure about Closures.

Closure Simplified:

Closure is formed when a function can remember and access its lexical scope even when it’s invoked outside of its lexical scope.

Didn’t follow? Don’t worry. Many developers (include me in this list) don’t get it first time. Check this example:

function outerFunction() {
    var outerVariable = ‘I am local to outerFunction’;
 
     function innerFunction() { //This is a closure. Simple.
         console.log(outerVariable); //It can access outer scope.
     }
 
     innerFunction();
}

outerFunction();

JavaScript function gives rise to new scope. Nested function, innerFunction in above example, can access variables defined in its outer scope, like hot air balloon can access outside air. This can be nested to multiple levels forming spheres of scopes. The innermost scope has access to all its outer scopes.

Note that innerFunction is called from within its lexical scope which is outerFunction in this case. We will soon see how to call it outside of its lexical scope by returning reference to innerFunction from outerFunction.

What is this lexical scope now?

It’s called lexical because of the way the scope of a variable is defined by its location within the source code. The variable’s scope is apparent lexically. Thus when we nest function within function (to form a parachute, or a transformer, or a dream within dream), each having scope of its own, the local variables are lexically scoped in these spheres of scopes.

Globals are Immortal.

Global variables live the entire life span of the application and are not garbage collected (GC’ed). But due to shared namespace in JavaScript (window object in browser environment), we know the quirks of using globals and often resort to locals.

Locals are better but they die.

What a world it would be with all locals when they die as soon as the function holding them completes? Hot air is gone when balloon deflates. Locals are GC’ed once the function holding them completes. Check below example:

function outerFunction() {
    var outerVariable = 'I am outside';
    
    function innerFunction() {     
       console.log(outerVariable);
    }
    
    innerFunction();
}

outerFunction();             //Logs 'I am local to outerFunction'
console.log(outerVariable); //Logs outerVariable is not defined

How Locals can Live Longer?

If we return reference of innerFunction from outerFunction, outerVariable won’t get GC’ed and can live longer.

function outerFunction() {
    var outerVariable = 'I am local to outerFunction';
    
    return function innerFunction() {     
       console.log(outerVariable);
    };
}

var innerFunctionReference = outerFunction();

//Calling innerFunction outside of its lexical scope:
innerFunctionReference(); //Logs 'I am local to outerFunction'

Inner function can hold onto variables defined in its outer scope as a reference to it is still alive. Mr. Garbage Collector lets them live longer.

Inner function can remember not just the variables defined in outer scope but also the arguments passed to its outer function. Run this and see it for yourself:

var messages = ['I', 'will', 'be', 'back'];

//Without closure:
for(var i = 0; i < messages.length; i++) {
    setTimeout(function () {
        console.log(messages[i]); //Logs ???
    }, 1000);
}

//With closure:
for(var i = 0; i < messages.length; i++) {
    (function (i) {                   //Closure holding onto i
        setTimeout(function () {
            console.log(messages[i]); //Logs the popular message
        }, 1000);
    })(i);
}

Without closure, it logs undefined 4 times as the anonymous function passed to setTimeout doesn’t remember what was ‘i’ at the time it was set to timeout. It runs when i has reached 4 which is undefined in messages array.

With closure it works as expected because now it can hold onto value of variable ‘i’ in each iteration. Value of ‘i’ is locked into inner function (inner balloon) in the closure of outer function (outer balloon) we wrapped it into.

Why do we need Closure?

Why use closure when we can live without it? But what a world it would be to remind (pass arguments to) a function when it can remember things around it? Think about it. It can open doors to do lot more than what we have been doing right now.

Benefits/Practical uses of Closure:

• Create self sustained and persistent modules with public/private properties and methods.
• Make semi-computations or currying to hold onto intermediate results to arrive at final/other results later. See My First Closure below.
• Remembering/caching what happened last time that can be used in AI, Machine Learning, Parsers, etc.
• Hold onto index while looping some asynchronous code.

My First Closure:

Say you want to create a heatmap wherein days are columns and rows are stocks and each cell holds the stock price with color to indicate price fluctuation between high and low of that stock in that period. And say you want to do this for last nDays (nDays is user input) for 30 stocks.

That will be nDays X 30 computations to decide the color of the cell. What about min and max computation in this period as that needs to be calculated based on prices in that period? Would you do this minMax calculation nDays X 30 times. Nah! I used closure to make cellColor remember what min and max is for the given stock:

Care for Closure. Get closer to Closure :-)

-1995-

• Let there be keyword ‘var’ to declare variables/references in JavaScript.
• Let ‘var’ be optional for JavaScript to be forgiving language for the beginners.
• Let variables declared outside of a function be global i.e. accessible from anywhere and those declared inside of a function be local i.e. accessible only inside of function holding them. This is called scope.
• Let variables be declared anywhere but get hoisted from top of enclosing scope.
• Moreover, let there be ‘no’ block scope. Only function can give rise to new scope which can even be nested to form closures.
• And one more thing, let there be lexical scoping to access variables of outer scopes from inner scopes for closures to work.

Back then, some of these design decisions were hasty while creating a brand new programming language that too in mere 10 days. Brendan Eich is a genius. But even genius can make mistakes when asked to rush.

Let’s see the problems related to ‘var’ one at a time in action:

//Problem #0: Let there be 'var':
//-------------------------------

var myVariable = 'I am global';
console.log(myVariable); //Logs 'I am global'

function myFunction() {
    var myVariable = 'I am local';
    console.log(myVariable); //Logs 'I am local'
}

myFunction();

console.log(myVariable); //Logs 'I am global'

This is self explanatory with no visible problem at all so far.

But, hidden problems related to ‘var’ creeped in right from the beginning.

You can run below snippets in browser’s console to check these problems:

//Problem #1: 'var' is optional:
//------------------------------

myVariable = 'I am global';
console.log(myVariable); //Logs 'I am global'

function myFunction() {
    myVariable = 'I am local';
    console.log(myVariable); //Logs 'I am local'
}

myFunction();

console.log(myVariable); //Logs 'I am local' instead.

Because ‘var’ is optional, myVariable inside myFunction appears to be declared/assigned as a local variable inside myFunction. But it is not the case. It is global and the change in its value is visible even outside of myFunction.

For folks coming from other languages, not using ‘var’ doesn’t lead to any error unless you use ‘use strict’ mode.

//Problem #2: Let variables be hoisted at top of enclosing scope:
//---------------------------------------------------------------

var myVariable = 'I am global';
console.log(myVariable); //Logs 'I am global'

function myFunction() {
    //TDZone starts
    console.log(myVariable); //Logs ???
    //TDZone ends
    var myVariable = 'I am local';
    console.log(myVariable); //Logs 'I am local'
}

myFunction();

console.log(myVariable); //Logs 'I am global'

What will first log statement inside myFunction give? If you think the global myVariable is lurking around for you to use before the local version is declared, you are wrong. It gives ‘undefined’ as the local myVariable gets hoisted at the top of defining scope which is myFunction in this case. And as the local myVariable is yet to be assigned with a value, any attempt to use it in that TDZone in between will give rise to undefined value. That’s why this zone is called Temporal Dead Zone.

//Problem #3: Let there be 'no' block scope:
//------------------------------------------

var i = 'I am global';
console.log(i); //Logs 'I am global'

for(var i = 0; i < 5; i++) {
    //do whatever you want...
}

console.log(i); //Logs 5 instead.

Yes, it logs 5 instead of ‘I am global’ because there is no block scope. Variable ‘i’ declared inside for loop is visible even outside of it. Same will be the case if we had declared it inside while, do while, for and else blocks. Let’s call this as Accidentally Unblocked Problem.

Now, let’s see the most hidden and notorious problem that provides one of the most powerful feature of creating closures in JavaScript when applied knowingly and correctly:

//Problem #4: Let closure access variables from outer scope:
//----------------------------------------------------------

var messages = ['I', 'will', 'be', 'back'];

for(var i = 0; i < messages.length; i++) {
    setTimeout(function () {
        console.log(messages[i]); //Logs ???
    }, 1000);
}

This won’t log back the popular message we know of. It will log ‘undefined’ 4 times. Yes, undefined again. Why? Think about it.

Variable ‘i’ keeps running from 0, 1, 2, 3 and 4 whereas the calls to anonymous function (marked bold) given to setTimeout function in each iteration are left aside at least for 1 second. (This anonymous function is a closure and has access to variable ‘i’ (declared outside of it) with help of lexical scoping). And by the time their turn come, variable ‘i’ has reached 4 which is ‘undefined’ in messages array. Let’s call this as Runaway Problem as ‘i’ is running away and not holding its binding to each iteration. Clear enough but hidden enough to understand it first time.

If you give one more look to these problems, all of them are hidden due to those design decisions related to ‘var’. We can’t change these rules now as they will break the web due to the existing JavaScript code written based on these rules. There is no turning back in time to rectify this.

So, ‘let’’s look forward.

Solution: Let there be ‘let’ in JavaScript.

-2015-

• Let there be ‘let’ in JavaScript to declare variables/references in a new way.
• Using ‘let’ variables before their declaration will lead to ReferenceError. This will kill the Temporal Dead Zone itself (described in problem #2 above).
• Let ‘let’ variables have block scope. The scope of variables declared using ‘let’ is its enclosing block and not the whole enclosing function. This avoids Accidentally Unblocked Problem (described in problem #3 above).
• Let ‘let’ variable declared inside loops have fresh binding in each iteration so that each iteration remembers its value. This will avoid the Runaway Problem (described in problem #4 above).

ES2015 is coming.

Let’s use let.

You can run below snippets in babel and see ‘let’ solving these problems:

//Problem #2 of Temporary Dead Zone solved with let:
//--------------------------------------------------

let myVariable = 'I am global';
console.log(myVariable); //Logs 'I am global'

function myFunction() {
    //TDZone starts
    console.log(myVariable); //Gives not defined/ReferenceError
    //TDZone ends
    let myVariable = 'I am local';
    console.log(myVariable); //Logs 'I am local'
}

myFunction();

console.log(myVariable); //Logs 'I am global'

//Problem #3 of no block scope solved with let:
//---------------------------------------------

let i = 'I am global';
console.log(i); //Logs 'I am global'

for(let i = 0; i < 5; i++) {
    //do whatever you want...
}

console.log(i); //Logs 'I am global'

//Problem #4 (Runaway Problem) solved using let:
//----------------------------------------------

let messages = ['I', 'will', 'be', 'back'];

for(let i = 0; i < messages.length; i++) {
    setTimeout(function () {
        console.log(messages[i]); //Logs the popular message
    }, 1000);
}

‘let’ was introduced in 2005 by Brendan Eich as panacea to these problems. Though it took ten years to reach ES2015 specs, it is finally coming.

ES2015 (also called ES6), specs for next version of JavaScript were released in June 2015, some time close to 20th birthday of JavaScript. It’s the best birthday gift JavaScript ever had. Be assured, more are coming soon that too every year from now on. That’s why they smartly put year in its new name.

-Conclusion-

Let ‘let’ be the new ‘var’ here on!

This doesn’t mean you can just find and replace all ‘var’ by ‘let’ as it may break something based on how the design flaws were accidentally put in use in the code. Best bet is to use ‘let’ whenever possible in the new ES2015 code you write.

So, Keep Calm

&

Let ‘let’ Help

You Stay Calm.