Artem Sapegin’s Blog

React Amsterdam 2016

React Amsterdam is the first conference about React in Amsterdam, Netherlands.

My friends and speakers at React Amsterdam 2016

The conference day started from a personal transport disaster. My hotel, that was booked by my employer’s travel agency, was in very inconvenient location in 15 minutes by bus from the Schiphol airport. There’s just one bus route that goes from the airport and on weekends it doesn’t work: you have to change to another bus. And my bus didn’t come in the morning so I had to walk two kilometers for another station. Then in the airport I found out that there was no train to the city on this weekend because of some maintenance work and I had to take a temporary bus. So I spent 2,5 hours to get to the conference venue.

Venue

The conference was at the Pllek that located at NDSM Wharf, a former ship wharf on a IJ river bank, now a hipster place. It’s in 10 minutes by a free ferry from the Amsterdam Central Station.

Pllek is a cool and very authentic place with a nice view but it was a bit chilly because it’s close to the water.

Conference

The conference was very well organized, all talks were in time. The food was strange but it’s the Netherlands after all. Actually that mix of gyoza and varenyky was nice. The only bad thing was terrible chairs.

I think 30-minute talks are the best. Speakers don’t have time to be too boring.

There should be a tool to preview how your slides will look on a projector: often the contrast was too low.

Unfortunately I haven’t won a cool t-shirt. Maybe next year.

Talks

Migrating Safely to React

Jamis Charles, PayPal. Video, slides.

A talk about migrating PayPal from Backbone to React.

  • Start from one small feature, then replace its siblings, then replace its parent.
  • Optimize for feature change.
  • Use as much vanilla JavaScript as possible.
  • We will have to move away from React one day.
  • Solve real problems.

Building Loveable UIs

Henrique Alves, DADI+. Video, slides.

  • React is a library for building ambitious user interfaces.
  • Design components not pages.
  • Good component names: <Card />, <Headline />, <Headline level={1} />, <Link />.
  • Bad component names: <ImageCard />, <StoryTitle />, <MasterHeadline />, <StoryLink />.
  • Container and presentational components.
  • Animation improve usability, feels natural, give feedback.

JavaScript Style Sheets

Oleg Slobodskoi, Chatgrape. Video, slides.

A talk about JSS and problems of CSS by the JSS author. I still think that CSS Modules are more convenient but the talk was very interesting.

  • React for components, CSS for documents.
  • Problems with CSS: global namespace, dependencies, dead code elimination, minification, sharing constants, non-deterministic resolution, isolation.
  • Inline styles solves most of this problems by they don’t support @media, @keyframes, etc. and they are slow.
  • JSS generates real CSS.
  • JSS itself doesn’t depend on React.
  • Don’t be religious. Keep an open mind. Use tools that solve your problems!

Mastering Server-rendered Apps

Sven Anders Robbestad, Inmeta Consulting. Video, slides.

Why and how to user server rendering with React.

  • Isomorphic → universal → shared?
  • Page load is critical: every delay make users go away.
  • JavaScript can be slow because of old hardware or slow connection.
  • JavaScript can be disabled by NoScript or AdBlock.
  • Server rendering makes: Google happy, slow computers happy, smart phones happy, NoScript happy.
  • ReactDOMServer.renderToString pros: faster render on the client, code reuse, works without JavaScript on the client.
  • Cons: complicated server code, relies on a fetch method before render, relatively slow.
  • react-dom-stream: sends the first byte much faster than renderToString — better perceived performance.

React Native Architecture Overview

Tadeu Zagallo, Facebook. Video, slides.

I’d prefer a simpler overview, looks like I’m not a target audience for this talk.

  • No web view, no HTML, no CSS. It’s only JavaScript.
  • React Native uses lots of clever techniques.

Building Reactive GraphQL Apps with Apollo

Martijn Walraven, Meteor. Video, slides.

Apollo is an interesting project, awesome slides.

  • Apollo stack is completely separated from Meteor.
  • GraphQL with any backend, any client, any language.
  • They are trying to improve GraphQL developer experience.
  • Apollo, the data stack for modern apps.

React for Game Development

Johannes Stein, Toptal. Video, slides.

An unusual but interesting talk about using making games with React.

  • Use the tools you’re most familiar with. If that’s React write games in React.
  • Many things in game development are easy with React.
  • Almost 100% code reuse across platforms in React Native because native components are not used.

React Component Library and React WebGL in Liberty Global

Two lightning talks.

Robert Haritonov, Liberty Global. Slides.

Denis Radin, Liberty Global.

  • Abstracting your component rendering lets you render your app in any environment.
  • WebGL instead of DOM because DOM requires too much memory and slower.

