This article requires some understanding of ServiceWorkers. If you’re not familiar with ServiceWorkers, here are some links to help you get started —

Service Workers: an Introduction | Web Fundamentals | Google Developers

Also, here is a good read —

The offline cookbook

Let’s discuss some of the gotchas when developing a web application with offline capabilities using service workers.

For the sake of brevity, sw = service workers.

3xx — Almost Never

Whenever a URL in your application possibly returns a 3xx response, make sure you know what you’re doing when you handle that request via a Service Worker. The 3xx are a useful way to add some side effects to modify your persistent state (on the server, session entry or some token entry to db which you’re planning to use later, and on the client, cookies) and let the user move on.

An example is when you have a separate login page for your application.

1. When the user visits /login, s/he expects to see the login page
2. When the user visits /login when s/he is already logged in, s/he should automatically navigate to the Homepage or Dashboard or similar.

Do you see the problem already? If so, High Five!!!

The 3xx itself is not the problem. The side effect it causes is the problem we should be aware of and handle.

What happens when you cache the login page in sw?

• User enters /login for the first time. Login page is cached by sw
• User completes login, and s/he is in some other page of the app (let’s not talk about the other 3xxs that you usually do here)
• Some random link takes user to /login when offline or flaky connection
• CacheFirst (ReadThrough), NetworkFirst or any approach that involves response from Cache will result in her/him seeing the Login page when s/he is already logged in.

This is one of the corner cases. But it’s an important gotcha that you’ve to plan and handle right from the beginning so that your sw code doesn’t get too complicated or convoluted. One simple solution to the problem is to NOT cache the page that can possibly throw a 3xx. But, it’s not that straightforward to identify. Inside a sw, the only way to make a request is to use the fetch API. Chrome was the first browser to implement service workers and fetch API. Between Chrome 42 and Chrome 46, the sw spec and the fetch standard kept changing — new features were added and the defaults were changing. So if your users are using this range, take a note of this inconsistency —

Simply don’t cache

For the pages that can possibly throw a 3xx (i.e. it returns a 3xx for some requests and 2xx for some other requests), simply don’t cache stuff.

Though it is possible to respond with fetch(request), like —

self.onfetch = function(event) {
  if (event.request.url === '/login')
    event.respondWith(fetch(event.request));
};

or with sw-toolbox,

toolbox.get(‘/3xx’, toolbox.networkOnly);

it has had its issues in the first half of 2015. Fetching a 3xx in service worker resulted in this —

