Paying back my Javascript/React knowledge debt

Recently I was suffering from a little bit of work induced burnout and as such I took the opportunity to step back from 12 hours of daily coding to attempt to reduce my knowledge debt and refactor our various products.

At the most basic level this would involve updating and implementing newer/updated versions of the various frameworks that we utilise on both the front and backend of our various products.

I however wanted to delve a little deeper and make sure that our codebases (across various platforms) were written in a clean, commented manner, and that they followed appropriate design patterns and paradigms.

In the process I was made aware of my lack of knowledge of some relatively simple (yet powerful) concepts. I filled in these gaps.

I explored ES6 and current best practices for utilising React. Here are some of the things that I discovered.

Refactoring some aspects of the front end of our web applications was somewhat arduous, and demonstrated that common situation - that whereby after hours of work to the viewing public absolutely nothing has changed.

  • displayName

I saw the displayName property being utilised in an open source project that I was working with. Whilst 'Non-standard' I see no harm in setting this property. It is utilised by browser consoles to display a more informative name for your functions. It can make debugging a little easier.

  • Spread syntax (...)

This syntax is really useful. It allows much simpler usage and manipulation of arrays, including:

  • passing arrays as function parameters
  • more succinct copying and pushing

To read more, take a look here.

  • map

Whilst I was aware of the map function on the Array prototype, I never used it. I found/find that traditional for loops are clear and concise (enough).

In certain situations however map is not appropriate. For example it doesn't allow you to break out of the loop.

Whilst working with React I have had situations whereby I have wanted to inline an array loop, and using map is the logical choice for code readability.

You can specify the this context as the second parameter. It is all really quite simple.

  • reduce

I was not aware of the reduce function on the Array prototype. I discovered it as a result of wanting to flatten an array of arrays. It is simple and powerful.

To read more, take a look here.

  • Hoisting

This is one of those buzzwords utilised in every beginner Javascript book/tutorial. That said I have never attributed a concept which I fully understand and appreciate to its 'term'. It is weird how one just gets things.. understands things, and uses them. Concepts like 'hoisting' are second nature, and are subconsciously understood.

Hoisting refers to the situation whereby a variable declaration is hoisted to the top of its enclosing scope.

The declaration is 'hoisted' but the initialisation is not. See here for more.

  • const, let, and var

const

As outlined on the Mozilla website, "The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable, just that the variable identifier cannot be reassigned."

You must assign it a value when you initialise it as the value can not be changed.

You can however modify object properties, and array values when an object/array respectively is defined as a const.

const protects from reassignment but object properties can still be changed. Use Object.freeze to stop that.

You can have block scoped const definitions.

let and var

Again as outlined by Mozilla, in my opinion the most important difference between let and var is with scoping.

let is scoped to its defining block, whilst var is defined to its enclosing function.

This Stack Overflow answer demonstrates this well.

  • Loop labels

You can name for loops so you can break them by name.

A label allows you to identify a particular loop such that when nested you can break or continue from a specific loop.

This makes your code considerably easier to follow, and comes in handy when you are not using map ;)

React

  • ES6 Syntax

I was aware of ES6 but had not investigated it (until now). With a significant amount on my plate I was of the view that the time investment was not worth it. In hindsight, having now gained a thorough understanding of the new functionality this was foolish. Going forward writing Javascript code (generally) will be significantly easier with the new and powerful functionality provided by ES6.

This post outlines a number of ES6 changes that directly relate to React.

  • Arrow functions

One aspect of the new ES6 syntax which is particularly powerful is arrow functions.

One downside? of moving to ES6 class syntax is that you lose some of the behind the scenes benefits of the createClass syntax such as autobinding of component context.

Implicitly having to set context is a little strange (when you have gotten used to it being done for you), but it is relatively simple to do, and makes your code better - I like to minimise the amount of 'magic' in my code.

  • Stateless functions

As outlined in the docs, stateless functions allow a simpler syntax for defining components which do not need to maintain. For example 'presentational components' (mentioned below).

  • Presentational components

Dan Abramov has written a detailed piece on separation of concerns within React.

I had gotten somewhat complacent in my approach to writing Reactive components. I could write code quickly, but everything knew about everything and as such following the chain up the virtual DOM to discern where/why a particular value was set as it was was becoming somewhat arduous. This would have been much worse had the components in question been more complex.

Refactoring such that a singular container component 'controls' and interacts with the backend has essentially 'contained' my complexity which in fact makes things significantly simpler.

As a result of investigating and implementing these changes I also took the time to investigate..

  • Redux

Redux is a state management system developed by Dan Abramov at Facebook. He has created a 30 part (2 hours) series of screencasts which explain how to get started.

Whilst I have not implemented Redux across our products (for the most part our state requirements are simple enough that it is not currently worth the time investment), I certainly will utilise it in new products.

Its simplicity is incredible.

  • Scaling

During my research I stumbled upon this post about scaling React applications. It mentions generators, and more complex implementations of data fetching alongside Redux. An interesting read, and something I will be looking into further..

It mentions redux-thunk which defines a 'thunk' well - "A thunk is a function that wraps an expression to delay its evaluation.". I mention this because a thunk is another one of those things that I understand and utilise daily yet have never attributed to its associated buzzword. Fun stuff.

Thats it..

Thats it for now. Nothing particularly complex or exciting.. simply an overview of some interesting and useful 'things'. Enjoy !


Thomas Clowes

Thomas Clowes

I am a 28 year old software engineer from the United Kingdom. During the day I build multi platform applications. In my spare time I eat food and run marathons. Sometimes I write angry tweets.