Testing React Applications

Jack Franklin, Pusher. Slides.

A good introduction to testing in React.

  • Most of your logic should exist outside of your components.
  • Plain old JavaScript functions are easy to test.
  • Never reach into a component to get or set state.
  • Use Enzyme instead of React TestUtils.
  • Blog post: Testing React Applications.

Introducing and Implementing React at Coolblue

Paul van Dam, Coolblue.

  • “The biggest advantage of using React is the refactorability. It’s easy to refactor and iterate on.” Leland Richardson.

Transparent Reactive Programming and Mutable Data Structures

Michel Weststrate. Slides.

Redux fatigue talk about the MobX.

  • Redux: simple and elegant concept but lots of new things to learn.
  • State should be minimally defined:

    • no caching,
    • no data duplication,
    • no cascading state changes,
    • don’t worry about how the app should react to state.
  • Everything should be derived:

    • automatically,
    • define derivations and reactions,
    • MobX ensures efficiency and consistency.
  • MobX is fast:

    • only track data which is accessed in last render,
    • minimizes amount of computations,
    • PureRenderMixin
  • MobX is scalable:

    • minimal state,
    • graphs: natural mental model,
    • simple code,
    • architectural freedom,
    • third party friendly.

Solving a Tooling Problem for React Native

Alexey Kureev, Mike Grabowski. Slides.

Talk about rnpm, package manager for React Native. I’m not very interested in the subject but the guys were very well prepared.

  • React Native modules contains not only JavaScript but also platform code and assets.
  • rnpm will be part of React Native soon.

The React Native Playground

Joshua Sierles. Video, slides.

Talk about React Native Playground. Lots of wisdom in this talk even if you’re not interested in React Native.

  • React Native docs will have a playground for each component.

More

Front-end Development Mail Lists

I like mail lists. Someone is working hard so you have to choose one or two best articles out of just 20 instead of 100.

I read these mail lists:

But there are more that could interest you:

What mail lists are you reading?

On Discoverability of JavaScript Packages

I really like the idea of extracting tiny tasks to separate libraries like David Clark suggests or like master of one-line modules Sindre Sorhus do.

But as user of these small libraries I always struggle with finding the right packages:

  1. npm has almost 250 000 packages and most of them are bad: no tests, no license, no docs, readme in Chinese, even no code sometimes.
  2. Many packages do the same thing and even have almost identical code.
  3. Many packages were abandoned: no updates, author doesn’t use them either.
  4. People still publish their packages on Bower only.
  5. Sometimes it’s hard to understand what to search: what the right thing to outsource is and what could possibly have been done before.

Juho Vepsäläinen has a list of npm search tools but they don’t solve the problem.

This is still an unsolved question for me and I hope we’ll see more sophisticated search tools that will consider many parameters to rank search results: npm installs in the last month, GitHub stars, latest release date, opened issues, test coverage, etc.

JS.coach is very close to that but they only have modules for React, Webpack, Babel, etc.

And I believe it will decrease the number of almost identical libraries because authors will be able to easily find what’s already available.

Don’t Touch jQuery

Most of 2015 front-end developers spent arguing about the best Flux implementation and whether we need jQuery or not.

Leave jQuery alone. Rewriting your project not to use jQuery won’t solve any real problem.

There are only two valid reasons to tear out jQuery from existing project:

  1. You are bored. Absolutely valid reason but if you’re bored at work you’d better spend your time updating your CV.
  2. You are making a library. jQuery is not a default-library-for-every-project anymore so avoiding it in your library will increase the number of potential users.

Other case is starting a new project. Maybe it’s the right time not to use jQuery. For example there’s no need for it if you’re using React.

React and Redux Single Page Applications Resources

Here is a list of the best articles, books and talks about the libraries and tools we use at the Here product tools team.

You can start from a very good introduction to modern front-end tooling.

ECMAScript 6

Thanks to Babel we can write in ES6 (official name is ECMAScript 2015).

React

Our view layer is React.

Redux

Redux is an app state container. It means that we store the whole application state (data from server and UI state) in a single immutable tree.

Redux was inspired by the original Facebook’s Flux architecture:

Immutable.js

Redux requires that all the data in the store should be immutable. Immutable.js makes work with immutable data structures easier and (potentially) faster.

CSS Modules

CSS modules are like BEM but they provide real class names uniqueness. And you don’t need to write long class names manually. We use CSS modules with Sass and Autoprefixer.

Webpack

Webpack allows us to use ES6/JSX syntax (including ES6 modules), import modules from npm and use hot reloading to debug front-end code.

Testing

To test React components we use Mocha, Chai and React’s shallow rendering.