1. Browser URL = /301. Service worker handles /301.
2. SW: fetch(‘/301'). fetch does the redirect to /200. The .then gets content for 200.
3. event.RespondWith(contentFor200)

So, what’s the problem here?

The browser URL still remains as /301.

Oops! This is not the expected behaviour. The browser URL should have changed to /200. This happens in Chrome 42, 43 and one or two more versions. So, if your users use this range, take a note of this before you implement service workers for 3xxs.

Can we fix it with some code and dirty checking?

Apparently, it’s not so simple. In these versions, the fetch standard says that if the redirect mode is set to “manual”, the behaviour was to change to “follow” by default. And it was removed only in July 2015 by this commit. So, this gives us no way to find if a request threw a 3xx by tapping into the request-response lifecycle before the redirection is made. But now, with the latest spec, it is possible to use redirect=manual and know whether it returned a 3xx response (will discuss in later parts of this article).

Coming back to the same problem, there are some clues to know whether it was a redirect or not.

1. request.url !== response.url

If the request.url and the response.url does not match, then there is a redirection. But then you’ve to pass this information back to the Document from the serviceWorker and make the browser make a request to the resultant url. This will result in requesting the same resource twice. You can be intelligent about it, but it just ends up in code smell.

2. Replace all 3xx with 200

One other option is to remove the 3xxs from the server completely by replacing it with 200s with custom headers. Here you’ll be parsing custom headers in your sw code.

function redirect(res, url) {
  res.header('X-Redirect-To', url);
  res.end();
}
app.get('/301', function(req, res) {
  redirect(res, '/200');
});

3. 3xx via 200 and a script tag

Same as the previous approach, but adding a script tag to do the redirection. Send a 200 response with the response body that will rewrite the url.

function redirect(res, url) {
  res.header('X-Redirect-To', url);
  res.end(`<script>location.href=${JSON.stringify(url)}</script>`)
}
app.get('/301', function(req, res) {
  redirect(res, '/200');
});

There is no straightforward way to get this to work on the browsers that was released with sw support in the first 3 quarters of 2015. So in my opinion, these approaches bring you to a point that gets stuff done using a hack. While this is not the best thing to do, it’s an option you can consider. If you find some other way to make it work, kindly leave a comment. Thanks!

Note: For latest versions of all browsers that follow the latest spec or spec after mid 2015, you don’t have to worry about the above 3 things. It just works.

The second part of the problem with fetch and sw is detecting a redirect. Let’s say /301 returns a, well, 301 to /200

fetch('/301')
  .then(response => {
    assert(response.status === 200);
  });

Note that the response status is not 301. And it is the expected behaviour.

RequestRedirect

To change the above functionality and get more control, we have the RequestRedirect. redirect is a RequestInit option using which you can specify the redirect mode to “follow”(default), “error”, or “manual”. The manual redirect mode allows you to detect the 3xxs.

fetch(‘/301’, {
  redirect: ‘manual’
}).then(resp => {
  assert(resp.type === 'opaqueredirect');
});

One important thing to note here is that — while tapping into the 3xxs gives you more control, it opens up a potential security problem. So you cannot simply get all the data you want from the 3xx. You only get one clue —type= ‘opaqueredirect’ and all other values are nullified — status=0, headers=null, body=null, etc… A brief of the security issue is in the spec —

Fetch

So with this type=‘opaqueredirect’, you can now know whether a request returned a redirect and you can decide whether to cache or not based on some logic. But there is one gotcha — this is not available in that version range discussed above. You’re better off with a hack than relying on making response redirect work. I’m discussing about this here to let you know that there is a neat way to tap into redirects. You can make use of it in case you’ve no other option.

Caching a 3xx response doesn’t make sense

Seriously! Think of it as highly opinionated, but trust me, when you make a web app, you’ve to know which URLs can return a 3xx and make sure you don’t ever cache the 3xx response. It simply doesn’t make sense to cache an opaqueredirect response. Also, an opaqueredirect response is treated like an error in fetch.

More Discussions

Hopefully, this gives you a basic idea. Here are a few more discussions on the same topic, and you’ll probably find a lot more information here —

• Allow "manual" redirect fetches with caveats · Issue #66 · whatwg/fetch
• Add a bit to Opaque Responses to distinguish redirects · Issue #79 · whatwg/fetch

Include credentials

When you make a request for which the server expects some cookies, by default, cookies are NOT sent. And when you make a request for which the server sends some cookies, by default, the response’s Set-Cookie header doesn’t reach the Browser’s Document. This can be fixed by adding the include credentials option in RequestInit.

For example,

fetch('/200')

the server does NOT see the cookies. And when the server sends a Set-Cookie Header, the fetch here in the SW kinda swallows these cookies

self.onfetch = function(event) {
  event.respondWith(fetch(event.request));
};

and they don’t reach the Document context.

For things that require cookies in their transactions, you need to explicitly tell in the Request to include the credentials.

fetch(url, { credentials: 'include' });

Response Race

While CacheFirst and NetworkFirst strategies operate based on one fails and the other kicks in, there is one more important strategy for certain things. In sw-toolbox it’s called — ‘fastest’ where cache and network are requested simultaneously using Promise.race.

When the request goes out for the first time — race(cache, network),

and for all other requests,

The documentation says it all —

Request the resource from both the cache and the network in parallel. Respond with whichever returns first. Usually this will be the cached version, if there is one. On the one hand this strategy will always make a network request, even if the resource is cached. On the other hand, if/when the network request completes the cache is updated, so that future cache reads will be more up-to-date.

Just A Silly Mistake

Here are some common silly mistakes that you can catch early and possibly avoid all the pain.

url

When you bring in one more layer in your request response cycle, you might miss out on some of the parameters. A reminder to you that url is not the only key in a request. It’s not uncommon to make this silly mistake —

var url = event.request.url;
if (url.indexOf('something'))
  return event.respondWith(fetch(url));

Note the `fetch(url)`. It should simply be `fetch(event.request)`.

Streams!!!

The request and response are streams. So whenever you’re consuming the body of a stream, you have to make sure that you clone it before consuming it. This is because the body of the stream can be consumed only once. Cloning the Request and Response streams are as simple as —

var reqClone = event.request.clone();
var respClone = response.clone();

SW Kill Switch

When you get your ServiceWorker wrong, it’s hard to make it right. What does it even mean? Say you’ve made a mistake that all your pages are broken when it passes through sw fetch and a stale cache always kicks in. This is bad and one way to fix it on your system is to kill the serviceworker from devtools. But when you ship it to users, you can’t ask all of your users to kill the serviceworker or force refresh your page a few times whenever you correct some mistake.

A Service Worker updates itself by checking the byte diff with the new service worker when available. It tries this update process upon navigation respecting the freshness headers and the sw explainer gives a detailed description of the same. For simplicity, let’s say the automatic update happens once in ~24 hours. And to update a service worker all you need to do is to change the contents of the file so that there is a diff. A simple —

const VERSION = 42;

will be enough. Incrementing this number will update the service worker in next load. This is mainly useful for cache invalidation —

const CACHE_NAME = 'my-awesome-site-cache-' + VERSION;

When you use this ‘VERSION’ as a part of the Cache name, it invalidates the previous cache completely and new caches are populated. This undocumented feature is called the Service Worker Kill Switch.

Added to the VERSION parameter, you can also call the update method in ServiceWorkerRegistration object —

navigator
  .serviceWorker
  .register('/sw.js')
  .then(registration => {
    button.onClick = () => registration.update();
    window.onSomethingHappened = () => registration.update();
  })

registration.update() will try for a new update of service worker bypassing the ~24 hour update check. Note that the byte diff requirement still applies.

Kill Switch 1

If you see some users getting cross site scripting attacks and you want to clear all the site’s information on the user’s device, this Spec comes in handy and it’s called the Kill Switch —

Clear Site Data

Sending the header ‘Clear-Site-Data’ is a useful way to mitigate these attacks. Also, from an example in the spec —

Installing a Service Worker guarantees that a request will go out to a server every ~24 hours. That update ping would be a wonderful time to send a header like this one in case of catastrophe.

Don’t generate dynamic sw code

If you’re going to generate dynamic sw code, say https://example.com/sw.js?foo=bar, don’t do it, because it brings in potential XSS attacks, say ‘bar’ is used in the script.

That’s all Folks!

There are a few other gotchas that I probably missed. Will write a Part-2 for the same. The epilogue is that there are some hidden things that are not obvious for the first timers, and it might require reading some parts of the Specification a few times. It helps both ways, you can improve your code as well as help improve the specification. Here is the spec —

Building Flipkart Lite: A Progressive Web App

Also, this article is cross posted here at the Official Flipkart Tech Blog — http://tech-blog.flipkart.net/2016/03/flipkartlite-the-how/

Well, where do I even start? The following is the list of most of the tech behind Flipkart Lite in NO particular order. Many thanks to all the authors and contributors of these tools, libraries, frameworks, specification etc…

Front-end:

• React
• react-router
• phrontend (+ flux)
• sw-toolbox

Tools — Build and Serve:

• NodeJS + ExpressJS
• Babel
• Webpack
• css-loader (for css-modules) —
• Postcss (+ autoprefixer, cssnext)

Web platform:

• Service Workers
• fetch API
• Push API
• GPU Accelerated Compositing
• Installable web apps - Add to HomeScreen
• Splash Screen

And a few more that I’m probably missing.

Some of the things listed above come with the tag “Experimental Technology”. But, trust me, take a leap of faith, play around, implement it in your app and push it to production. You’ll definitely feel proud.

The Monolith

The architecture decision started with choosing between “One big monolith” and “Split the app into Multiple Projects”. In our previous projects we had one big monolith repository and the experience getting one’s code to master wasn’t pleasant for many of the developers. The problem having all developers contributing to one single repository is — facilitating them to push their code to production quickly. New features flow in every day and the deployments kept slowing down. Every team wants to get its feature into master and effectively into production ASAP. The quintessential requirement of every single person pushing his/her code to his/her branch is that it should get reviewed and merged in the next hour, pushed to a pre-production like environment in the next 5 minutes and ultimately production on the same day. But how can you build such a complicated app from scratch right from the day 1.

We started with a simple system and added complexity

Separate concerns

The goal was to have the following DX(Developer Experience) properties,

• To develop a feature for a part of the application, the developer needs to checkout only the code for that particular application
• One can develop and test one’s changes locally without any dependencies on other apps
• Once the changes are merged to master, these changes should be deployed to production without depending/waiting on other applications

So we planned to separate our app into different projects with each app representing a product flow — ex: Home-Browse-Product or the pre-checkout app, Checkout app, Accounts app, etc… but also not sacrificing on some of the common things that they can share with each other. This felt like restricting usage in technology. But everyone agreed to use React, Phrontend and webpack :). So it became easy to add simple scripts into each of the project and automate the build and deploy cycles.

