Starting React

I’ve been dabbling with the concept of a remote part-time job to provide a bit of personal funding as our business venture slowly gets off the ground, and this has highlighted the current popularity of React. It’s not like I’ve had my head completely in the sand, but the number of roles requiring a specific JS framework, rather than just JavaScript (plus a framework preference) did surprise me a little.

With all that in mind I decided to take a proper look at React, and compare it to my current front-end framework of choice, Aurelia. The fruits of this exploration are in GitHub and hopefully not too embarrassing :).


There is a continuum in current web libraries between being a full framework, like Angular or Aurelia, and a view library, where non-rendering activities like routing and dependency injection are not included. React sits at the view library end of this spectrum, but with well established and supported choices for the excluded activities. In this respect I’ve found React easier to learn than Aurelia because it enables the ecosystem to be learned step-at-a-time – although it could also be said that significant experience with any of these frameworks would make learning the next easier.

React is strong on conventions, although at times it has felt like these conventions obscure what is going on and make ‘magic happen’, which is not a feeling I enjoy when developing. This is particularly so with react-redux.

It also leans more towards JavaScript’s dynamic typing than a static typing style, emphasized in the event handler example which does this.setState({ [name]: value });. However it also encourages the use of typed systems like TypeScript which requires some trawling through the index.d.ts file to come to grips with.


React is driven by the notion of small and composable components, and it does make creating and working with these very easy. The use of JSX/TSX files allows advanced logic to be mixed with markup giving complete flexibility over the creation of elements. There is a risk to this, which is that a component gets bloated instead of being split into smaller parts, so good code maintenance practices are important.

Styling is fairly flexible, allowing anything from basic CSS use, referenced from the index.html, through to compiled and bundled SCSS using a packing system like webpack.


My basic understanding is that data that is owned by a component goes into this.state and is modified by setState(), while data that is used by a component goes into this.props and is read-only. In a basic scenario (i.e. without Redux) data flows down via properties on this.props, and up via callback methods on this.props. e.g.

// in parent component
private handleChange(data) {
  this.setState({ filtered: data});

render() {
  <Subcomponent all={this.all} onChange={(data) => this.handleChange(data)} />

// in a subcomponent method
this.props.onChange(this.props.all.filter(f => f.something > 0));

This is certainly more laborious than Aurelia’s two-way binding, something React’s documentation acknowledges: “It can sometimes be tedious to use controlled components, because you need to write an event handler for every way your data can change and pipe all of the input state through a React component.” However this approach does make data passing and ownership very explicit and therefore understandable. Going to react-redux changes all this, and that’s something I’ll leave for a future post.

So there you have it – my first couple of days building something with React.