So if we organize a web project by features rather than technique categories (like components, actions, models) it will help us always manage the project under control when the project grows because we construct the system with bigger units.

This architecture is also the key concept of Rekit, a toolkit for building web applications with React, Redux and React router.)

Unlike backend system, frontend web application is the direct interface for user to understand the capabilities of an application. So it’s more suitable to be organized by features.

What is a feature?

At first let’s define what a feature means:

A feature is some capability of a system.

That is a feature always adds some functionality to a system. For example, For a content management system, a new supported content type is a feature, for an IDE the capability to run tests is a feature.

Organize application by features

For a complex web application, it’s usually hard to understand how different parts work together. Original developers need to draw architectures, write documents to describe the system so that other could understand. But maintaining them is very hard because when the project evolves docs don’t evolve themselves. People need to update them in time so that they won’t mislead while they don’t help. So how if the project itself is self-describle? A feature oriented architecture is helpful for this.

Because we’ve grouped components, actions, stores into features, we don’t need to think about how these small parts work together but we only consider how features work together to construct the whole application. Features are much bigger units than pure technical artifacts like components, actions or models. By analyzing dependencies between features the system could auto generate understandable and accurate diagrams for developers to learn or review the project.

The implementation using React, Redux, React router

The idea is developed by creating apps using React, Redux and React router. Here is the general architecture:

Real word example

Let’s compare below two diagrams, from Rekit portal, one contains relationship between small artifacts and the other only contains relationship between features. It’s obvious the first one is too complicated to understand. In fact, we usually don’t need to care about the complexity inside a feature because it’s small and it doesn’t prevent from understanding the whole application.

By this approach, we separate concerns of a large project. Each feature is self manageable and decoupled from others. To understand the whole project, we look at relations among features, to understand we only look into a single and small feature.

Hard and soft dependencies

Since features need to work together, we can’t avoid dependencies among features. Actually a new feature is very possible to be based on other existing features. But we also should make feature more individual as much as possible. And we should avoid hard circular dependencies. Here we mention hard dependencies, oppositely we also have soft dependencies. Below is what we define hard and soft:

When feature A is based on feature B, that is B will not work without A. We say the dependency from B to A is a hard dependency.

For example, diagram feature provides visualization of the project, it uses data from home feature, if no home feature then diagram doesn’t work. Then we say diagram hardly depends on home.

When feature A uses some artifacts from B (depends on B) to provide new capabilities, but if without B, A still works by simply remove related code. Then we say the dependency from A to B is a soft dependency.

For example, in Rekit portal application, Rekit-cmds feature provides the ability to manage Rekit elements, but home feature needs to provide menu items as entries. Then we say home softly depends on Rekit-cmds feature. Soft dependencies usually could be dismissed by designing some extension mechanism. For example, if home feature allows other features to register menu items then there will be no dependencies from home to Rekit-cmds. However an extension architecture always adds much complexity to the system, if not heavily needed, we prefer soft dependencies so that the system is easier to understand or debug.

In Rekit portal diagrams, we can easily find hard in solid lines, and soft dependencies in dashed lines. See below, when mouse over Rekit cmds feature, we can see the hard and soft dependencies.

Conclusion

This article describes the thought of building an application by features. All small technique artifacts should be grouped by features so that the whole system is scalable and maintainable.

Feature oriented architecture for web applications was originally published in React Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.

EDIT: This guide is outdated. Please go to the updated repository: https://github.com/mrpatiwi/ReactNativeTS

Go ahead and install Node.js and the required tools from the official install guide: https://facebook.github.io/react-native/docs/getting-started.html#content

A more complete example code and starting point is available here:

mrpatiwi/ReactNativeTS

Up next, we will setup the most basic React Native application with Typescript.

Environment

The most adequate IDE is Visual Studio Code, this doesn’t means you can’t use your favorite IDE. Just make sure you have a Typescript-related plugin, like atom-typescript for Atom.

Dependencies

Along with react-native-cli, we will need:

• Typescript
• Typings
• TSLint

Install all the required dependencies with:

npm install -g typescript tslint typings react-native-cli

Creating the app

Starting a React Native app is very straightforward:

# Create app
react-native init ReactNativeTS

# Navigate to the just created app
cd ReactNativeTS

# Start git
git init

It’s a good practice to have the Typescript-related dependencies at the package.json file, so:

npm install --save-dev typescript tslint typings

To start a Typescript project and avoid long commands on the terminal, it’s good to have a tsconfig.json file.

Also, we need to keep track of the required typings, because they are not always bundled in the dependency itself, we will use Typings:

tsc --init
typings init

The default config files should look like this:

Typings

Let’s find the typings of React Native. We can use the cli as follow:

typings search react-native

So, we found some typings, but they are written for DefinitelyTyped. To install them with Typings and move forward with the React typings we run:

typings install dt~react dt~react-native --save --global

The dt keyword has the meaning of telling the cli to use the definitions from DefinitelyTyped. The global flag is required for this cases.

Typescript config

Time to setup out tsconfig.json file. Here are declared all the required info to tell Typescript transpiler how to build our app. We will use the following settings:

• Our target JS will be ES2015, because React Native supports it by default. Also we want to use JSX syntax and be able to include Javascript files along with Typescript files.
• Out source code will be located at src directory and the output JS files will be placed at the build directory.
• We want to follow as much as possible the Babel import system. That’s why we will activate allowSyntheticDefaultImports.

The recommended tsconfig.json file should be like this:

Don’t forget to add the following to your .gitignore:

# .gitignore
build
typings

Prepare React Native app

To easily support Typescript, let’s create the main entrance of our app at the src directory:

mkdir src
touch src/index.tsx

As a minimal working example, our main component will be as next:

A few notes about this:

• We import React and React Native modules as always.
• Our IDE should capable of showing autocomplete for types and show warnings and errors.
• Component must have a State and Props interfaces. If empty, you can always use the any type.
• The styles must have typings.

To see how Typescript is transpiling our new components, run:

tsc

This automatically reads the tsconfig.json file.

The final JS file is placed at build/index.js:

You can see this is a common React Native Javascript file. The typings and interfaces are removed and the JSX syntax in converted to normal Javascript.

Putting it all together

Currently, the main index files:

• index.android.js
• index.ios.js

Are not pointing to our new base components. We should edit them as follow:

This implies that we expect to have built the TS source before running the app on a device or emulator.

Also I recommend to have the following scripts in the package.json file:

"scripts": {
  "preinstall": "rm -rf typings",
  "postinstall": "node node_modules/typings/dist/bin.js install",
  "start": "node node_modules/react-native/local-cli/cli.js start",
  "android": "node node_modules/react-native/local-cli/cli.js run-android",
  "ios": "node node_modules/react-native/local-cli/cli.js run-ios",
  "prebuild": "rm -rf build",
  "build": "tsc"
},

Open two terminals and run:

# One terminal for build and watch for changes
npm run build -- --watch

# Other terminal to run the development server
npm start

iOS & Android

Open another terminal (sorry!) to run it on a iOS emulator:

npm run ios

To run it on Android, be sure to follow the install instructions from:

https://facebook.github.io/react-native/docs/getting-started.html#dependencies-for-android

Now, any change made to the contents of the src directory will update the JS files. So Hot Reloading must be working well right now.

To build the source without watching is simple as:

npm run build

Adding custom components

It’s all about components and it rich ecosystem available to developers. So I will show how to add third-party modules and make them work with Typescript. Because — let’s be honest — there should be none React Native components written in Typescript with typings.

As an example, let’s take:

ide/react-native-button

npm install --save react-native-button

Creating the 100% perfect typings is a hard and unnecessary work. So we can do the following:

touch src/declarations.d.ts

If we use the any type, Typescript will not bother us about missing typings or wrong usage:

It’s easy and we get (rotated screen to show it better here at Medium):

It’s possible to improve the declared typings, take as example:

The usage still the same.

There are not the full typings of the components, but you can see that we can make improvements over the time.

Conclusion

The usage with Typescript is very simple. But it comes with risks:

• React (Facebook) has Flow. Even if it’s a annotation system, I think the invention of this has splitted the community. We could have a unique and common typings system for React and Angular. Maybe someday a combination of both of this technologies will be merged to the ECMAScript.
• It’s hard to find modules with typings. Un-official support comes with compatibility problems because of outdated or incomplete typings.
• The typings conventions are still immature, so it’s common to have errors and it’s hard to find updated information and guides.
• Perhaps it’s better to stick with Flow or keep using classic un-typed Javascript.