Out of these different apps, one of them is the primary one — the Home-Browse-Product app. Since the user enters Flipkart Lite through one of the pages in this app, let’s call it the “main” app. I’ll be talking only about the main app in this article as the other apps use a subset of tooling and configuration the same as in the “main” app.

Home-Browse-Product

The “main” app takes care of 5 different entities. Since we use webpack, each of the entities just became a webpack configuration.

• vendors.config.js : react, react-router, phrontend, etc…
• client.config.js : client.js → routes.js → root component
• server.config.js : server.js → routes.js → root component
• hbs.config.js : hbs-loader → hbs bundle → <shell>.hbs
• sw.config.js : sw.js + build props from client and vendor

vendors.config.js

This creates a bundle of React, react-router, phrontend and a few other utilities.

{
  entry: {
    react: "react",
    "react-dom": "react-dom",
    "react-router": "react-router",
    phrontend: "phrontend",
    ...
  },
  output: {
    library: "[name]",
    libraryTarget: "this",
    ...
  },
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({ name: "react" }),
    new CombineChunksPlugin({ prelude: "react" })
  ]
}

This is roughly the configuration for the vendors js. We tried different approaches and this worked for us. So the concept is to

• specify different entry points
• use CommonsChunkPlugin to move the runtime to this chunk
• use CombineChunksPlugin (I’ve uploaded the source here) to combine all the chunks to one single file with the runtime chunk at the top

