Great beer, pizza and speakers can only mean one thing, another React London Meetup! This month we had three awesome speakers and the sweltering hot weather that can only be "enjoyed" once or twice a year in London.
Jonny gave an excellently executed demo of a counter app with a twist - an extra requirement that if a user selects add five times the app will have a side effect.
The Counter App was composed of:
- View - a React Component that has two buttons, add and subtract, that when clicked dispatch an action to a reducer
- Redux root store - the app's root atom state management. When actions are dispatched they are consumed by the related reducer which updates state, triggering a re-render of the view
- Redux Middleware - sits between the view layer and the reducers and intercepts actions before they hit the store. Once they've done their bit, they then pass the action object onto the next Middleware, and once all the middlewares have been consulted in order, the store reducers are reached. Redux Middleware are a fantastic choice for encapsulating side effects.
Jonny concluded this demo with examples of how to test your middleware using Mocha, Chai and SinonJS and how to design your middleware to be composable by injecting callbacks into the middleware allowing you to test your side-effect using spys.
You can check out Jonny's slides here.
Re-writing a frontend with re-usable React Components via an API
Chris McKenzie - Notonthehighstreet
Next up we had the very interesting talk by Chris on the troubles of incrementally migrating an existing system to React and how NOTHS achieved this through Toga - a CaaS (Components as a Service) system developed by Chris himself.
Chris began by describing the age old problem of being tied into a specific language and outdated tech (sorry jQuery!), and the struggles of code becoming stale and brittle due to changing architectures and opinions over time.
So what did they want to achieve at NOTHS?
- Develop faster for the business
- Make changes easier
- Share code
- More out of their tests (no longer is testing an afterthought)
- Serving the browser efficiently
This led to Toga which serves universal components which are pre-rendered on the server and initialised on the client so that they can be instantly used with any web-app.
So how does it work? Toga runs as a service supplying your custom component library on request. These components should be considered as Top Level components which contain all of the business logic needed. When making a request for a component props can be supplied as a url query. Toga will return the component as pre-rendered HTML. It also returns the associated JS, CSS and Vendor bundles to the page containing only the required assets - serving the browser efficiently.
Toga has allowed NOTHS to deliver code with the most value to the business during this migration phase, providing quick feedback cycles and sharable code.
Cycle.js: a reactive framework
Luca Mezzalira - Massive Interactive
Finally we had Luca give us a persuasive introduction into an alternative architecture of Model-View-Intent with Reactive Programming concepts in Cycle.js, with his eye-catching and informative slides.
Luca began with an introduction into Reactive Programming versus Imperative Programming. He then gave us an explanation of the core tenants that make up Cycle.js:
- Pure functions - a function that given the same input will always return the same output and not cause any side-effects
- Drivers - functions that listen to sink streams (their input), perform imperative side effects and may return source streams (their output)
- Components - reusable piece of the UI, except in Cycle.js they have a special property, any Cycle.js app can be reused as a component in a larger Cycle.js app.
- Streams - Observables are lazy event streams which can emit zero or more events, and may or may not finish
Luca finished with a demo of a TFL live feed and an overview of the Model-View-Intent architecture that is implemented in Cycle.js. By using Observables to communicate, each layer is decoupled as it does not directly know where to send each event, rather the event is detected by being observed. This decoupling and the fact that Observables are just pure functions is very powerful when testing.
- Model - this is where the state is stored
- View - receives data from the model observable and prepares the Virtual DOM
- Intent - interaction from the user that prepares the data for the Model
- Renderer - the Virtual DOM is injected and rendered.
Thanks to Jonny, Chris and Luca for their great talks, Facebook for hosting and everyone that joined us! Did you know we've moved the home of the React London Meetup? Check it out! Be sure to keep an eye out for next month's tickets as they are likely to sell out quickly.