Finally, a more complete example code is available at:

mrpatiwi/ReactNativeTS

React Native and Typescript was originally published in React Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.

AngularJS is a pretty cool framework by Google — it provides many great features, like routing and two-way data binding. We used it to create the first version of our platform, but today, we see its limits and want to migrate our platform to ReactJS.

Angular helps creating single page applications and renders the content on the client-side, but is utterly bad in terms of SEO referencing. We want to have something that renders our content on the server-side at the first load, but provides the experience of the SPA applications after that: an isomorphic app. We also want to come back to Javascript, pure javascript, not an Angular abstraction, and further control our data stream.

A little more about React and its environment

React is an open source library built by Facebook.

React provides a high performance client and server side rendering with a one-way flow for data binding. It’s not a framework, that’s why we’re talking about React and all of its environnement friends.

1.Flux:

“Flux is the application architecture that Facebook uses to build client-side web applications. It complements React’s composable view components by utilizing a unidirectional data flow. It’s more of a pattern than a formal framework” — Flux

We chose Redux, as a flux implementation, a predictable state container for JavaScript apps.

“As the requirements for JavaScript single-page applications have become increasingly complicated, our code must manage more state than ever before. This state can include server responses and cached data, as well as locally created data that has not yet been persisted to the server. UI state is also increasing in complexity, as we need to manage the active route, the selected tab, whether to show a spinner or not, should pagination controls be displayed, and so on.

Managing this ever-changing state is hard. If a model can update another model, then a view can update a model, which updates another model, and this, in turn, might cause another view to update. At some point, you no longer understand what happens in your app as you have lost control over the when, why, and how of its state. When a system is opaque and non-deterministic, it’s hard to reproduce bugs or add new features.“

2.Webpack, a module bundler.

Webpack takes modules with dependencies and generates static assets representing those modules.

Refactor time

How do we refactor our entire platform? Several methods are available. To prepare, we often go to React and JS meetups. One of them is exactly on our topic: how to migrate your website to React. The conclusion of the speaker is to migrate little by little, for months, and maintain all this crazy stack.

While that’s great advice, we decide against it. We use the summer to recode the entire platform in a rush and start form zero. We keep no files from the previous version, we create this entire new project. It takes four developers, and three weeks later here we are! Here’s how we made it work.

A little preparation

Before we started coding, we “printed” all of our current website to have a global view. That allowed us to easily analyse what we want to redo. This second version was going to be built on the UI foundations of the old one, with lot of little changes in UI-components to make a better user experience. So the key idea was to abstract website pieces in order to make re-usable multiple component.

To make all of this more readable, we drew the component hierarchy. In React documentation, they call this “Break the UI into a component hierarchy”. The first thing you want to do is to draw boxes around every component (and subcomponent) in the mock and name them.

After the component hierarchy was set up, we took the time to work on our redux store.

The redux store holds the whole state of your application. We have to think about how our data will be structured and how our cache will work.

The first line of code

The first step was to migrate our stylesheets and in the same time to start a real web-styleguide. We took the opportunity to restructure our whole style, and to only keep some global component: typography, layout, buttons, input, etc. All other component will have their own stylesheet attached to them.

In order to have a great project structure, we based our architecture on one of our friends boilerplate: minus a “React / Redux isomorphic starter, focused on minimalism and beauty”.

After that, the coding begins

We split the tasks between the four of us. It was important that each member could move forward without the work of the others. Some of us focused on dumb components and others on smart components.

One very important thing in our project was authentication. Due to an isomorphic app, backend and frontend share the same code, but some code had to be specific, like the cookie handle. So an isomorphic authentication was not really easy.

And now?

Thanks to the isomorphic app, we have an increased performance, mainly thanks to the initial pageload speed. The SEO problem is no more, single page app is crawlable. If you want other benefits due to isomorphic app, you can check this: http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/. It’s a beautiful world.

With this second version, we’ve set up an advanced smooth rendering and navigation of our pages.

To do so, we’ve rendered content as quickly as possible, so we’re never stuck on a page waiting for data.

To achieve this, you need to flush async fragments. For instance, on this page, the structure loads first, then bloc number 1, and finishes with bloc number 2. Users can navigate smoothly and are never blocked on a page:

But one of the greatest benefit of our migration are the improved micro-interactions. All micro-interactions are easy to code with this new stack and really smooth for the user. You can fork a bot on the explore page. There is always an indicator of forking on the bot, wether you navigate on the explore or go back to your profile.

And that’s about it. So if you’re looking to migrate from Angular to React, go for it. It’ll be worth it.

We are working now on a big feature on the platform for October, and the front developers team is growing up, so if you want to know more, drop us a mail!

Jasmine ANTEUNIS — Recast.AI

This post was originally published on our blog. If you enjoyed it, you might also like: Datasets, the gold of Machine Learning

Angular to React: tips on a smooth migration was originally published in React Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post aims to be a guide for implementing GraphQL into a Redux App. It goes over some of the realizations I made throughout the process of integrating it into my workflow. I expect that you have some amount of familiarity with the setup involved in React / Redux projects and will link to resources as I go.

While Redux at it’s core is a State management library, often times your action creators take care of loading data from your API. The method that I have used mostly is to implement thunks, along with having several actions / action creators to communicate between the store and UI during the data-loading process.

What this generally ends up looking like is the following:

import {
  LOAD_EMPLOYEE_DATA_INITIATION,
  LOAD_EMPLOYEE_DATA_SUCCESS,
  LOAD_EMPLOYEE_DATA_FAILURE,
} from './constants';

export const employeeUrl = 'http://0.0.0.0:1338/api/employees';

// loadEmployeeDataInitiation :: None -> {Action}
export const loadEmployeeDataInitiation = () => ({
  type: LOAD_EMPLOYEE_DATA_INITIATION,
});

// loadEmployeeDataSuccess :: Array -> {Action}
export const loadEmployeeDataSuccess = (data) => ({
  type: LOAD_EMPLOYEE_DATA_SUCCESS,
  data,
});

// loadEmployeeDataFailure :: Error -> {Action}
export const loadEmployeeDataFailure = (error) => ({
  type: LOAD_EMPLOYEE_DATA_FAILURE,
  error,
});

export const loadEmployeeData = () =>
  (dispatch) => {
    dispatch(
      loadEmployeeDataInitiation()
    );
    return fetch(employeeUrl)
      .then(res => res.json())
      .then(data => {
        dispatch(
          loadEmployeeDataSuccess(data)
        );
      })
      .catch(error => {
        dispatch(
          loadEmployeeDataFailure(error)
        );
      });
  };

The pattern here is to essentially represent the control flow of your data via the dispatching (via a thunk) of actions at various stages of your asynchronous control flow.

I actually really like this pattern. I think that it works very well for the majority of my data-fetching needs. So why, you ask, would I even want to use GraphQL?

About GraphQL

GraphQL is a declarative query language, created by Lee Byron of Facebook. The initial reason why I wanted to learn GraphQL is because basically everything that comes out of Facebook is golden. Lee has supplanted himself and Facebook as one of the major thought leaders in the space and I trust his/their judgement. He brought us ImmutableJS, an implementation of persistent immutable data structures in JavaScript, the life-cycle methods in React, several contributions to the TC39 committee. Anyways, Lee and his colleagues know their stuff.

The major accomplishment of GraphQL, in my opinion, is that it inverts control of the server layer to the client. Commonly, REST architecture leaves the control of the data layer to the server. It is common nowadays to build APIs in a micro-service oriented manner, whereby the API is built in isolation of the client application and the two are connected via RESTFul endpoints.

The problem with RESTful endpoints, especially at a large scale, is that the control of the data returned from custom endpoints generally lies in the hands of the server developer. We can fake some amount of control using query parameters, but ultimately the client-side developer is at the whim of the server.

As our front ends grow more and more complex, this model starts to show its weaknesses. Over-fetching of data, multiple round trips per request, misunderstanding of the data model. It also becomes hard to maintain RESTful APIs over time because changes to the models require significant amounts of planning in order to ensure that they aren’t breaking the system.

GraphQL aims to invert the control of data flow, giving control to the front end developer. It gives them the power to define their data needs, while also optimizing the entire experience, solving many of the problems of the custom endpoint approach. On top of that, the language is highly declarative and the process of expressing your data needs fits right into the client-side development flow that many of us have become accustomed to with React.

Back to the point