As a result, we get one single file — vendors.<hash>.js, which we then sync to our CDN servers.

The vendors list is passed down the build pipeline to other apps as well and each of them (including main) externalise the vendors so as to be used from vendors.bundle.js,

{
  externals: vendors
}

client.config.js

As the name says, it is the configuration to build the app. Here we do minification and extraction of css into a single file.

server.config.js

Why do we even need a server.config.js ? Why do we need to bundle something for server?

We use webpack heavily and we rely on some conventions — we add custom paths to module resolution, import css files, use ES6 code, and node cannot understand most of this natively. Also, we don’t want to bundle every single dependency into one single file and run it with node. Webpack provides a way to externalise those dependencies leaving the requires for those externals untouched and this is one way of doing it,

var nodeModules = {};
fs.readdirSync(‘node_modules’).filter(function(m) {
  return [‘.bin’].indexOf(m) === -1;
}).forEach(function(m) {
  nodeModules[m] = ‘commonjs2 ‘ + m;
});

and in the webpack configuration,

{
  output: {
    libraryTarget: "commonjs2",
    ...
  },
  externals: nodeModules,
  target: "node"
}  

sw.config.js

The sw.config.js bundles sw-toolbox, our service-worker code and the Build versions from vendors.config.js and client.config.js. When a new app version is released, since we use [hash]es in the file names, the URL to the resource changes and it reflects as a new sw.bundle.js. Since we now have a byte diff in the sw.bundle.js, the new service worker would kick in on the client and update the app and this will work from the next Refresh.

hbs.config.js

We use two levels of templating before sending some markup to the user. The first one is rendered during the build time hbs → hbs. The second one is rendered during runtime hbs → html. Before proceeding further into this, I’d like to talk about HTML Page Shells and how we built them with react and react-router.

HTML Page Shells

Detailed notes on what HTML Page shells or Application Shells are are given here — https://developers.google.com/web/updates/2015/11/app-shell . This is how one of our page shells look like —

The left image shows the “pre-data” state — the shell, and the right one is the “post-data” state — the shell + content. One of the main things this helps us in achieving is this —

Perceived > Actual

It’s been a thing for quite some time that what the user perceives is the most important in UX. For example, splashscreen — it informs that something is loading and gives the user some kind of progress. Displaying a blank screen is no use to the user at all.