And a couple of libraries to make work with shallow rendering easier:

Other Useful Libraries

Unfortunately, I haven’t found any good articles about these libraries.

Developer Tools

These tools are as useful as all the resources mentioned above.


Let me know if I’ve missed something, I highly appreciate any additions to this list.

P. S. Check out my latest open source project: React Styleguidist, a component style guide generator with a hot reload dev server.

Importance of the developer experience in the modern front-end

In the past front-end developer could spend years mastering the same set of tools. Now we don’t have this luxury. We have to adapt to constantly changing ecosystem. We’ve replaced Grunt with Gulp, JSHint with ESLint, Bower with npm and everything with React.

It requires us to develop new skills:

  • monitor new tools and techniques;
  • quickly decide what to learn and what to use;
  • debug frameworks and libraries.

Only last month gave us Babel 6, React Router 1.0 and React 0.14 (a bit earlier) as well as betas of React Intl 2.0 and Webpack 2. All with breaking changes.

It makes developer experience much more important than ever. In the past few months I spent many hours debugging strange issues with Webpack, Babel and other libraries. I believe that we can do better.

What we, as tools developers, can do

Improve documentation quality

  • More examples.
  • Get started guide for beginners.
  • Starter kits and boilerplates.

Good: Redux. Documentation that worth publishing as a book, a huge number of starter kits and example applications by the community.

Bad: Immutable.js, Webpack. Almost never helps.

Describe breaking changes and how to upgrade

Good: Rackt projects like React Router or Redux. Detailed descriptions of breaking changes and upgrade instructions.

Bad: almost any Gulp plugin. No changelogs at all.

Improve error handling

Good: React. Lots of checks and meaningful warnings in the development mode. Elm. They are trying to be really useful.

Bad: almost everything else.

Follow semver

Use semantic versioning to notify users about breaking changes. They shouldn’t be afraid that updating to a new patch or minor version breaks their code.

A few notes about web developer’s interviews

Some unorganized tips from current me to last year’s me when I started to look for a job in Europe (I’m from Russia).

Preparation

  • Update your CV and put you LinkedIn profile in order.
  • Write down what you were doing at your last few jobs. Read it aloud several times before the interview if it isn’t in your native language (I didn’t do that but after the eighth or so interview I realized that I should have done it).
  • Look at the company site, find out what technologies they use (if possible); google their tech blog, employees’ blogs and twitters.
  • Inquire about salary range in the city where the company is located. It’d be the best to talk to someone who already lives there. Define an appropriate amount for you and be confident in it.

Think about the answers to the questions like:

  • Why do you want to work for the company?
  • Why do you want to leave your current position?
  • What is the most difficult task you ever encountered?
  • What is the most interesting task or project?
  • How would you describe a perfect team or work environment?

Cover letter

Most likely your cover letter is the first (and often the only) thing that your future employer will read about you. It should show that you (and why you) are a good fit for the position.

I usually read a vacancy and describe my experience with each requirement. If I don’t know something then I say so in my cover letter. If I have some related experience (for example they ask about Ruby on Rails but I have experience with Django) then I write about it.

Correspondence with IT HRs, and especially with developers, is usually quite informal. But it doesn’t mean that you can forget about grammar and politeness. And remember that your email will be read by developers and HRs: they all should be able to understand it.

Coding assignment

Treat coding assignments as a real and useful experience. It would be more useful for you, and at the same time your future employer will see that you’re not only able to stick together jQuery plugins but to write serious maintainable code.

I always try to take something for myself from each coding assignment: try out new tools and so on. Sometimes it significantly increases the time I spend on an assignment.

For example I learned React doing some coding assignments: first, second.

Interview

  • For Skype interviews: dress up, it could be a video call.
  • Don’t be afraid to say “I don’t know” — you can’t know everything. You can answer: “I don’t know exactly but it probably goes something like this”.

Be prepared to write code in all possible ways:

  • on a piece of paper;
  • on a whiteboard;
  • in Skype window (hi-tech version of a piece of paper);
  • by sharing your screen via Skype (or they will provide access to their computer);
  • in some online editor with synchronization.

For sure they will show you snippets of code on pieces of paper and ask the result of executing them. Or they will ask you to fix a mistake, or change code to get a different result.

What to read

But, please, don’t use all that new trickery you’ve learned in real code. We write code for other people and making your code more cowboyish won’t make them happy.

Links

  • Grammarly — find mistakes in your English texts.
  • Canned Emails — prewritten emails for any occasion.
  • Codewars — small tasks for programmers.

Attend an interview