Now that we have a bit of the history behind us and a greater understanding of where GraphQL fits in, we can explore a bit about why we would want to integrate GraphQL into our Redux applications and how we would go about doing it.

GraphQL, although extremely powerful, is just one part of the picture. In order to integrate it into a React/Redux application, we could use some help. This is where Apollo and Relay fit into the picture. Both intend to bridge the gap and provide the missing implementation boilerplate that makes the integration a seamless experience. I am choosing to focus on Apollo, but I’d love to use Relay and will leave that to a future article.

Apollo

The integration of Apollo into a Redux application is very straight forward because Redux is baked into Apollo Client, the library we’ll be using here. Before we get into integrating Apollo Client into our front end workflow, let’s go over the basics of setting us up on the server side.

Server Setup

With Node, Express and a few GraphQL related libraries, the server setup is fairly simple. In my example, I chose to completely forego any database setup and I generated some random JSON and CSV data that I used instead of a database.

You’ll have to keep in mind that this is not an example of a production setup, but is rather an example of how you can start messing around with GraphQL today.

// server/schema/schema.js
import {
  GraphQLSchema,
  GraphQLObjectType,
  GraphQLInt,
  GraphQLString,
  GraphQLList,
} from 'graphql';

import issuesJSON from '../data/issues.json';
import employeesJSON from '../data/employees.json';
import _ from 'lodash';
import fs from 'fs';
import path from 'path';
const store = {};

// Some helper methods to load CSV into JSON, which were removed for brevity's sake.

const customerJson = loadCsv();

const CustomerType = new GraphQLObjectType({
  name: 'Customer',
  fields: () => ({
    week_num: { type: GraphQLInt },
    num_customers: { type: GraphQLInt },
  }),
});

const PersonType = new GraphQLObjectType({
  name: 'Person',
  fields: () => ({
    name: { type: GraphQLString },
    avatar: { type: GraphQLString },
    company: { type: GraphQLString },
  }),
});

const EmployeeType = new GraphQLObjectType({
  name: 'Employee',
  fields: () => ({
    id: { type: GraphQLString },
    numemployees: { type: GraphQLInt },
    location: { type: GraphQLString },
  }),
});

const IssueType = new GraphQLObjectType({
  name: 'Issue',
  fields: () => ({
    id: { type: GraphQLString },
    submission: { type: GraphQLString },
    closed: { type: GraphQLString },
    status: { type: GraphQLString },
    customer: { type: PersonType },
    employee: { type: PersonType },
    description: { type: GraphQLString },
  }),
});

const StoreType = new GraphQLObjectType({
  name: 'Store',
  fields: () => ({
    employees: {
      type: new GraphQLList(EmployeeType),
      resolve: () => employeesJSON,
    },
    issues: {
      type: new GraphQLList(IssueType),
      resolve: () => issuesJSON,
    },
    customers: {
      type: new GraphQLList(CustomerType),
      resolve: () => customerJson,
    },
  }),
});

const QueryType = new GraphQLObjectType({
  name: 'Query',
  fields: () => ({
    store: {
      type: StoreType,
      resolve: () => store,
    },
  }),
});

export default new GraphQLSchema({
  query: QueryType,
});

Above is a very simple schema definition that we use to describe our data to GraphQL. If you were hooking this into a database, you would be making calls to it in the resolve functions you see above instead of returning the data loaded from the mock JSON files. The reason that we define a schema will be discussed more in detail later, but the idea is that we can generate a structure and assign types to our data to make static analysis possible.

We wrap our data in a root level key that we are calling Store here in so that when we query our data, it will be wrapped in a root level object. This is something that you might be used to if you’ve used the Rails ActiveModel Serializers Gem with the JSON API adapter type before. As shown below, it acts as a root level key in our queries. This is really just a preference thing and you can take it or leave it.

query Customers {
    store {
      customers {
        week_num
        num_customers
      }
    }
  }

With our schema defined, we can now tell our Express server to serve the data through an endpoint using the GraphQL Express library.

// server/app.js
import 'regenerator-runtime/runtime';
import express from 'express';
import path from 'path';
import fs from 'fs';
import { graphql } from 'graphql';
import { introspectionQuery } from 'graphql/utilities';
import schema from './schema/schema';
import morgan from 'morgan';
import cors from 'cors';

// constants needed
const isDeveloping = process.env.NODE_ENV !== 'production';
const port = isDeveloping ? 1338 : process.env.PORT;
const app = express();
const graphqlHTTP = require('express-graphql');
const query = 'query { employees { id, numemployees, location }}';

if (isDeveloping) {
  app.all('*', (req, res, next) => {
    res.header('Access-Control-Allow-Origin', '*');
    res.header('Access-Control-Allow-Methods', 'GET, POST');
    res.header('Access-Control-Allow-Headers', 'Content-Type');
    next();
  });
  app.use(morgan('combined'));
}

app.use(express.static(__dirname + '/public'));

graphql(schema, query).then((result) => {
  console.log(JSON.stringify(result))
});

(async () => {
  try {
    app.use(
      '/api',
      cors(),
      graphqlHTTP({ schema, pretty: true, graphiql: true })
    );

    app.get('*', (req, res) => {
      res.sendFile(path.join(__dirname, 'public/index.html'));
    });

    app.listen(port, '0.0.0.0', (err) => {
      if (err) { return console.warn(err); };
      return console.info(
        `==> 😎 Listening on port ${port}.
          Open http://0.0.0.0:${port}/ in your browser.`
      );
    });

    let json = await graphql(schema, introspectionQuery);
    fs.writeFile(
      './server/schema/schema.json',
      JSON.stringify(json, null, 2),
      err => {
        if (err) throw err;
        console.log("JSON Schema Created")
      });
  } catch (err) {
    console.log(err);
  }
})();

Now, it may look like there is a lot going on here, but really it is fairly simple. Most of this is really just boilerplate Express stuff, for example we are using CORS and Morgan when the app is in development in order to make our lives easier. We are also setting our access control headers.

The async IIFE that you see here is just a neat use of the Async Await feature that will be released, I believe, in the next formal JavaScript specification. It allows us to write the GraphQL schema into a schema.json file asynchronously using the new syntax. The generation of this file is part of the process.

Note, to get this working, you will need to have a file that first requires babel-core/register and then loads up the express server.

To do this, I’ve created a root level server.js file with the following:

require('babel-core/register');
var app = require('./server/app');

Clientside setup

Now we can move onto the client-side setup. I began this project as a fork of my own React Boilerplate, where I have all of the boilerplate setup for React / Redux. My boilerplate aims to modularize React applications, and thus the setup was a bit different from the guide located on the ApolloClient site.

The main difference between the code on the site is that I separate out my Routes, Store and Reducer into separate modules, which you can see if you take a look at my boilerplate project. For this reason, I suggest creating a new file called apolloClient, that you will use as a singleton in multiple files.

// /app/src/apolloClient.js
import ApolloClient, {
  createNetworkInterface,
  addTypeName,
} from 'apollo-client';

const client = new ApolloClient({
  networkInterface: createNetworkInterface('http://0.0.0.0:1338/api'),
  queryTransformer: addTypeName,
});

export default client;

Make sure that you set your network interface URL to the same endpoint that we created early in the Express setup.

Now, we need to use this client in multiple places in our App:

// /app/src/reducers.js
import client from './apolloClient';

const rootReducer = combineReducers({
  // ... Other reducers go here
  routing: routerReducer,
  form: formReducer,
  apollo: client.reducer(),
});

/ /app/src/routes
import { ApolloProvider } from 'react-apollo';
import client from './apolloClient';
/* eslint-enable */

const routes = (
  <ApolloProvider store={store} client={client}>
    <Router history={history}>
      <Route path="/" component={App}>
        <IndexRoute component={Pages.LandingPage} name="Home" />
        <Route path="*" component={Pages.NotFoundPage} />
      </Route>
    </Router>
  </ApolloProvider>
);

// /app/src/store.js
import client from './apolloClient';
const loggerMiddleware = createLogger();
const middlewares = [thunk, loggerMiddleware, client.middleware()];

const enhancers = [];
const devToolsExtension = window.devToolsExtension;
if (typeof devToolsExtension === 'function') {
  enhancers.push(devToolsExtension());
}

const composedEnhancers = compose(
  applyMiddleware(...middlewares),
  ...enhancers
);

const store = createStore(
  rootReducer,
  initialState,
  composedEnhancers,
);