So I want to generate some app shells. I have a react application and I’m using react-router. How do I get the shells ?

Gotchas ? maybe.

We did try some stuff and I’m going to share what worked for us.

componentDidMount

This is a lifecycle hook provided by React that runs ONLY on the Client. So on the server, the render method for the component is called but componentDidMount is NOT invoked. So, we place all our API calling Flux actions inside this and construct our render methods for all our top level components carefully such that once it renders, it gives out the Shell instead of throwing an empty container.

Parameterised Routes

We decided that we would create shells for every path and not a simple generic one that you can use for anything. We found all the paths that the application used and would use. We wrote a small script that iterated through all the routes we defined to react-router and we had this —

/:slug/p/:itemid
/(.*)/pr
/search
/accounts/(.*)

During build time, how can you navigate to a route (so as to generate HTML Page Shells for that route), with an expression in the route that is resolved only during run time ?

Hackity Hack Hack Hack

React-router provides a utility function that allows you to inject values to the params in the URI. So it was easy for us to simply hack it and just inject all the possible params in the URIs.

function convertParams(p) {
  return PathUtils.injectParams(p, {
    splat: 'splat',
    slug: 'slug',
    itemId: 'itemId'
  });
}

Note: We used react-router 0.13. The APIs might have changed in later versions. But something similar would be used by react-router.

And now we get this route table.

Route Defined     → Route To Render    → HTML Page Shell
/:slug/p/:itemid  → /slug/p/itemId     → product
/(.*)/pr          → /splat/pr          → browse
/search           → /search            → search
/accounts/(.*)    → /accounts/splat    → accounts

It simply works because the shell we are generating does NOT contain any content. It is the same for all similar pages (say product page).

Two-level templating

We are back to hbs.config.js. So we have one single hbs file — index.js with the following content.

// this is where the build time renderedApp shell goes in
// React.renderToString output
<div id="root">{{content}}</div>

// and some stuff for second level
// notice the escape
<script nonce="\{{nonce}}">
<script src="\{{vendorjs}}"></script>
<script src="\{{appjs}}"></script>

Build time rendering: For each type of route, we generate a shell with $content injected into index.hbs and get the hbs for that particular route, example — product.hbs

Runtime rendering: We insert all the nonce, bundle versions and other small variables into the corresponding app shell hbs and render it to the client.

The good thing is that the user gets a rendered html content before static resources load, parse and execute. And this will be faster than server-side rendering, as this is as good as serving a static HTML file. The only variables in the template are a few numbers that are fetched by in-memory access. This improves the response-time and the time to first paint.

The end

And with all this and a lot of gotchas that I missed out, we put Flipkart Lite into production successfully. Oh wait! This didn’t start as a story. Anyway. Thanks for reading till here.

…

All the solutions described above are NOT necessarily the best solutions out there. It was one of our first attempts at solving them. It did work for us and I’m happy to share it with you. If you find improvements, please do share it :).

This is heavily inspired from CircleCI’s blog post ‘It’s the Future’ and expresses the same in another perspective.

It's The Future | The Circle Blog

Hey, I'd like to learn to write rich web applications. I hear you've got a bit of experience in that area.

: Yeah. I'm a front-end guy, using a couple of tools and techniques to build web applications.

Cool. I'm building a simple web app at the moment — a normal TODO app using HTML, CSS and JavaScript, and I’m planning to use JQuery. Is that the way to go ?

: Oh, no. That’s old school. JQuery is dead — no one uses it anymore. You need to use React now. That’s the future.

Oh. Okay. What’s that ?

: React is the new way of building web apps. It uses a Virtual DOM implementation underneath and lets you write JSX code.

Virtual… what ? JSX ? What’s that ?

: JSX — It’s HTML on steroids. It’s an extended version of JavaScript where you mix XML and JS in the same code. VirtualDOM — You’d have a tree of custom objects representing part of the DOM, and it gives the ability to manipulate these objects very quickly without touching the actual DOM.

What is mixing XML and JS ?

: Ok. Look. React is the future. It lets you create components as reusable entities.

Oh. So you mean like Backbone views ?

: No. Backbone is dead. Everything is going to be components now.

So. I don’t need to know about JSX or VirtualDOM ?

