This is part 2 of a series. Check out part 1 if you want to know why we went for React Native and how we approached it.

Written by Kenneth Skovhus and Kevin Pelgrims.

React Native under the hood, a crash course

To understand how React Native works on mobile, you first need to look at the virtual DOM (Document Object Model) that is used in both React and React Native. If you’ve ever done web development, you know how the DOM works in the browser. If not, you might be interested in reading up on it. In short: The DOM represents a page as nodes and objects. In plain React, the virtual DOM is an in-memory representation of the UI on top of the actual DOM. When a node or object changes, React will diff the virtual DOM and the actual DOM, and only update those nodes or objects that have changed. In React Native, there is no browser DOM. Instead, the virtual DOM is rendered into native iOS or Android views.

While you write plain JavaScript and JSX (tag syntax that is an extension to JavaScript) to define how your React Native app should look and behave, the UI is still rendered natively. Whenever there is a change in one of the nodes or objects, React Native will update the relevant parts of the UI automatically.

This is what sets React Native apart from other cross-platform solutions. Rendering native components significantly speeds up interaction with the app, and while this also introduces some complexities (sometimes you will need to create a custom UI component), for us, it was definitely a good trade-off.

Navigation is hard

Navigation has always been a bit of a problem on React Native, but the vast amount of packages that are available show that this area is under development. Ideally, Facebook would create or, at least, recommend one solution. But for now, that’s not the case, and we all have to choose a third party library and stick with it. For us, the main contenders were react-navigation and wix/react-native-navigation. The first is very flexible and runs everything purely in JavaScript, while the second one is based on native navigation on both platforms. We decided to go with react-native-navigation because we felt like native components would make the app feel more familiar to our users.

Getting used to JavaScript

JavaScript? No, thanks

In mobile development circles, most people cringe at the thought of writing an entire app in JavaScript. Why would you even do such a thing? JavaScript has a lousy reputation, and rightfully so. If you worked with JavaScript a decade ago, you likely had a horrible experience. Suitable for small scripts on websites, but not ideal for developing an application of any significant size.

However, things have changed, and over the last ten years there have been significant development efforts in tooling, frameworks, and engines. We saw the creation of jQuery, V8, Node, Backbone, … All of these efforts propelled JavaScript into one of the most used languages in the world. Today, Google’s Angular and Facebook’s React are the two most popular JavaScript frameworks. They are used by Google and Facebook themselves and provide a solid foundation for app development.

Modern JavaScript

JavaScript itself also saw significant advances in the last few years. When EcmaScript 6 came out, developers finally had access to features that were already common in most modern programming languages, such as classes, arrow functions (aka lambdas), string interpolation, let and const, and many more. Meanwhile, CoffeeScript and Babel pioneered transpilation so everyone could start using new language features that were not yet implemented by all browsers or engines. ES 7 and 8 kept on advancing the language significantly, and by now we can say that JavaScript can be a very nice language to work with.

Of course, it’s not all sunshine and rainbows. While the language itself is getting better, it is still difficult to set up a good development environment. Because of the dynamic nature of the language, doing something as simple as renaming a variable can still be a challenge. Coming from Android, you might find JetBrains’ IntelliJ useful, because of its familiarity. Web developers tend to stick with editors like VSCode or Atom when they go to React Native. As long as the plugins are there to support what you need, you can use any editor you want.

We found that a lot of JavaScript’s shortcomings can be countered with internal coding conventions and a good tooling setup to enforce them. Once you get into the habit of writing good, idiomatic JavaScript in a proper architecture, it becomes quite nice, even when you come from Swift or Kotlin in native land.

Tooling

After we understood how React Native works and decided to make peace with JavaScript, we wanted to make sure we had the right tooling set up to enforce best practices, and that the native developers on our team are made aware when they write non-idiomatic JavaScript. The setup, with a variety of tools from the JavaScript and React ecosystem, also helps us write more maintainable code that is easier to read.

Static analysis and code consistency

The dynamic and loosely-typed nature of JavaScript makes it especially prone to runtime errors. To help us find these errors before running the app, we use ESlint. ESlint also helps us see dead code and detect problematic patterns that sneak into the codebase. Our configuration is based on the widely used eslint-config-airbnb.

Although ESlint can also check that a codebase adheres to a specific style guideline, we strongly believe that a code style should be enforced by a tool. Instead of debating over coding style, we use Prettier to format our code. It integrates with ESlint, so when hitting save in our editor the code is formatted and statically analyzed.