The three important pieces here are that we need to get setup is

1. We need to make a reducer that will act as our representative for the apollo client within our store.
2. We also need to hook up our ApolloClient singleton to our application via the ApolloProvider, a HOC that sits around our routes in this case.
3. Finally, we need to add the ApolloClient middleware to our store.

This may seem like a lot of boilerplate, and well it is. Similarly to Redux, once we have this boilerplate setup, our application development process is extremely streamlined and declarative.

By wiring in the ApolloClient, we are now free to carry on using Redux as we were before, while using GraphQL to replace our Thunks from earlier.

Within our containers, we can create declarative query strings that Apollo will handle the details of executing clientside. At this point, a container might look something like this

import React, { Component, PropTypes } from 'react';
import { connect } from 'react-redux';
import { bindActionCreators } from 'redux';
import * as KeyMetricsViewActionCreators from './actions';
import gql from 'graphql-tag';
import { graphql } from 'react-apollo';
import cssModules from 'react-css-modules';
import styles from './index.module.scss';
import Heading from 'grommet/components/Heading';
import { LineChart } from 'components';

class KeyMetricsView extends Component {
  render() {
    const {
      loading,
      store,
      areaChartLabels,
    } = this.props;
    return (
      <div className={styles.keyMetricsView}>
        <Heading align="center">
          Key Metrics
        </Heading>
        {loading ?
          <Heading tag="h2" align="center">Loading</Heading>
        :
          <LineChart
            data={store.customers}
            labels={areaChartLabels}
          />
        }
      </div>
    );
  }
}

KeyMetricsView.propTypes = {
  store: PropTypes.array.isRequired,
  areaChartLabels: PropTypes.array.isRequired,
  loading: PropTypes.bool.isRequired,
  error: PropTypes.object,
};

// mapStateToProps :: {State} -> {Props}
const mapStateToProps = (state) => ({
  areaChartLabels: state.keyMetrics.areaChartLabels,
});

// mapDispatchToProps :: Thunk -> {Action}
const mapDispatchToProps = (dispatch) => ({
  actions: bindActionCreators(
    KeyMetricsViewActionCreators,
    dispatch
  ),
});

const allCustomers = gql`
  query allCustomer {
    store {
      customers {
        week_num
        num_customers
      }
    }
  }
`;

const ContainerWithData = graphql(allCustomers, {
  props: ({ data: { loading, store } }) => ({
    store,
    loading,
  }),
})(KeyMetricsView);

const Container = cssModules(ContainerWithData, styles);

export default connect(
  mapStateToProps,
  mapDispatchToProps,
)(Container);

Notice how we are still able to continue using connected Redux components. To me, this is the best of both worlds. Once you have this wired up, you will see that behind the scenes, ApolloClient is taking care of the asynchronous action creators for us and we no longer need to follow the model mentioned earlier.

This setup allowed me to get my hands dirty with GraphQL without giving up Redux. When I have a better understanding of how Relay fits into that same picture, perhaps I will give it the ‘ol College try, but for now I am very happy with this setup.

In this example, what I am really trying to show you is that the GraphQL setup with ApolloClient is very similar to what we are already doing with Redux. It allows us to wrap our container with a function that maps the data returned from our Query to properties that we can using in our React container and pass down to our Children.

ApolloClient behind the scenes is doing almost exactly what we were manually doing earlier with our Thunks. It is sending Redux actions at each stage of the control flow. The benefit, if you choose to see it that way, is that it takes care of abstracting away those details.

Inversion of Control

Back to the point, GraphQL flips the entire server relationship model on its head. It gives us, the people who are actually building the client-facing application UI complete control over our data needs. It does so while remaining flexible and performant, cutting down on refetches and preventing over-fetching. It lets us represent our data needs declaratively and helps to bridge the gap between the client and server.

It also encourages exploration of data. Using the GraphiQL IDE, which can be enabled with the Express GraphQL library, the client-side developer has a tool that they can use to get their hands on the actual data by writing GraphQL queries in the browser. Take a look at GraphQLHub to see what I mean. I’ve been spending some time getting my Data Science friends pumped on the idea of using GraphQL as part of a data science pipeline. I can see it being useful in a number of other domains where having control over representing your data needs as a Graph would come in handy.

What you are seeing in action with the GraphiQL IDE is the static analysis that GraphQL is able to do behind the scenes. The GraphQL specification makes key the concept of allocating types to your data schema, providing a mechanism to perform static analysis. As you are typing out your query within the GraphiQL IDE, you will see instant feedback, including intelligent autocompletion and syntax error highlighting. All of this is made possible by mechanisms built right into the GraphQL specification.

Beyond the purview of this article, these tools provide even more powerful data fetching facilities, such as optimistic UI, pagination, mutations, and many others. Relay has client-side caching built right into it, and manages many of the complexities of loading massively complex feeds of data.

More Resources

Hopefully this article has gotten you pumped about integrating GraphQL into your app. I hope to write more articles like this in the future as I get more hands on time with a production setup. In the meantime, here are some of the resources that I used to learn about GraphQL and the accompanying tools and libraries.

• Apollo Stack website
• Learn GraphQL
• GraphQL Documentation
• Relay Documentation
• GraphQL Specification — This document is especially useful if you are serious about integrating GraphQL.
• GraphQL Concepts Visualized — An amazing article that explores how our data can be expressed by Graphs.

The application that I built can be found here for reference, although I must warn that I am still working on the app, so it could break over the next week.

Enjoyed this article? Please make sure to tap the like button below!

Implementing GraphQL in your Redux App was originally published in React Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Summary: If you are excited about just declaring data required by your UI components while leaving the difficult parts of data fetching, updating, and data handling performance issues to a framework, you will be excited by Facebook’s recent release of Relay/RelayJS (Sep 2015), which works with React UI (Oct 2014). This article shows you how to to integrate Relay/React into Rails.

NOTE:

• You can clone this starter-kit from Github, and start using Relay immediately without reading further
• Conversely, with instructions here you can re-create the starter-kit on Github

Facebook introduced React (Oct 2014) to make creating rich web UI easy to reason, and debug with its uni-directional data flow; all data required by the entire web UI on a page is piped through a top-level UI component, which percolates only the necessary data to each sub-components under it.

However, the React component (usually the top-level component), or the optional Flux framework (if you implemented it), is still responsible for fetching the required data using Ajax, etc., and you have to write that.

Enter Relay! When you create a React component, you just need to declare the data that it needs, and Relay will handle the gory details of fetching the data efficiently, which includes batching queries, collapsing access patterns, caching, etc.

Overview

Assumptions:

• You have Rails installed (tested on Rails 4.2 only)
• You have >= ruby-2.1

Goals:

• Make it easy to understand (see Relay in Pictures section) Relay
• Setup Relay/React on Rails so that we can create a very simple Rails/Relay/React application, which outputs to the browser:

The Board!
Boarding… Simpleton

NOTE: The 2nd line ‘Boarding… Simpleton’ is a React component, which relies on Relay to pull its data (Simpleton) from the server over the Internet.

• Use this setup as a foundation to further experiment with Relay

Why this is difficult:

As of this writing (15 Sep 2015), I could not find any information on getting Facebook’s Github Relay or npm-based ‘react-relay’ to work with Rails.

The existing Facebook tutorial:

• Does not show clear distinction between client-side, and server-side library requirements because in its case, both use Javascript libraries. Specifically, it does not address the question — “which libraries are required to make a non-Javascript-based server Relay-capable, and which libraries should be delivered to the browser to make the client-side Relay-capable?”

// nodejs npm package.json
// Source from Facebook's Github Relay repo
// Which libraries are client-side & which are server-side?

“dependencies”: {
 “babel”: “5.8.23”,
 “babel-loader”: “5.3.2”,
 “babel-relay-plugin”: “file:../../scripts/babel-relay-plugin/”,
 “classnames”: “^2.1.3”,
 “express”: “^4.13.1”,
 “express-graphql”: “^0.3.0”,
 “graphql”: “^0.4.2”,
 “graphql-relay”: “^0.3.1”,
 “react”: “^0.14.0-rc”,
 “react-dom”: “^0.14.0-rc”,
 “react-relay”: “file:../../”,
 “webpack”: “^1.10.5”,
 “webpack-dev-server”: “^1.10.1”
 }

• Has no information on how to transpile Relay/GraphQL client-side Javascript code, which may reside on a non-Javascript-based server, but needs to be delivered to browser for execution