: No. You still need to know the underlying concepts, so you can write code without worrying about operations being costly and optimize places where it ll actually be — like the component’s state.

Okay. I’m getting lost here. There is this thing to build components, called React. Can I use it with JQuery ?

: Well. React does allow you to build only part of the application and the rest with your choice. But I told you, JQuery is dead. You'd want to use webpack to bundle your components together.

OK. What’s that?

: It’s a module bundler. You write a bunch of files as you'd write node modules, and you just combine them to form a single file / chunks of files to serve to the client. Also, you don't even need react-tools, you just need babel to compile JSX.

Babel ?

: Yeah. Babel. It’s this cool tool that can transpile your ES6+, JSX code to readable ES5 code with the support for sourceMaps, and it’s widely adopted even Facebook uses it.

ES6+ ?

: ES6/ES2015 is the next version of EcmaScript where you have so many new features like classes, arrow functions, maps, sets, etc… Almost everyone uses ES6+ code to write their applications.

Is that good ?

: Of course it’s good. ES6+ + transpiling is the future.

Okay. How do I use it ?

: You start by installing Node…

Install Node? No no no… You were saying something about React and components.

: Yeah. So you have the flux application architecture pattern and you create your actions, stores and components…

Flux ?

: With flux, you build your app as stores, actions and views where data flow is in one direction. Views trigger actions, that runs through a dispatcher and stores listen to dispatcher and emit change events which the view again listens to.

Ah. Like MVC ?

: No. MVC is dead. Flux is the future. There are many many flux implementations out there.

What? Flux implementation ?

: Yeah. Flux is a pattern. Just look it up, #alt, #flummox, #marty, #fluxxor, #fluxible, etc… and there is a Dispatcher that is implemented by Facebook.

Why don't I just use the Facebook’s thing ?

: It gets complex to write all the boilerplate code efficiently as a beginner, so you start with one of the existing implementations.

OK. Yeah. I really don't want to do hard boilerplate code.

: Well. Yeah. As I said, there are some existing implementations.

What about angular?

: Ew

Ew?

: Ew

Look. I really don't want to go through the headache of bootstrapping complex code.

: No. It’s really easy. There are some starter kits/repos, or there are some yeoman generators to do that for you.

I need a generator ? Yeoman ? What’s that ?

: It can generate code for you, and you can use it to create multiple apps. Use webpack’s new DLL support to build every single app separately as well as together.

I’ll have only one app, page or component, whatever. Just one of them

: No. Look into composable components. It’s how we do everything now. You need to break down into components — one for every small entity.

That seems excessive

: It’s the only way to make sure it’s clean, developer friendly as well as performant. So you can do things like hot-reload…

Hot Reload ? Like livereload ?

: No. Webpack supports this amazing feature called hot module replacement, and there is a react-hot-loader for react where you can tweak a single component in isolation without reloading the entire page. And with your flux actions, you can do crazy things like replay your actions with live editing your code seamlessly.

Okay. So I've got dozens of tools and libraries for building, bundling, transpiling, whatever. Now what?

: I was saying. Flux — It lets you architect your applications well. With Observables and Immutable data, it gets nicer and interesting.

Observable ? I need immutable data ?

: You need observables to neatly handle events and a few other asynchronous calls and Immutable data for persistence, efficiency and simplicity. Observables are an asynchronous plural primitive analogous to arrays in the synchronous world. Observables are expected to be the return values of an ES2016 async-generator function.

What’s async generator ?

: See. A generator function modifies a function and causes it to return multiple values, an async modifier causes a function to push their values in future. So an async generator function is a combination of both — yield multiple values in future. But the author, Jafar Husain, has withdrawn this proposal and is working with Kevin Smith towards a smaller-scoped es-observable proposal for ES7/ES2016.

Sigh. I just want to launch a simple app. How much deeper does it get ?

: Well. You can use RxJS which is close to the observable spec. It’s widely used and production ready.

RxJS ? Why is this useful ?

: It plays nice with your existing promises, events ecosystem. You can create an Observable from any asynchronous code, and treat it like a first class citizen, pass around, handle async values, handle errors etc… Well, if you're looking for something truly Reactive and interesting, check out cycle framework by Andre Staltz.

WTF. I just want to build a simple app and demo it. Will I be able to do it ?

: Sure. I mean deploying it might be another interesting topic altogether, but you're basically there.