State management

For state management, we enjoy the simplicity and testability of Redux. We use the redux-persist middleware to read and write parts of our Redux store to disk.

Static type checking

We started rebuilding the application in React Native without types. But as the application grew, it became clear that a static type checking tool like Flow or TypeScript would help us refactor and discover bugs. The more of the codebase we covered with types, the more bugs we uncovered.

TypeScript by Microsoft and Flow by Facebook are similar tools, providing gradual static typing capabilities, a similar syntax, and widespread usage.

For React Native, Flow was a natural choice. It integrates nicely with the build tool, and most third-party libraries already provide Flow types.

A type checker is not a silver bullet, though. The learning curve is steep, and you find yourself fighting the type system. But we are happy that a lot of development is happening in this area. One of the most promising options for the future is Reason (also by Facebook), a type-safe language build on top of OCaml which compiles to very readable JavaScript.

Storybook as a productivity booster

Storybook is a UI development environment for your UI components. With it, you can visualize different states of your UI components and develop them interactively.

If we were to dream up a productive setup for developing UI components and screens, it would:

• Work on components and screens in isolation without starting the entire application
• Be able to describe and quickly switch between components and screens in different states
• Support hot reloading when styles and markup changes
• Have multiple simulators and cross-platform devices connected and see them all update when updating the code

We are happy to see that Storybook delivers all of these. It is a major productivity booster when developing UIs.

Automated testing

For unit and integration testing, we are using Jest — another great open source tool by Facebook. It provides a testing framework with excellent watch mode, coverage support, fairly simple mocking and swift feedback when writing tests. As it runs in Node, you mock out all native components (though it requires some setup).

We have experimented with Appium and Amazon Device Farm for cross-platform UI automation tests. But currently, we’re focusing on a solid and fast unit testing setup that helps us catch bugs and documents the expected behavior of our code.

Editor support

Everyone on the team uses their preferred editor, whether it be Visual Studio Code, Atom, or IntelliJ IDEA. To have a good and consistent development experience we ensure that all of our editors:

• Show ESlint errors
• Call eslint — fix on file save (we never do manual formatting, we have Prettier for that)
• Understand Flow declarations, so we get autocompletion and type errors in the editor

What’s next?

While we are quite happy with the current setup, there is room still for improvement. One thing we want to do is to have a big set of UI tests. We’re not entirely sure yet what the best option for that would be. But in general, we now have a solid foundation on which we can build more features, and we have great checks in place that make sure our code adheres to best practices and our internal style. The development cycle is also a lot faster because of the unit tests and Storybook.

There is one more thing we feel is important when converting to React Native, and that is native modules and UI components. We will cover that in our next blog post.

Converting an app to React Native — How to get started was originally published in LEO Innovation Lab on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been dreaming about type safety and editor autocompletion when using CSS Modules. There are a few TypeScript tools for this (see this and this), but I didn’t find any solid tools for Flow.

TL;DR I’ve made some new tools, and when trying them on a codebase I’m working on, Flow found a lot of dead code (and potential bugs)… 😬

The problems

It is quite easy to misspell a class name or forget to update .js consumers after removing a class in a .css file. As an example, the class foo might not be defined in Button.css:

/* @flow */
import styles from './Button.css';

const Button = () => <button className={styles.foo} />;

Solutions

To teach Flow about CSS Modules file, we can create a definition file Button.css.flow containing the class names exposed by Button.css. By doing so we can get:

• static type checks showing usage of non existing classes
• editor autocompletion of CSS classes (for editors supporting Flow)

To generate these .flow files I was thinking of two use cases. One using a simple CLI and another using webpack.

Solution: CLI

css-modules-flow-types-cli is a CLI that quickly generates .flow files.

Let us install it:

npm install --save-dev css-modules-flow-types-cli

# Or
yarn install -D css-modules-flow-types-cli

And then just run the CLI on your source directory:

css-modules-flow-types src

I recommend using the CLI on your CI system (like Travis or Circle) to ensure that all .flow files are up-to-date before running Flow. This will catch potential styling errors before deploying.

Another use case is quick feedback loop when developing and changing CSS Modules files. The CLI includes a watch mode for this, but I myself would like to avoid having yet another tool that needs to be running while developing. As a lot of people already have webpack running, I did a small loader consuming the tokens from style-loader.

Solution: webpack loader