// Relay/GraphQL code to get 'name' data from our
// 'simple' data model
// The browser does not understand GraphQL, so this needs
// to be transpiled to Javascript before delivery to the browser

simple: () => Relay.QL`
      fragment on Simple {
        name
      }
    `

• Is not Rails-based so you need to hunt down nuggets of information from all over the web

Relay In Pictures

Relay consists of 3 parts:

1. The schema for our data specified in GraphQL
2. A GraphQL server, which can load up the schema, and respond to client queries in GraphQL
3. A ‘transport’ layer through which a client communicates with the GraphQL server via GraphQL language

For our purpose, architecturally, this translates to:

• A Rails server acting as a GraphQL server serving our data based on our schema (requirement 1. & 2.)
• The Rails server delivering the necessary client-side Javascripts required for the browser to communicate with the GraphQL server through the Relay ‘transport’ layer, using the pre-agreed data schema (requires 1. & 3.)

To facilitate understanding, we illustrate the Relay nodejs setup used by the Facebook tutorial, and then compare what that setup should look like for Rails.

Things of note:

• Our GraphQL data schema (bottom-left box) is in either Javascript (nodejs server) or Ruby (Rails sever) but is converted using a npm script (nodejs) / Rake task (Rails) to JSON (follow the arrow upwards from the bottom-left box); nodesjs/Rails server-side code can use the GraphQL schema in Javascript/Ruby format, but babel-relay-plugin (more on this in next) needs it in JSON format
• Transpilation of Relay.QL code (top-left box) to Javascript is done by babel (nodejs) / babelify (Rails) with the help of the babel-relay-plugin based on GraphQL data schema (JSON format)
• We can clearly see what libraries are needed to make nodejs/Rails speak GraphQL, enabling it to host a /graphql endpoint (bottom-right box); the arrows from libraries/Gems pointing to the ‘Pure JS server-side /graphql endpoint’ (bottom-right box)
• All Javascript code that needs to be delivered to the client-side (top-right box) is bundled using webpack (nodejs) / browerify-rails (Rails), which is also where transpilation is configured

Let us look at how we can setup each component in detail next.

Rails GraphQL Server

GraphQL-speaking Rails

Add the following gems and run ‘bundle install’:

# Gemfile

gem ‘graphql’ 
gem ‘graphql-relay’

graphql-ruby bestows Ruby with the ability to understand GraphQL, while graphql-relay-ruby provides helpers to handle Relay specific-concepts such as:

• Associating a piece of data with a global id to facilitate re-fetching
• Tying a piece of data with associated data, e.g., a piece of data representing a Person, can have many associated pieces of data about each of his Friend
• Updating a piece of data with input from client (Relay uses the fancy term ‘mutation’)

GraphQL Data Schema

Facebook’s official tutorial shows how we can use GraphQL for data schema definition. Unlike the tutorial, instead of defining the data schema in Javascript (data/schema.js), we define it using graphql-ruby classes in a set of files under app/graph.

We will present a very simple GraphQL schema here as it is a huge topic, and Facebook’s tutorial has covered it quite a bit.

A GraphQL schema consists of a Query, and Mutation type, for handling queries and updates respectively. Each of these is compose-able out of other GraphQL types, e.g., our Simple query is composed from SimpleType (see below).

The first thing that you need to implement for the schema is the standard NodeIdentification interface; each piece of data that a client fetches through Relay/GraphQL comes from an instance object, e.g., an ActiveRecord, in Rails. Each of them is also assigned a global ID, that when passed back to Relay/GraphQL, enables Relay/GraphQL to re-fetch that same instance object (whose data may have changed). For more details read this, but in the same vein as Facebook’s Relay tutorial, this was introduced at the start.

# app/graph/types/node_identification.rb

GraphQL::Relay::GlobalNodeIdentification.instance_variable_set(:@instance, nil)

NodeIdentification = 
  GraphQL::Relay::GlobalNodeIdentification.define do
    object_from_id -> (id) do
      type_name, id = NodeIdentification.from_global_id(id)
      type_name.constantize.find(id)
    end

type_from_object -> (object) do
      RelayOnRailsSchema.types[object.class.name]
    end
end

Next, let us look at the GraphQL schema Query (but leave out Mutation as an exercise).

# app/graph/types/query_type.rb

QueryType = GraphQL::ObjectType.define do
  name “Query”
  description “The query root for this schema”

  field :simple do
    type SimpleType
    description “Simple Stuff”
    resolve -> (obj, args, ctx) do
      Hashie::Mash.new( { id: rand(1000), name: ‘Simpleton’ } )
    end
  end

  field :node, field: NodeIdentification.field
end

This schema enables us to query data by either of the fields:

• :simple with some arguments (args)
• :node id

Under the :simple field:

• resolve tells us how to get the data. In this case, we merely return a constant hash. However, if arguments were provided in the GraphQL query, e.g., a user email, we can access it in args and fetch data based on it by replacing resolve with:

# app/graph/types/query_type.rb

... 
 resolve -> (obj, args, ctx) do
    # Using ActiveRecord for Person Model
    Person.find_by_email(args[:email])
  end
...

• SimpleType defines the structure of the data we fetch (app/graph/types/simple_type.rb)

# app/graph/types/simple_type.rb

SimpleType = GraphQL::ObjectType.define do
  name “Simple”
  description “Simple”
  interfaces [NodeIdentification.interface]
  global_id_field :id
  field :name, !types.String, “Simple name”
end

We bind the Query type into our data schema in app/graph/relay_on_rails.rb. This is also where you bind a Mutation type if you have one.

# app/graph/relay_on_rails.rb

RelayOnRailsSchema = GraphQL::Schema.new(query: QueryType)

To ensure that Rails can find our schema in app/graph/types, add to config/application.rb:

# config/application.rb

# Load all graphql types
config.autoload_paths << Rails.root.join(‘app’, ‘graph’, ‘types’)

At this stage you can test that Rails can speak GraphQL through the RelayOnRailsSchema object, by firing up your Rails console:

# rails console

> query_string = “query SimpleQuery { simple { name } }” 
=> “query SimpleQuery { simple { name } }”

> RelayOnRailsSchema.execute(query_string)
=> {“data”=>{“simple”=>{“name”=>”Simpleton”}}}

GraphQL Endpoint

With Rails speaking GraphQL, and understanding our data schema, all we need now is to expose the GraphQL endpoint /graphql that the client-side Relay ‘transport’ communicates to by default.

Define the /graphql endpoint in config/routes.rb:

# config/routes.rb

scope ‘/graphql’ do
  post”/”, to: “graphql#create”
end

Handle the /graphql endpoint with the GraphqlController#create method in app/controllers/graphql_controller.rb.

class GraphqlController < ApplicationController
  # Ignore CSRF, rely on some auth token
  protect_from_forgery :except => [:create]

  def create
    query_string = params[:query]
    query_variables = params[:variables] || {}
    query = GraphQL::Query.new(RelayOnRailsSchema, query_string, variables: query_variables)
    render json: query.result
  end
end

Start the rails server using rails s within the root directory.

Now test the endpoint from the command line:

# Command line

$ curl -d “query=query SimpleQuery { simple { name } }” http://localhost:3000/graphql

> {"data":{"simple":{"name":"Simpleton"}}}

The Rails GraphQL server is now ready.

Serving Client-side Relay Javascripts

Relay/React Javascript Libraries

From the Rails Relay Setup illustration, we know that we need to deliver Relay/React Javascript libraries (react, react-relay, etc.) to the client-side. We prepare them on the server-side first with npm which relies on a package.json file that specifies all the Javsacript libraries:

// package.json

{
  “name”: “relay_on_rails”,
  “license”: “MIT”,
  “engines”: {
    “node”: “>= 0.10”
  },
  “dependencies”: {
    “babel-relay-plugin”: “^0.2.5”,
    “babelify”: “^6.3.0”,
    “browserify”: “~> 10.2.4”,
    “browserify-incremental”: “^3.0.1”,
    “graphql”: “^0.4.4”,
    “react”: “^0.14.0-rc1”,
    “react-dom”: “^0.14.0-rc1”,
    “react-relay”: “^0.3.2”
  }
}

Do:

npm install

Which downloads all the libraries into node_modules/. To deliver them to client-side, we use browserify-rails, which bundles node_modules/ content into Rails assets pipeline without requiring any configuration.

Add the gem and run ‘bundle install’:

# Gemfile

gem ‘browserify-rails’