I see. Okay. I think I understood something. Thanks for explaining.

: Great! No problem

Let me just repeat some of what I've got it right.

: Sure!

So I need to split my application code into actions, stores and components following one directional data flow, write ES6+ code which would allow me to use the latest features and let me write clean code, use babel to transpile this ES6+ code into ES5 code which all browsers can parse, use webpack to join all the files written as node modules, use ImmutableJS to represent all my data and RxJS for all my events and other asynchronous functions.

: Yes. Isn’t it glorious ?

I think I forgot about static content, and minification.

: Not a problem at all. Webpack allows you to import them. All you have to do is configure some loaders, plugins and you're basically done. You can import component level stylesheets and images and use them with this setup. There are other alternatives to stylesheets where you can write CSS in JS.

I’m going back to JQuery.

a('a', function() {
  b('b', function() {
    c('c', function() {
      d('d', function() {
        console.log('WTF!!!');
      });
    });
  });
});

and it was never nice to add one more function to represent your idea into code via callbacks. Promises are a big step towards solving this issue. The following tutorial on Promises by Jake Archibald(@jaffathecake) is one of the best out there. I’d recommend reading it if you’re new to Promises.

Learn

The analogy

In the synchronous world, the primitives are values.

var foo= 5;
var bar = {};
var baz = 'dice';

So, in the asynchronous world, we need something that can be used as a neat representation of async values. When an asynchronous function is invoked, instead of returning the value immediately, it returns a placeholder for the value — a Promise and this placeholder provides a way to ask for the actual value.

var promise = asyncfn();

That’s it and we can pass this value around. A better overview of this entire space can be found in the General Theory of Reactivity (gtor) by Kris Kowal.

kriskowal/gtor

A Stateful Machine

Promises are stateful objects themselves and can exist in one of these three states: unfulfilled, resolved, rejected. It’s state properties —

• When a promise is created, it is always in the unfulfilled state
• Once a promise changes its state from unfulfilled to either resolved or rejected, it cannot change again
• If you’re adding to the tip of a Promise chain, you’re creating a new Promise and the state properties apply

First class citizen

A promise can be treated as a first-class citizen resolving to a JavaScript value in future. Once a promise has been created, the value it resolves to has the same properties as a normal JavaScript value. To understand this better, let’s take an example,

var x = 1;
var y = x + 5;

and,

var x = delay1s(1);
var y = x.then(function(val) { return val + 5; });

As you can see the analogy, in both the programs, x can be used even after y has consumed x. And the original value of x, sync or async, doesn’t change.

Single output pattern

This is a very common pattern (in structured programming) where you start with an async value (a Promise) and at every stage you’re storing only the tip of the chain. So all branches created eventually merge using all / race. Storing mid-references are not allowed or the notion of stored mid references becomes irrelevant. During branching you only store until all branches are merged back. The ES7 async/await enforces this single output pattern through its syntax.

Concurrent usage pattern

This is also a legitimate use case for Promise. With this, you can create custom concurrent executional paths and may expose any intermediate promise. Usually, this is hidden using some higher level abstractions and what gets exposed is determined by the abstraction rules. It uses branching and merging underneath.

The Mutate anti-pattern

Take this example — A promise that resolves to an Object after 100ms.

var promise = delay(100).then(_ => ({ a: 5 }))

Objects are mutable in JavaScript and are passed by references. When you branch this promise out,

var x = promise.then( v => { v.a = 6; return v })
var y = promise.then( v => { console.log(v); return v })

The anti-pattern: the tip x has a consumer that modifies v
Side-effect: the tip y gets a value where v.a is 6, where you’d expect v.a to be 5.

I’d recommend further reading about Promise anti-patterns in bluebird’s documentation.

petkaantonov/bluebird

Epilogue

Promises are the asynchronous primitives in JavaScript analogous to values which are synchronous primitives. There is a lot more to talk about promise based async programming patterns — I’d hopefully try that in my future posts after a few clarifications and learnings.