css-modules-flow-types-loader is a webpack loader keeping .flow files updated by consuming the tokens from style-loader. I recommend using this when developing as part of a webpack-dev-server setup. It will give a small slowdown, as the loader potentially needs write a lot of files.

To get started:

npm install --save-dev css-modules-flow-types-loader

Then update your webpack config:

{
  test: /\.css$/,  // or the file format you are using
  use: [
    'style-loader',
    'css-modules-flow-types-loader',  // right after style-loader
    // Other loaders like css-loader after this:
    ...
  ]
}

And then sit back and enjoy CSS Modules being type checked by Flow. 🍺

Please let me know what you think… And give a little ⭐️ over at github.

skovhus/css-modules-flow-types

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

Type safe CSS Modules with Flow was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

If React were Facebook’s gateway drug to declarative and composable UI, React PropTypes introduced a lot of people to type checking.

PropTypes documents a given component’s props and gives runtime validation of props during development. I find them really helpful, but they also have several shortcomings. Most notably we should aim to catch errors before opening our browser. Say hello to static type checking.

To statically type-check an application, you can use JavaScript extensions like Flow or TypeScript. In this blog post I’m focusing on Flow, but the same approach can be applied to TypeScript.

No doubt: Static type checking (using Flow or TypeScript) at build time is vastly superior runtime validation.

If you are new to Flow, the new documentation is really good. After setting up Flow you can now start type annotating your components state and props. For a simple component it might look like:

So far so good. But transitioning an existing codebase to use Flow annotations instead of PropTypes can be tedious... However this is a perfect task for a codemod!

Time to mod the code

To automate the conversion of React PropTypes to Flow annotations, we are using another tool popularized by Facebook: jscodeshift (JavaScript codemod toolkit).

If the concept of automated refactoring with codemods is new to you, I’ll shamelessly self promote a meetup talk I recently did:

Enough talk. Time to get rid of the PropTypes! Turns out Billy Vong already did a lot of the hard work for us with codemod-proptypes-to-flow.

billyvg/codemod-proptypes-to-flow

So to automatically convert all components in a folder my-components:

• git clone https://github.com/billyvg/codemod-proptypes-to-flow
• jscodeshift -t codemod-proptypes-to-flow/src/index.js my-components
• Look no PropTypes! (Although createClass, imported and custom PropTypes validators are not supported — yet!)

I’ve successfully used this codemod for multiple projects, and it eased the transition remarkably. Now Flow starts finding errors while you write the code instead of when the code is executed! 🍷 🙌🏻

Notice that there are cases where you want to keep your PropTypes (possible alongside Flow annotations):

• PropTypes in library code can help consumers and document an interface
• If you have no automated tests validating your flow definitions of any external resources (like an API), PropTypes can be really helpful. For this I would recommend using babel-plugin-flow-react-proptypes to add PropTypes at build time
• PropTypes are still great for learning material on React (no need to burden new people with Flow/TypeScript)
• PropTypes can be more flexible than what the Flow type-checker currently supports (e.g. validating a number is in a particular range)

(Thanks to Maciek Pekala and Mads Hartmann for reviewing this post)

React PropTypes to Flow codemod was originally published in Netscape on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 2 of “Toward a maintainable front-end” series. Part 1 is here.

For many years, issuu’s engineering group was organized around component teams. Our late great Team Monster handled the front-end code and the rest of the teams provided APIs and back-end infrastructure.

As we scaled the engineering organization, this classical split became counterproductive. A lot of cross team coordination was required for releases. Business logic and remappings were spread across multiple layers of the application. Dependencies and ownership of features were unclear. Finally, the Monsters had way too much on their plate!

So in 2013, several of our teams transitioned from component teams to customer-centric, cross-component feature teams. One focused on the end-to-end reading experience, another team handled all publisher-related features and so on. Next was taking ownership of the entire code stack, from database to front end. Our back-end system quickly transitioned into smaller microservices written in technologies the team deemed best (OCaml, Erlang, Python, node.js, MySQL, Postgres, Redis, AMQP).

Until recently, though, the front-end code running issuu.com was still one big, monolithic codebase. It had turned into such an unmanageable beast that we were all fighting with each other to get features out to users. We identified several blockers:

• With one big pile of code, team ownership and dependencies were unclear;
• we stepped on other people’s toes all the time;
• and as a result the rate of feature deployment decreased. (Oh yes, big-bang releases!)

