React London Meetup September 2016

Free beer and pizza, developers, and maybe React talks? You’ve come to the right place!
This month’s React London Meetup was held at Skillsmatter, CodeNode, which a great place for like minded developers to socialise, share their ideas and see the latest trends in the React community.

So without further ado, on to the talks!

Keith Woods - Building Maintainable Single Page Applications With React

Keith Woods

YouTube

• Talk is 0:33:32 into the video



• View Slides NPM: esp-js



• @keith_woods



• KeithWoods

Keith Woods works for Adaptive, who are real-time application and infrastructure specialists.

His talk was around patterns that they’ve used to manage complicated state. He also demoed a simple Scrum Task Board using esp-js-react with epics, stories, and tasks.

They’ve used their framework esp-js at Adaptive to avoid creating fat controllers, views and models. esp-js revolves around a model-first development process, which can be used to deterministically update their models.

A React view can be used with the ESP event router, this acts as broker between the model and the view, so anything that wants to publish events can stream updates to the view. This means that the latest version of the model is dispatched to the view or observers in real time. It’s similar to unidirectional data flow that exists in React Flux architectures.

For their team, it also simplifies their codebase by providing these events where certain computations should happen such as working out sums and when/if components should update.

Events can be serialised into an event queue and replayed through the ESP event router to help manage state.

His talk also covered mutable (changing states) and immutable (non changing state). To change an object’s properties in an immutable event-based system, you first have to create a new object and assign it the previous object properties and any new properties you want to set.

Using immutable state makes it easier to track if a component should update, because you can check to see if an object instance is equal to another object instance. Whereas in an OO/mutable model you have to keep track of property value updates to make sure that it’s okay to set your React components shouldComponentUpdate flag.

ESP events can be wired up using the ES7 decorator syntax, which then observe events as they happen. These can be created in a granular fashion and then built up to handle complicated state changes.

There were examples of how you can use esp-js’s built-in React components such as <RouterProvider /> and <SmartComponent /> to configure your application, which creates the router and pass down the props the relevant components/subscribers. ESP also provides an @esp.viewBinding decorator to automatically resolve view bindings for models.

His team have built a real-time FX Reactive Trader Cloud app written in esp-js which is bundled as a client application using openfin and Electron. Traders can use it to buy and sell different currencies and get notifications on prices and transactions. It’s push-based and can be left open all week and will automatically update the app’s base code and prices:

reactive-trader-screencapture

The backend is event-based and works using linked microservices in the cloud.

Graham Mendick - The Navigation router

A photo of Graham Mendick presenting

YouTube

• Talk is 0:33:32 into the video



• JSFiddle NPM: navigation-react



• @grahammendick



• grahammendick

The Navigation router is a new data-first URL router for React. In his presentation, Graham explained what’s wrong with the existing React Router:

“React Router was initially inspired by Ember’s fantastic router. Many thanks to the Ember team.”

He went on to question their reasoning, that if: “React is nothing like Ember, why have they used used this statement?” and that it’s only “fantastic for Ember and not for React”. When parameters change in the Ember’s router it’s passed down into the view, but it doesn’t replace the view.

React router “Displays a view”, “Changes a view”, and “Changes the data”, but there’s nothing new here that you can’t already do in React itself.

Graham’s Navigation router is the opposite and provides new functionality which React and React Router do not provide.

A new StateNavigator can be created and this holds URL parameters that can be used to map/route to a certain state. So when the URL changes it checks to see if the key state.${your-react-render-method}.navigated exists as a function and will then call it. This gives you control on how the route is rendered.

When building hyperlinks the URL is never hard coded, instead a <NavigationLink /> component is imported and given the stateKey you want to navigate to and navigationData that you want to provide to the route.

Default values can be used for your state properties, so that you don’t have to provide it in the URL or <NavigationLink />. State is maintained across the application so you won’t lose user input when navigating.

URLs are automatically generated for states, but can be configured into prettier URLs being any subpath the user requires. So that query strings can be route/subpath parameters.

Alexey Golev - Pros and Cons of Static Typing

A photo of Alexey Golev presenting

YouTube

• Talk is 1:14:39 into the video



• View Slides



• @alexeygolev



• alexeygolev

Alexey argued “Should we use typed language within a dynamic untyped language like JavaScript and do we actually need types?”

As a developer using JavaScript there are a number of typing stages we go through:

Stage 1 - Denial

Types don’t exist in JavaScript, or do they? Under the hood, variables are casted into types and providing types upfront can help us find problems before we even run our code because if we provide an incorrect type our IDEs and compilers will complain.

In JavaScript we can use TDD to assert if variables are a certain type (e.g. assert.isFunction(myVar);), but this seems like a lot of extra work. So we should either use a typed language upfront or use type hinting.

“A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.”

–Benjamin C. Pierce, Types and Programming Languages

Stage 2 - Anger

“GOOD PROGRAMMERS SHOULD NOT NEED TO BE PROTECTED AGAINST THEIR OWN MISTAKES”

– ██████████, Good Programmer

People may disagree about using types in their programming language of choice, saying that it’s too verbose and less flexible and maybe that’s why they are using that language in the first place.

Stage 3 - Bargaining

Using an additional framework or runtime checks can provide some safety nets around typing issues such as:

• TypedJS
• Contracts.coffee/Contracts.js (Inspired by Racket)
• rho-contracts.js
• TreatJS
• PropTypes

In React we tend to use PropTypes to define the type contracts between our components.

Stage 4 - Depression

The depression stems from fatigue and “What am I going to use?”:

• JSig
• Infernu
• TypeScript
• Flow
• Elm, Purescript, >ReasonML, BuckleScript, ghcjs, Idris

There’s also the problem of how long the framework will be around and if it will just disappear.

Looking into how many stars and forks a project has on GitHub can help you decide which one you should use. There are a lot of JavaScript based type system out there, so choosing the right one can be tricky. Looking to some of the larger companies to see who’s using what, can also be an influencing reason.

Alexey did also suggest not to use the any type as it’s pointless!

Stage 5 - Acceptance

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

– Martin Fowler

Using a statically typed system that outputs JavaScript has a lot of advantages and can help you write better error free code.

Are we what you're looking for?* Red Badger is hiring! For details on our tech stack, positions and clients take a look at our Join Us page.

* And vice versa