Artem Sapegin’s Blog

Structuring React and Redux Applications

There’s no idiomatic way to structure Redux applications yet. And I believe there’s no The Only True Project Structure but I’ll describe what works for me.

General structure

There are two approaches for grouping files:

  • By type: one folder for components, one for reducers, one for actions, etc.
  • By feature: all files related to one feature are inside the same folder.

I started from grouping by type. It works for a small application but to add a new feature you have to create: reducers/myfeature.js, selectors/myfeature.js, components/MyFeature.js and a few more. It’s annoying and difficult to explain to new team members.

Now I group files by view or page: dashboard, users, etc.

Here are main folders I have in my application:

  • app: Redux store configuration and root reducer, React Router routes, application root components with connections to Redux, Redux DevTools, React Router and React Intl.
  • components: shared components.
  • models: Immutable.js records.
  • util: any shared non-React JavaScript code.
  • features.

Read more…

Egghead Courses Review: React, Reactive Programming & Open Source

Most courses are good but very basic. They are very good to get to know a new technology. Only the Redux course I can recommend to any developer: no matter if you just starting with Redux, already fluent or not going to use it at all.

Some courses are free but most of them are available only by subscription. With a subscription you have access to all Egghead’s courses and a few useful features: adjusting playback speed, skip 25 seconds button, downloading HD videos. In the past they had a $20 monthly subscription but now they have only $200 yearly. And I can’t recommend it anymore: one month is enough to watch most of the good courses.

Getting Started with Redux by Dan Abramov (free)

Really great course. Teaches you many other things besides Redux: like ES6 and just how to write good code. Watch in any case.

Building React Applications with Idiomatic Redux by Dan Abramov (free)

Not as universal as the first one but also very good. Watch if you’re already using Redux.

How to Contribute to an Open Source Project on GitHub by Kent C. Dodds (free)

Very short and good course. Watch before you send your first 20 pull requests.

If you want more pull request to your open source projects, you can try to add a badge with the link to this course.

How to Write an Open Source JavaScript Library by Kent C. Dodds (free)

Great course for beginners but I’ve learned something from it myself. Watch before you make your first 10 open source projects.

One thing I don’t like about this course: Kent suggests semantic-release to automate releases. I wouldn’t recommend it because it makes project maintainer life harder: it doesn’t allow you to group breaking changes and write human readable change logs. And I think it’s too opinionated for such course.

Learn how to use Immutable.js by J.S. Leonard

Mostly just retelling of the docs (which are hard to read). Watch if you don’t know much about Immutable.js.

React Testing Cookbook by Trevor Miller

Short and very basic. Covers shallow rendering, expect-jsx and Redux.

React: Flux Architecture (ES6) by Joe Maddalone

Watch the first Redux course instead. Watch this course only if you really have to use the vanilla Flux.

Reduce Data with Javascript Array#reduce by Joe Maddalone

I enjoyed watching this short course. Watch if you can’t use the reduce function with your eyes closed.

Getting Started with React Router by Joe Maddalone

Very basic and very short course. If you’re already using React Router in a project you most probably won’t learn anything new.

React Fundamentals by Joe Maddalone

Watch the free React.js Fundamentals course by Tyler McGinnis instead (yeah, the name is the same but it’s a different course by a different author).

Introduction to Reactive Programming by André Staltz

Looks like the example project is not very good to learn reactive programming. The resulting code looks for me like a typical jQuery soup. Watch the next course instead.

Step-by-Step Async JavaScript with RxJS by John Lindquist

This course is much better than the previous one. But it’s still not very useful if you want to understand when to use reactive programming in real projects. Watch if you want to see how reactive programming with RxJS looks like.

React Native Fundamentals by Tyler McGinnis

I didn’t know much about React Native and wanted to know how it looks. This course was good for that. Through the course the author develops an app for displaying GitHub profiles so in the end you have an idea of how to make an app with React Native.

Why I Wrote Another Static Site Generator

For many years I was struggling every time I was using a someone else’s engine to build one of my sites. I’ve tried WordPress, Koken, Aegea, Django, DocPad and Hexo. Now all my personal sites (this blog, homepage and photo portfolio) work on my own static site generator — Fledermaus — and I’ve never been more happy.

It’s not my first engine:

  • fjSiter, 2002: PHP, MySQL, XSLT based content management system.
  • Custom PHP based generator for my photo gallery, 2008.
  • Sweet, 2011: Node.js based static site generator.
  • Springhare: Python based gallery engine, unfinished (the project was too big for one developer with limited time).
  • Others that I don’t remember.

Experience with other engines has taught me how an engine shouldn’t be implemented.

Usual site engine is a massive piece of code that’s optimized for a few the most popular use cases. But if you want something else you have to suffer: it’s either too hard or not possible at all. Often you end up with an ugly unstable code that breaks after every engine update.

It’s like in Joe Armstrong’s famous saying about object-oriented programming:

You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

But in that case the banana is half-eaten.

With the Fledermaus I took a different approach. Actually it’s just a collection of useful functions that you can use to write your own static site generator: loading Markdown source files, documents filtering, grouping and sorting, pagination, internationalization, generating HTML pages and RSS, etc.

You can combine them any way you want, add custom processing at any step, generate pages yourself. For example, in my photo gallery I read EXIF meta data from JPEG files and generate pages and albums based on this data.

It’s based on fancy modern things like ES2015, JSX, Markdown and Intl.

And it’s very small and fast:

Engine code
Docpad: 10300 lines (without 6 required plugins)
Hexo: 7800 lines (without 2 required plugins)
Fledermaus: 1300 lines

Blog code
Docpad: 211 lines
Hexo: 361 lines
Fledermaus: 159 lines

Build time
Docpad: 77,49s (version 6.78.4)
Hexo: 4,60s (version 3.1.1)
Fledermaus: 3,80s (version 5.0.1, including Babel transpilation)

It builds my whole photo gallery (2000 HTML pages) in 35 seconds on my 2011 MacBook Pro.

Now I finally can build stuff instead of crutches.

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.


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.


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.


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. Video, slides.

Denis Radin, Liberty Global. Video, slides.

  • 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. Video, 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. Video, slides.

  • “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. Video, 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. Video, 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.


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. 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.

Update. Looks like the search problem is pretty much solved by the new It’s really awesome!

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).


Our view layer is React.


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:


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 allows us to use ES6/JSX syntax (including ES6 modules), import modules from npm and use hot reloading to debug front-end code.


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).


  • 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.


  • 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.


  • 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.