Besides, we had a major technology lockdown due to a very customized build system. This alone was around 3.000 lines of code, including a home-built Browserify and a lot of magical grunt tasks. As nobody dared to touch that part of the system, we were locked to our own require system, ES5 and Ruby SASS. Also the size of the codebase made builds painfully slow.

It was time to pour into our front-end code the same poison we gave our back-end systems, splitting it all apart into maintainable chunks. Our vision was to make each feature team own, build and deploy its front-end code autonomously – and to make things that ought to be trivial actually trivial!

To the lifeboats!

We started by dividing the front-end codebase into four chunks:

• shared serving infrastructure;
• pages;
• widgets;
• and UI components.

The shared serving infrastructure is a thin horizontal node.js application responsible for routing and serving pages. It holds the configuration for which version of a page to be served.

A feature team delivers products consisting of the following:

• pages (node.js handlers, templates and assets like compiled JavaScript/CSS);
• and some widgets (shared functionality used on multiple pages, like a message hub, streams or drag-and-drop functionality to initiate a publication upload).

Our UI component package provides high-level building blocks and styling for the site. It is our shared horizontal toolkit for keeping a consistent look and not reinventing buttons, form elements, modals and colors for each page and widget.

To handle internal code dependencies, we decided to use the same tool we use for all other dependencies in JavaScript: npm. So we set up a private npm repository using the open-source Sinopia tool. When pushing code on master for one of our front-end repositories, our CI server will test and publish a new version of the package to Sinopia.

To release a change to a page, you simply bump the product version in the shared webserver package. The package.json for our webserver looks like this:

{
  "dependencies": {
    "issuu-productA": “1.0.2”,
    "issuu-productB": “2.0.292”,
    "issuu-productC": “1.0.x”
    …
  }
}

To follow the principle of least astonishment, most of our top-level packages are locked to a specific version of a page, but some packages like Marketing pages will always take the newest version.

How did we migrate to this? After the initial serving infrastructure was ready, we made it up to the feature teams to take ownership of the old mothership codebase and turn it into a product/widget in the new world. Of course, the mothership still holds tight to some old products we never touch and that no team really owns. In the end, it is all about ownership.

After a few months, the old monolithic codebase is split into 45 packages. Oh, 46 now!

A new hope

Instead of the old, frustrating technology lockdown, over the last six months a lot our feature teams have been innovating on the tools they have for building products. Most of the teams use the following:

• Makefiles for orchestrating everything why reinvent the wheel?;
• Webpack for building assets;
• Babel for allowing us to write slick ES6 code that transpiles to ES5;
• a move to React and Redux;
• strict linting using ESLint;
• and more as we go. Nothing stops a team from trying out TypeScript, CSS Modules, Elm, etc.

We are now able to work on isolated, vertical features without worrying about stepping on toes. Deployment time went from 30 minutes to just a few minutes, as we are rebuilding only what have changed and not the entire codebase. We went from a few weekly deploys to multiple times daily — continuous delivery for the win!

The one constraint for a product is that it can be served by node. Heck, we are already talking about breaking the horizontal node server into smaller servers and letting the top-level routing logic reside in a proxy configuration. Ultimate autonomy to the team.

A note on sharing code, and lessons learned

We want to make fast iterations on products and sustain team autonomy. Our new system is optimized for changes in issuu’s vertical products, not for making horizontal changes easier. It highlights clearly that we still have a lot of horizontal dependencies.

In our old mothership repository, it is very easy to make a horizontal change and share a lot of code between products. One thing the code split has highlighted is that developers intuitively love to share code. Instead of copying and pasting small pieces, we would rather generalize it into shared components. This comes at a high cost: You now have yet another dependency, and *dependencies slow you down.* You lose autonomy and make simple things complex.

On the scale of a single product or feature, team code reuse and the principle of DRY still make sense. But one should be careful about sharing code between products as shared dependencies are cumbersome. Of course, you never want to duplicate business logic, but I would much rather duplicate simple components than share them between verticals.

Still, redundancy sucks, right? I’m going to end with a quote from the excellent post by Yossi Kreinin:

Redundancy always means duplicated efforts, and sometimes interoperability problems. But dependencies are worse. The only reasonable thing to depend on is a full-fledged, real module, not an amorphous bunch of code. You can usually look at a problem and guess quite well if its solution has good chances to become a real module, with a real owner, with a stable interface making all its users happy enough. If these chances are low, pick redundancy. And estimate those chances conservatively, too. Redundancy is bad, but dependencies can actually paralyze you. I say kill dependencies first.