Relay.QL and GraphQL Data Schema

With Relay, for each React component in our client-side Javascripts, we create a RelayContainer counterpart to declare its data requirement:

// app/assets/javascripts/relay/components/board.react.jsx

class BoardApp extends React.Component {
  render() {
    var _name = this.props.simple.name;
    return (
      <div>
        Boarding… {_name}
      </div>
    );
  }
}

var BoardRelayContainer = Relay.createContainer(BoardApp, {
  fragments: {
    simple: () => Relay.QL`
      fragment on Simple {
        name
      }
    `,
  },
});

In the RelayContainer, there are Relay.QL fragments, which are NOT Javascripts, and needs to be transpiled based on the GraphQL data schema we defined at our GraphQL server.

Facebook provides the babel-relay-plugin to do the required transpilation, but it requires our data schema in JSON format as input. To convert our Ruby-based GraphQL schema in app/graph into a JSON file (app/assets/javascripts/relay/data/schema.json), use the Rails console:

# rails console
File.open('app/assets/javascripts/relay/data/schema.json', ‘w’) do |f|
  f.write(RelayOnRailsSchema.execute(
    GraphQL::Introspection::INTROSPECTION_QUERY).to_json
  )
end

If you are using the starter-kit, just do:

# Command line

rake graphql:update_schema_json

Create a new transpilation plugin by initializing babel-relay-plugin with the JSON schema file as shown in app/assets/javascripts/relay/utils/babelRelayPlugin.js:

// app/assets/javascripts/relay/utils/babelRelayPlugin.js

var getBabelRelayPlugin = require(‘babel-relay-plugin’);

// load previously saved schema data
var schemaData = require(‘../data/schema.json’);

// create a plugin instance
var plugin = getBabelRelayPlugin(schemaData.data);

module.exports = plugin;

Transpile Relay.QL fragments

Configure browserify-rails to perform transpilation (while doing bundling) in config/application.rb:

# config/application.rb

config.browserify_rails.commandline_options = ‘-t [ babelify --plugins “./relay/utils/babelRelayPlugin” ] --extension=”.react.jsx”’

Note that the plugin we created from babel-relay-plugin, relies on babelify.

NOTE: As bonus, babelify can also transpile JSX tags if they are used in our React components. However, babelify seems to do JSX transpilation only if your files have .jsx extension.

Displaying the Relay/React App

Prepare a Javascript snippet to render the RelayContainer (BoardRelayContainer) in app/assets/javascripts/relay/boardapp.react.jsx:

// app/assets/javascripts/relay/boardapp.react.jsx

var BoardRelayStart = function() {
  ReactDOM.render(
    <Relay.RootContainer
      Component={BoardRelayContainer}
      route={BoardRelayRoute}
    />,
    document.getElementById(‘board-id’)
  );
};

module.exports = BoardRelayStart;

Make the BoardRelayStart function available. The simplest way is declaring it in app/assets/javascripts/application.js:

// app/assets/javascripts/application.js

window.getBoardApp = require(‘relay/boardapp’);

Lastly, deliver the UI to the user through a HTML page with a Javascript to call BoardRelayStart function in app/view/static_pages/board.html:

// app/views/static_pages/board.html

<div>
  The Board!
</div>
<div id=’board-id’>
</div>

<script>
  window.getBoardApp();
</script>

The controller for this page is in app/controllers/static_pages_controller.rb:

# app/controllers/static_pages_controller.rb

class StaticPagesController < ApplicationController
 def board
 end
end

And its routes in config/routes.rb:

# config/routes.rb

scope ‘/static_pages’ do
  get “/board”, to: “static_pages#board”
end

I hope you will find this Relay On Rails starter-kit useful! Let me know of any errors, suggestions, etc. @neth_6.

Resources

Facebook Relay: The source of authoritative information on Relay

Facebook Relay Tutorial: I read this (> 2 times start-to-end) to get started

Facebook Relay Github Repo: The examples provide useful references for various GraphQL schema definitions, and client-side Relay Javascript and Relay.QL snippets

Facebook Relay Starter Kit: If you are doing everything in Javascript, and have a preference to use webpack for Javascript bundling/transpilation, clone this to get started, or refer to it for webpack configuration

Simple Relay Starter Kit: If you are doing everything in Javascript, and have a preference to use browserify for Javascript bundling/transpilation, clone this to get started, or refer to it for brwoserify configuration

graphql-ruby & graphql-relay-ruby: The authoritative sources for defining GraphQL schema in Ruby GraphQL classes, and getting Rails to speak GraphQL.

browserify documentation: Command-line options required to do transpilation, e.g., —plugin, etc.

Relay/GraphQL On Rails was originally published in React Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.

import React from ‘react’

Or this guy?

import ReactDOM from ‘react-dom’

A few weeks ago, a colleague at Udacity showed me a trick that eliminates the need for repetitive import statements in your code. The magic starts on line 18, with Webpack’s ProvidePlugin:

When Webpack builds your JavaScript, it will load the ‘react’ module whenever the identifier ‘React’ is declared in your code. So now you can use:

React.createClass(…)

…without having to import ‘react’ explicitly at the top of your component file.

Webpack’s ProvidePlugin isn’t limited to React dependencies, of course. You can use it to load all your frequently used modules.

This not only leads to fewer build errors, it also gets rid of big import blocks like this at the top of your code:

import ReactDOM from ‘react-dom’
import _ from 'lodash'
import $ from 'jquery'
import cssModule from 'react-css-modules'

I feel an irrational amount of happiness about such things, don’t you?

Never `import React from ‘react’` again, thanks to Webpack’s ProvidePlugin was originally published in React Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, we’ll deep dive into building a full TodoEditor with MobX and React, starting from the basics and ending with some considerations.

Here you’ll find the entire code repo!
https://github.com/mattiamanzati/react-mobx-todo-editor

Finding a JavaScript editor

First of all, you will obviously need any text editor to edit your JavaScript code. I recommend using VSCode, an OpenSource JavaScript editor supported by Microsoft. Give it a shoot, it’s great!

Setting up the build environment

Setting up the full stack build environment for a React application could be tedious, but fortunately facebook published a create-react-app package, which provides a fast and convinient way to create your React app and automatically setup Babel and Webpack.

Now, after installing NodeJS on our system, let’s install the create-react-app package globally by doing

npm install -g create-react-app

Notice: if you are running on Linux, you may need to prefix it with “sudo”.

Now we can create our project folder by running from the parent destination folder:

create-react-app react-mobx-todo-editor

After some dependencies are downloaded, a “react-mobx-todo-editor” folder will appear, and we’ll reference to it later as “project folder”.

Unfortunately the preset does’nt includes by default support to decorators, that we will use later to decorate class properties, so we need to “eject” the default configuration and edit that manually. To do so, simply run

npm run eject

inside of your project folder. That will result in a config and in a scripts directory being created. Let’s now install the Babel plugin to handle decorators:

npm install babel-plugin-transform-decorators-legacy --save-dev

now, we need to edit both “config/babel.dev.js” and “config/babel.prod.js” and add the decorators legacy transformer to the plugins array like this to let babel know about this additional transformer:

plugins: [
    // handles @decorator
    require.resolve('babel-plugin-transform-decorators-legacy'),

Now, you can run

npm run start

to start the development server: a browser page will open showing a default React app.

You can also run

npm run build

to create the production build of your project! A “build” folder will appear containing the built files of your single page application.

You can now clear the content of the “src” folder, as we will put there our application code.

Installing additional required packages

Now we need to install mobx and mobx-react! To do so, simply type:

npm install mobx mobx-react --save

Creating the domain models with MobX

React and MobX are great libraries that allow to build a clean MVVM architecture in JavaScript.

Let’s now start by writing first our domain models, which in this example the only domain model is the “Todo” entity. We’ll create a “Todo.js” file in the “src” folder with the following code:

To create a full working example, I added two serialize and deserialize methods, but keep in mind that you could use https://github.com/mobxjs/serializr to easily define the model schema and serialize/deserialize it easily to JSON.

Creating the ViewModel in MobX

You know, Model is’nt everything! You need somewhere to define the logic to interact with it! That’s what’s the ViewModel is for. ViewModel provides data and logic that will be used by the view to interact with domain models.

We will create a “TodoViewModel.js” file in the “src” folder with the content below:

As you can see, our view model is a simple list of todos, with methods to add and remove todos and save and load them form the browser LocalStorage.

Creating the React View

Now we have all the data and methods to interact with… what’s missing? The View! To create the View we simply create React components that accepts a “model” prop which is an instance of our ViewModel and decorate them with “observer” from the “mobx-react” package.

The observer will automatically force the view to update whenever an object given as prop to our component has changed observable properties. And that’s exactly our case; we want the view to automatically update whenever our ViewModel or our Model changes.

This way our view is completely decoupled from our logic. We could for example take advantage of this feature and create a React Native view using the same Model and ViewModel of the HTML one.

Notice that I have used classic React components class to improve readability, but you should use StatelessFunctionalComponents, as the data is coming in from the view model.

Wiring it up

Finally the last step is to wire up ViewModel and View, and proceed to render them. To do so, we simply create and “index.js” file in our “src” folder that imports the View and the ViewModel, creates a ViewModel instance and render the View with the given ViewModel instance.

Now we run “npm run start” and our first React & MobX Todo Editor is running!

If you’re ok with it, you can now simply run “npm run build” and serve the “build” folder content to an HTTP server!

Make it prettier

What your app to rock? We could use the MaterialUI package components to make our todo app look nicer! You simply need to update your view to use the MaterialUI components package! First of all, let’s install the material-ui package:

npm install material-ui react-tap-event-plugin --save

Here’s the code to build it! You can find more components in the Material UI API docs!

you will also need to add these line to the start of “index.js” in order to support mobile devices tap event:

Now you are able to build larger application with React & MobX; simply keep going creating Model, ViewModel and Views and wire them up. As occurs in other languages, you can use multiple ways to wire up the View and the View Model.

The easy one is to create a singleton of the ViewModel and simply pass it as property of the React component, as we did before.

Another way, that avoids singleton, is to use the <Provider/> and connect() from the ‘mobx-react’ package, that allows to define a top-level provider which provides instances of the ViewModels and the Views will connect() to one of the provided ViewModels.

You could also check-out the mobx-mvvm package, which is an on-going experiment that provides not only a way to link View and ViewModels, but also provides a way to link the properties of the component to the properties of ViewModel automatically.

Here you could find the same example of this post wired with mobx-mvvm.

Thanks for your time!

Building a React & MobX application with MVVM was originally published in React Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.

I give training in React.js via CodeWinds, and one of the questions I’m often asked is whether it is faster than X?

The short answer is that React.js is very performant out of the box, even before you start tweaking.

Note that performance is always a tradeoff and one needs to be careful to optimize real use cases (e.g. time to render moderately complex screen) instead of artificial benchmarks (reorder 1000 items).

Even so, React.js has a great performance story. Its component model lets you easily optimize performance bottlenecks without changing the components’ interface. You’re free to apply manual optimizations to specific parts of your app without changing your whole approach. So if you need them, additional optimizations are available.

However, I don’t think those are even the best questions to be asking.

React.js is a pivotal technology that is moving the whole industry forward.

Why is it such a game changer?

• Simplicity
• Composable components
• Declarative
• Easy to use with existing projects
• Functional / Immutable friendly

Facebook’s success in breaking from the mold and embracing bold ideas has raised the bar for everyone. It takes a leader to blaze the trail and prove out a technology before the mainstream will even take notice. Fortunately Facebook has just such an engineering team and leaders who embrace sharing this openly with the world.

There are always going to be new libraries or frameworks that will come up optimized for specific use cases that will be knocking on the doors wanting to take the new performance crown. So we have to be careful to not get caught up in chasing that carrot. It’s a never ending battle.

Performance does matter, but it’s only one of the factors to consider when choosing technology.

With the fantastic teams at Google, Mozilla, and Microsoft improving JS engine performance month after month, benchmarks and performance are constantly changing. Something that was faster last month, might not be the leader in the next. Fortunately, most everything is moving forward since general engine performance is improving across the board.

Another thing to consider is how closely does that micro-benchmark match your workload? Unless you have a real world environment and are tracking actual usage, it is hard to even dream up the proper things to evaluate.

Some alternate questions which I think might be better to ask are:

Developer Experience

• Is React.js easy to learn so that my whole team can use it effectively?
• How easy is it to evolve an existing code base? Not everyone is starting with fresh stack, so is it possible to ease into React.js or does it require a full rewrite?
• How well do the React.js abstractions hold up when the codebase needs to be enhanced over time to support new features?
• What type of Developer Experience (DX) does React.js provide?
• What type of User Experience (UX) does React.js enable?

Stability & Resilience

• How reliable and solid is React.js? Are we going to be constantly chasing bugs or weird anomalies?
• Is it battle proven and receiving enough adoption to trust? Likewise, a smaller project doesn’t have the means to chase down edge cases across the multitude of browsers in use.

Community

• Is the community welcoming and supportive?
• Is React.js and its community forward thinking? Is it looking at the best ideas in the industry and moving towards those goals?

I think these types of questions are possibly more relevant to consider than the performance one.

… And I believe React.js nails it on every one of these.

In fact, it would be hard to find a UI library that has a better story than React.js with regards to all these key questions.

Even if we go back to the original performance question, React.js has an excellent position. Yes, it is very performant out of the box for the common use cases, but if necessary developers can tap into even more optimizations like shouldComponentUpdate and perhaps using immutable data structures to squeeze out additional speed. Without adding prohibitive complexity, developers have the confidence that they can optimize slow parts of their app if and when real use indicates performance enhancements are necessary and justified.

In my opinion, Facebook and the React.js community have set a new bar for UI development, one that now extends into mobile apps and all variety of devices (desktop, set top, …) as well. I believe history will hold a special place for this little UI library.

So be a part of the revolution. Join the React.js community. I think you’ll love it.

Some resources to get started with React.js

• Main React.js site contains some great articles to get you started.
• CodeWinds has continuing coverage of React.js and will host my forthcoming video course on React.js due this summer. Subscribe to be notified when it is available.

Many thanks to those that reviewed my article and provided feedback

• Kevin Old @KevinOld
• Jed Watson @JedWatson
• Dan Abramov @Dan_Abramov

Is React.js fast? Faster than {framework}? … or are there more relevant questions to be asking? was originally published in React Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever since the inception of client side JS taking control of the web, we have observed a hefty amount of JS being written or included in our web apps. Gone are the times when our servers used to render the html for our web apps (although they’re used for initial server side rendering). Today we need more out of our web apps like lazy loading of data through Ajax, cool animations, app state management, routing, infinite scrolling and many more.

All of these things mentioned require a decent amount of work on JavaScript by a front-end developer. The result is a huge pool of JS files since developing for front-end requires being dependent on some library or framework or at least jQuery. Writing all of your code in VanillaJS is not everybody’s cup of tea. Besides this, you also tend to keep your code modular using design patterns namely modular pattern, factory pattern, singleton pattern, observer pattern etc. These things takes an important place in development. I can’t imagine engineering a complex web app without the use of such design patterns.

Now, while maintaining a modular code is beneficial for development purpose but not ideal for your production environment. It’s a very crucial step in web optimisation to bundle up all your files into one before deploying on production. Why? because generating individual http network request for all those modular files is not efficient. Running 1 request for a bundled file over 100 requests to fetch 100 files is more efficient. So, as you can see there’s a trade off kinda situation between the two approaches. The latter approach can provide you with things like lazy loading of modules on demand but results in a lot of network requests. The former approach does efficiently single request and reduces frequent roundtrips to the server but at the same time takes a heavy toll on the initial load time. The CRP(Critical Rendering Path) of your web app should not involve long blocking Javascript as it might block your initial load time giving a bad experience to your first time users and even worse on a slow network.

So, one thing is clear that we just have to bundle up the JS files for production while keeping the initial load time low. Then how can we break this deadlock? The answer is Code Splitting or Chunking i.e we can find a middle ground between these two things by increasing the number of requests while keeping them bundled.

My discussion will follow my favourite bundling tool webpack. But this concept of chunking is there in all other bundlers like browserify, requirejs or almondjs. Coming back to the discussion, for most of our web apps we have two kind of codes, one which is written by us and the other on which we depend or the third party libs you can say. Now, its wise to separate them apart firstly. Reason I’ll tell you shortly.

Above are the two illustrations of my bundled file sizes before and after chunking. As you can see my index.js has size of 666 kB(after minification) in the first screenshot and when I moved all my vendor or 3rd party code to vendor.js it became 1.1 MB + 172 kB. This inflation is because I have included the whole Material UI library for my react project instead of individual components as in the first case. But lets not deviate out discussion on that. Sticking to the point, we have successfully finished the first phase of chunking.

Lets, do a bit more. Lets say I wanna cache this vendor.js on user’s client machine for a longer period of time using maybe service worker, server side caching or through shipping it along with my Android app build as I do at my current job. The point is, our vendor.js is not going to change that frequently as compared to my own written code in the form of index.js. Moving on, we have to do versioning to make sure our vendor.js file doesn’t change overtime. Also for generating a hash based content for our vendor.js, we’ll need to separate our webpack runtime code from it into say meta.js or init.js. See this github issue. The result will look something like this.

Also, to make your vendor.[chunkhash].js fully static, please use this new webpack NamedModulesPlugin since it uses the names of module files instead of dynamically generated files during bundling. These are all little caveats I figured out while working with webpack.

Cool, so far we have separated the runtime from our vendorjs, content based automated versioning has been done. Our build files are ready for caching. Only one teensy things left, infact the main challenge, how will we include these dynamically generated hashed filenames into my index.html?? Don’t worry, there exists a webpack HtmlWebpackPlugin that’ll exactly solve this problem. You can use it like this

As you can see I’m using an ejs template for generating my index.html file. You can skip that and set your inject option as true which will automatically inject the generated js files in the end before the closing body tag. My requirement was different since I had to embed my versioned files in a Django template which already has {{}} reserved, otherwise I could had used moustache or handlebars. You can checkout more options on HtmlWebpackPlugin docs.

Voila! We just accomplished transforming our web app ready for caching 3rd party vendor.[chunkhash].js. Now, all that will change overtime is index.[hash].js. So, 90% of the load time has been already reduced for subsequent page loads on users machine as the hash of the vendor file will remain same through out. Now, all that we need to focus is on index.[hash].js which is 172 kB in our case. We can further break this into chunks and load them on demand on events like route change most commonly.

Lets try it out with react-router. React Router allows you to add hooks to routes before navigating. So what you can do is specify the load of a certain module using require.ensure or System.import with webpack 2. Lets stick to the former one.

Above is the implementation of lazily loading the route. On a side note, I tried abstracting the getComponent handler function but for some bizarre require context reasons it wasn’t accepting dynamic params from the closure (If you can solve it, please go ahead and let me know as well). Anyway, lets see run the webpack and analyse the output.

The size of the index.[hash].js has reduced from 173 kB to 113 kB. There’s a straight ~35% or reduction in its size, so you can pretty much expect quicker initial load than before. And as you navigate to a certain route, the corresponding chunk will be load lazily on demand.

Phew! That was tiring. Was it? You decide. But in the end of the day your app users will be happy which is makes our efforts worthy. So, go ahead and transform your web app taking these amazing advantages webpack offers you to put a smile on your app users face.

Summary

So, we learnt about why bundling is important, how to separate your vendor and your own app code to implement caching, versioning your files for proper cache busting. I’m sure you might have got stuck in a situation like “I have deployed my latest code on server, but still I’m getting the old version on my app”. Webpack automated versioning we learnt can help you alleviate such pains (things like index.js?v=2). After that, our separated index file of 173 kB was reduced to 113 kB using lazy loading with react-router.

I hope you liked my post. I thoroughly enjoyed writing it and in fact learnt few things while writing it. If you do too, please recommend and comment.

Thank You!

Code Chunking with Webpack — A pragmatic approach was originally published in React Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.

I believe as a community, many of us JavaScript engineers have embraced Immutable Architecture. Whether we realize it or not, a new way of building apps has crept into the mainstream JavaScript ecosystem and it is here to stay.

What is Immutable Architecture, anyways?

To understand immutable architecture, we need to first understand state. State, an evil source of complexity in any software, is the characteristic of a value. According to Miriam Webster, state is defined as “the particular condition that someone or something is in at a specific time.” As we continue to make web applications with more and more dynamic data, we are introducing more and more state into our applications.

Combined with asynchronicity, a core characteristic of modern web applications, it’s no wonder why our applications have become very hard to understand.

Whether you realize it or not, you have most definitely dealt with state bugs many times over if you are a software engineer in any capacity. In fact, there is a famous white-paper about the Software Crisis that references state as the number one contributor to software complexity.

The main issue with state complexity is that it causes our code to become harder to reason about. When you are unable to reason about what your code is doing, you lose the ability to properly communicate with the computer and that leads to bugs and the inability to maintain the software. As software scales to more and more people, the probability of introducing state bugs increases exponentially.

So how do we control state complexity? It’s actually really simple, we use Immutability to our advantage.

Immutability

Immutability is defined as “unchanging over time or unable to be changed.” In software, a value that is immutable, by its very definition, does not have state! With one simple change, our entire problem is solved! Where the complexity sinks back in is when you try to do anything meaningful without stateful data and the ability to mutate data.

It is a common misconception that immutability hinders the engineer’s ability to write meaningful software. Without going into the details of the mathematical background of Functional Programming, I am going to attempt to explain immutable architecture in simple terms that hopefully all of us can understand.

State Management

The way we curtail software complexity in JavaScript land is to use a state management library, such as Redux or MobX. One can also use any number of Immutable data structure libraries, but let’s leave that aside for now. With state management, what we are attempting to do is to handle the changing values over time (state mutations) through a predictable mechanism. In other words, the only way to alter state is through a strict mechanism.

In the case of Redux, we use pure functions to mutate state. Pure functions are defined as those that given the same input, always return the same output. In other words, they are predictable as they do not rely on any outside mechanism or global state.

By employing state management in our apps, we are boldly turning off mutable state within the majority of our app and we are using state management to manage the situations where our state needs to be changed in order to provide a meaningful experience to our application’s end users.

I hope you see that this idea is fundamentally simplistic in nature. You do not need to be a functional programming wizard to understand it. State management needs to be a primary focus of all of our applications going forwards.

One way data flow

I am sure you have no doubt heard of unidirectional data flow by now. It is a natural extension of the ideas described above. With unidirectional data flow, we take the principles of pure functions and apply it to our entire app.

So now, our state is managed properly, we are using immutability throughout our app and our application consists almost entirely of pure functions. By thinking of our applications as a pure function of state, we are suddenly able to reason about what the application is doing. This can be applied to our entire application architecture, from data-fetching to UI.

A perfect example of this in practice is React. With React, you design your user interface as a collection of components. Each component is a pure function that takes data and returns HTML. With unidirectional data flow, we are able to describe our application as pure functions and we are given the guarantee that when the data changes in our app, through a predictable state management mechanism of course, the user interface will be completely recalculated.

Suddenly, we are given a guarantee that if our UI renders correctly once, it will render the same from now until eternity. The components of your application are now totally decoupled from the complexity of your app. This makes testing, both manual and automated, a predictable process.

Even without React, this concept can be applied to building applications in any domain. In fact, React is not at all necessary for this equation. Many frameworks are picking up these concepts and the newer version of JavaScript enable these ideas by having declarative mechanisms built right into the language.

Paradigm Shift

The transition to Immutable architecture represents a paradigm shift in our industry. Those of us that are using Immutable architecture on a daily basis are here to stay. Our software development process is just so much easier and less buggy. It scales well because it eliminates the biggest cause of software complexity, which again is the complexity caused by mutative state.

It is exciting to see the growing popularity of Immutable architecture. Elm, a functional language that compiles to JavaScript, was the first mainstream example of immutable architecture in Front End land. The fact that this same architecture was transferred, via Redux, to the mainstream JavaScript community is really fantastic. I think we owe a lot of credit to Dan Abramov, Lee Byron and the other incredible Facebook engineers for helping to lead the movement.

Over the last year, I have become immersed in Immutable architecture, both with Elm and JavaScript and I am happy to say that it will be the only architecture I use for the foreseeable future. There really is no going back for me. If you feel the same way, I would love to hear about your experience!

More Resources

If you have yet to embrace immutable architecture, I recommend the following resources.

• Talk by Lee Byron on Immutable Architecture
• Motivation behind Redux
• Mostly Adequate Guide to Functional Programming in JS
• Purely Functional Data Structures— Not for the feingt of heart, but a fantastic source of information about persistant immutable data structures.
• Immutable Infrastructure in Cloud Computing

Also, searching for Immutable Architecture and Functional JavaScript on Medium provides dozens of fantastic articles on the subject.

Please click the like button if you enjoyed this!

Embracing Immutable Architecture was originally published in React Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.