React

For ‘Non Techies’

React is taking over...

React is everywhere...

● We’ve been using it on every client project during the

last 18 months.

● London React Meetup hosted by Red Badger has

2000+ members.

● 4th most starred JS project of all time on Github

behind Angular, D3 & jQuery

● ‘React is something cool you can use to create UI but

we don’t know why it’s good.’ - Non techie

● ‘A javascript library for building user interfaces. The V in

MVC.‘ - Facebook React Developers

But what is it?

● The best tool developers currently have for

organising the front end code.

BackendPrepares data that should be sent to user and determines what front end code should go with it:

What is the frontend exactly?

User types fortnumandmason.comin web browser, request sent to our server

CLIENT

SERVER

Frontend Adds data to HTML and JavaScript files, sends those files with CSS to the user

Frontend Adds data to HTML and JavaScript files, sends those files with CSS to the user ⬆

React helps us organise and build this

● jQuery

● Backbone, Ember,

Angular and more...

● All provide a solution

● React was easy to pick up

● Promotes idea of breaking

down UI into components

● Big company backing

Not the first solution, probably not last

● A few lines of JavaScript that defines how an element of the page should behave.

● We can position it on the page and style it too..

● Facebook recommend slicing the design into React components

What is a React component?

Business Requirement

“We want to show a number!”

React: Example 1

http://codepen.io/anon/pen/QjzwdE

● Props● Render● Default Values● Validations of prop data types● React forces code structure.

10

Business Requirement

“We want to be able to increase that number!”

React: Example 2

http://codepen.io/anon/pen/epQXZN

● State

Business Requirement

“We want to have re-usable components so that other teams can use what we are building!”

React: Example 3

http://codepen.io/anon/pen/EVOMNg

● Separation of concerns● Re-use

● Clear structure and organisation of UI

● Encourages code re-use

● Fun! (inspired by game programming)

● Lifecycle - you can do stuff before and after a

component appears on the page

● Small components are more testable

● Abstracts some browser differences

● Challenges: A single component is simple but

constructing a large system of components and

co-ordinating their communication is complex

Patterns for managing state still being figured out.

(Arch, Flux, Relay, Redux etc. etc.)

Developer perspective

UX, Design & Dev collaboration

● Lloyds UXD started slicing components at design stage with developers. Worked well.

● Shared terminology, better communication.

● UX/Designers already think this way?

● Brings development process closer to design process?

● Makes the front end easier to understand, debug and iterate on.

● Reduces communication barriers between Design and Development

● Common structure and patterns so developers can take our knowledge with us to old and new projects.

Benefits to clients

Faster Delivery

Higher Quality

Next steps...

● What can we do as Red Badger teams? ○ Regular team huddles during design stages to review Sketch files.○ Break the design down into components.○ Translate them to code.○ Reference them in future designs .

● Remember the only constant is change, who knows what tech will be using in 1 year, we have to continually adapt our process and technology, More communication will help us evolve..

● But right now, it feels like we are in the right place...

Fin.