Modern Web Development with React & Fluxible

Henri Karhatsu / @karhatsu

Who am I?

Software developer / Scrum master / Agilist / CEO / M.Sc. x 2

~15 years of software development, mainly web applications

Year ago no real experience from modern web development

Twitter: @karhatsu

Sanoma Customership

Development project started 11/2014

Fast-forward...

account.sanoma.com

Web technology selection

Initially Angular

Lead UI wanted React

React vs. Angular analysis

Result of this Friday meeting

It's gonna be Angular

Next Monday

We go with React & Fluxible

Feeling matters

For him React felt better, it felt right

(Let's see if he was "right"...)

Development in the beginning

HTML inside Javascript, seriously?

What is the correct way to do thing X in React?

Why does this work only in some cases?

When should we load the data? In what component?

...

After 2-3 months

Productivity, clarity, our way of working

Now

These tools feel (mostly) really good

(Also JSX)

So what feels good?

Case Digitase

Annual closings table

First implementation - jQuery

Main principle

What has changed in state that has to be changed in view?


function afterCellClick(company, field) {
  if (sameFieldCurrentlyOpen()) {
    hideStatusRow(); // HIDE!
  } else {
    showStatusRow(); // SHOW!
  }
}

What is the table state after...

  1. I open unmodifiable field X
  2. I open modifiable field Y
  3. I change Y's status to Done
  4. I get a server error
  5. I open modifiable field Z

???

If the application state is difficult to track in logical level, it is also difficult to implement in the UI level.

It is also really difficult to test.

Second implementation - React

1. Recognize components

AnnualClosingsTable, HeaderRow, EmptyRow, StatusRow, ModifiableField, UnmodifiableField,...

2. Implement components based on properties they get

With the same properties you always get the same view

Another component example

3. Implement top level component with the state

4. Use child components in parent components

5. Update state in user actions

6. Take the top level component into use

(Ruby on Rails example using react-rails gem)

7. Done.

React basic flow

Components have their states

⇓

Components send data to child components as props

⇓

User actions change state

⇓

Everything is rerendered according the latest state

So what feels good in React?

Possible to create simple and reusable components

AlertBox, BackToHomePageLink, DateInputField, SubmitButton,...

"Components are Just State Machines"

"In React, you simply update a component's state, and then render a new UI based on this new state."

(http://facebook.github.io/react/docs/interactivity-and-dynamic-uis.html)

Easy to write clean code

!!! Testability !!!


describe('ModifiableStatusCell', function () {
  describe('when annual closing report is not sent', function () {
    it('renders empty cell');
  });
  
  describe('when annual closing report is sent', function () {
    it('renders field status');
    
    describe('and cell is clicked', function () {
      it('invokes openFieldWrapper callback function');
    });
  });
});

How about performance?

If React always rerenders the whole DOM..?

Isn't that really slow..?

Virtual DOM

React maintains a fast in-memory representation of the DOM. React can compute the fastest way to update the browser after the virtual DOM has changed.

https://facebook.github.io/react/docs/working-with-the-browser.html

Virtual DOM

React components are declarative

Virtual DOM is imperative (towards actual DOM)

How about Fluxible?

Flux architecture

Complements React's view components with unidirectional data flow

Flux architecture

Complements React's view components with unidirectional data flow

React & Flux

Predictable data with Flux

Predictable UI with React

fluxible.io

Fluxible component types

Stores

Store the application data, listen events for data changes

(React) Components

UI using the data in the stores

Actions

Fetch and update data, invoke events for stores

Services

CRUD operations on server-side (NodeJS)

Good parts in Fluxible

  • Plain React isn't probably enough in big applications
  • Clear responsibilities inside of the application
  • Isomorphic — server-side rendering can speed up the application
  • Takes care that unidirectional data flow is not broken (finish rendering before next action can start)

Bad parts in Fluxible

Sometimes feels boilerplate

Not much community support

One reminder

Do not forget the high level tests (we use Robot Framework).

Was he right?

Yes. Feeling matters.

Next time I would definitely choose React myself.

Thank you!

These slides are available:
www.karhatsu.com/capgemini