“Dae, vetti(jobless) fellow. It’s time to wake up. We reached”, said Chakra, my roommate. It was a 6 hour journey from Bangalore to Kukke. I was struggling to open my eyes to get a clear vision of the world outside. There weren’t anyone around, “Time’s up! Freshen up guys”, said Prassanna, our Trek coordinator. With a 15% awaken mood, I walked into the room at Kukke and lied down to take a nap for a few more minutes (…) and we reached the starting point of the trek. The coordinator was giving some insights of how it is going to be while I was observing the surroundings. There were fences all around, most of ‘em broken, and there was one tiny path which led to a picturesque view of sparsely dense forest. We started walking towards it and our journey began here.

It was around 7.30 in the morning, the climate was awesome — humid cold air, wet path and rising Sun which intermittently showed its face, and an exuberant team, where each one of us had a profound trekking experience. After 30 minutes, Chakra and I started racing towards the mid-point of the 14 KM trail to Kumara Parvatha — the summit. We didn’t want to stop anywhere inbetween because both of us believed that the challenge here was to do it as fast as possible and prove it to none but ourselves. We did observe all the intrinsic details of the charming scenery along the path. As people believe, “Words aren’t enough to explain the nuances of the experience.”

Immediately, after we crossed the forest, the trek became steeper and steeper. When we could no longer walk, we started increasing our speed. This scene from the movie, Ironman, striked my mind.

Sometimes you gotta run before you know you can walk.

It was 10:15, and after these strenuous steep slopes, we reached an area where it was relatively flat. We had little instinct that we had reached the place called “Bhat’re manae” (Not sure if it’s spelt that way). It was a house owned by the Bhat brothers. They offer place to stay and food for the trekkers.

“How many of you are there?”, asked the elder Bhat brother. “Seven”, I replied. “Come in. Leave your footwear outside”, said the elder Bhat brother, watching a Kannada channel on his TV. We went in, removed backpacks, lied down, and waited for the others. Two more guys made it in a short span of time, and we were not ready to continue the breaktime. We started exploring the place. There was a tiny stream, which we drank the water from, and to us it had the perfect combination in perfect amounts of the essential minerals and it tasted so good. We filled our bottles and we were waiting for the Bhat brothers to finish cooking. A couple of other trekkers also arrived and they started introducing themselves.

As soon as the food arrived, like a quintessential meme would portray, we rushed towards forming the queue and started eating. Food never tasted so good amidst the fact that nothing fancy was served (plain rice with dal and pickle). The plan was to reach the peak and get back to Bhat’re manae on the same day before 06:00p.m. We started climbing uphill from Bhat’re manae at 12:00p.m. The path contained no trees around and the Sun showered its rays of intense heat upon us. We wet our heads with water and moved further uphill.

We crossed 3 hills and reached Shesha parvatha. From there, the trail went into a forest. We climbed downhill in the forest and then uphill along the side of a dry waterfall and some rocky paths. Our legs started sending signals that it can’t move further. Our consiousness acted thereupon, and replied to them about the trek becoming steeper. Then, out of nowhere, Prassanna started moving fast. We were determined to reach the peak in another 20 minutes. And consequently, we started running.

We reached the peak at 03:00p.m. and we were so tired that we just found some shade under a plant and waited there for the others to make it to this point. After they arrived, we started capturing some pictures with weird poses. I realized that the peak wasn’t that great. There were campfire stone rings, a lot of ‘em, and a temple built by stacking small stones. Infact, the view wasn’t as great as the view from the other peaks (local maximas) we crossed. As Steve Jobs says, “It’s never about the destination. The journey is the reward.”, holds true, literally.

We started trekking downhill to Bhat’re manae. Sunset in Kumara Parvatha happens so fast that in a span of 2-3 minutes, it becomes dark. Just when the Sun was setting, we were climbing down hill and the view was unreal. 1.5ft tall thin sparsely branched plants and grasses covered the entire region. The rays of the dawning Sun striking this setup resulted in a view — an Orange glow over the Green land.

We reached Bhat’re manae at 06:00p.m. and stayed in the nearby forest department building for the night. (…) It wasn’t too cold here that we woke up early and decided to start trekking downhill, back to Kukke, as soon as possible, to avoid the bright guy rising over our heads. We had breakfast at Bhat’re manae, and started moving downhill at around 7:45a.m. We didn’t spend too much time observing the scenery as our motive was to find how fast we could get to the end of the trail. After everyone reached Kukke, we jumped into a small stream of water and relaxed while the gentle stream of water was massaging our tired body. We ended the trek with a pint of beer, fried fishes and chickens, and biryani.