I believe that attending interview is useful even if you don’t plan to change jobs. It allows you to look at your experience from another perspective, find out your weak spots, and understand what to improve to become a better developer.

Loading framework’s plugins with RequireJS

In big project, you often use framework extensions or plugins: things that extend your framework’s namespace but do not export any modules themselves. For example I use Backbone and React with Backbone.localStorage, react.backbone and my own React mixins.

I’m trying to find the best way to include such modules with RequireJS. Most of them can be used for polyfills too.

Almighty copypasta

Just require everything in all modules.

// mymodule.js
define(['backbone', 'react', 'backboneLocalStorage', 'reactBackbone', 'util/react-extras'], function(Backbone, React) {
    …
});

Pros:

  • None.

Cons:

  • Code repetition.
  • Very hard to maintain.

Main module

Require everything in the main module.

// main.js
require(['router', 'backbone', 'backboneLocalStorage', 'reactBackbone', 'util/react-extras'], function(Router, Backbone) {
    …
});

Pros:

  • Clean modules.
  • All extensions in (almost) one place.

Cons:

  • Difficult to test (tests don’t include main.js), so you need to require these modules for tests differently.

Bootstrap module

Put all the extensions in a separate module and require it from your main module and from tests.

// main.js
require(['bootstrap', 'router', 'backbone'], function(_, Router, Backbone) {
    …
});

// bootstrap.js
define([
    'backbone',
    'react',
    'backboneLocalStorage',
    'reactBackbone',
    'util/react-extras'
]);

Pros:

  • All extensions in one place.
  • Clean modules.

Cons:

  • You need to require bootstrap from your main module and from every test.

RequireJS bundles

Bundle is a special module, which you create with the RequieJS optimizer. Any time you require one of the modules inside the bundle RequireJS will load the bundle instead.

// config.js
require.config({
    bundles: {
        'backbone-bundle': ['backbone', 'backboneLocalStorage'],
        'react-bundle': ['react', 'reactBackbone', 'util/react-extras']
    }
    …
});

(I haven’t try this method myself because I think it’s overcomplicated but here’s a good article on how to make and use bundles.)

Pros:

  • Clean modules.
  • No need to do anything special for tests.

Cons:

  • You need to create and maintain bundles.

Wrappers

Create a separate module that requires an original framework with all needed extensions and returns framework back. Do it for all your frameworks that you want to extend.

// config.js
require.config({
    paths: {
        // Rename original framework
        reactOriginal: 'bower_components/react…',
        // require('react') will load our wrapper module
        react: 'react-with-extras'
    }
    …
});

// react-with-extras.js
define(['reactOriginal', 'util/react-extras'], function(React) {
    return React;
});

Pros:

  • Clean modules.
  • No need to do anything special for tests.

Cons:

  • A bit complicated.

Conclusion

I don’t like any of these techniques very much and I hope I’ve just missed the best one. Tell me if you know it.

Going wavy

Often when I have something to get done, I can’t get myself started for a few days. Even if the week before I was very productive.

I used to get upset about it, but then I realized that such a wave pattern is perfectly normal.

When you do different things: pet projects, open source, freelance and non-programming-hobbies; life became richer. I have noticed that drops in some areas are followed by rises in other areas. If I decide to work on a freelance project but feel that I need to edit photos then I’ll edit photos. I know I’ll be back to freelance soon. (Indeed it limits projects I can work on but the most interesting ones remain.)

Good example of this is GitHub profile: you can see a rise, a drop and the beginning of a new rise:

My GitHub profile

How to show GUI dialog window from shell script on a Mac

When you run a shell script from a GUI app (from Alfred workflow, for example) you want to show an error and ask questions via GUI too. You can do it with AppleScript.

Show error message:

#!/usr/bin/env bash

# error "Message"
function error() {
  osascript <<EOT
    tell app "System Events"
      display dialog "$1" buttons {"OK"} default button 1 with icon caution with title "$(basename $0)"
      return  -- Suppress result
    end tell
EOT
}

error "Not enough cheese!"

(You can use note or stop instead of caution to show a different icon.)

Ask question:

#!/usr/bin/env bash

# prompt "Question" "Default value"
function prompt() {
  osascript <<EOT
    tell app "System Events"
      text returned of (display dialog "$1" default answer "$2" buttons {"OK"} default button 1 with title "$(basename $0)")
    end tell
EOT
}

value="$(prompt 'Enter:' '42')"

Or you can just download dlg-error and dlg-prompt and put them somewhere in $PATH:

#!/usr/bin/env bash

dlg-error "Not enough cheese!"
value="$(dlg-prompt 'Enter:' '42')"

P. S. You can show notifications in the Notification Center using terminal-notifier.