Extending React’s container/presentation pattern to share business logic between apps

One of the hottest JavaScript libraries out there right now is React. Whilst there are many good reasons for React being so popular, the main reason my team picked React for our new project is because of the commonality between React and React Native. The concepts and the language are the same, so if you can write React, then you can write React Native. There is also the benefit of being able put both in the same project and then share business logic between them, which is precisely what we need to be able to do.

There are a number of ambitious projects out there that aim to eliminate duplication between platforms by using a common set of React primitives. react-native-web, ReactXP and react-primitives spring to mind. However, these rely on not only a common set of components, but also a common approach to things like styling and animations.

Whilst we wait for the dust to settle on which is the best generic solution to use, my team has come up a simple approach that extends upon a pattern that is already quite well known in the React community. In this post I’ll outline this approach.

Ampersandjs at the beach


Ampersand.js was created by the good people at &yet. It is based on Backbone.js, and refers to itself as a ‘non-frameworky framework’. In a world where Javascript frontend frameworks abound, it can be difficult to choose ‘the best’ one for your project. Most of the time you would go with that which was used before, which is the most popular, or which is most familiar. In 2015 I found myself in a position where a series of small, discrete, single-purpose, front-end ‘widgets’ were proposed. The small development team was able to choose what we wanted, and Ampersand.js was selected. In this post I’ll talk about why I like using it for our projects, and what I think makes a good framework in general.

Triggering Dataflow Pipelines With Cloud Functions

Do you have an unreasonable fear of cronjobs? Find spinning up VMs to be a colossal waste of your towering intellect? Does the thought of checking a folder regularly for updates fill you with an apoplectic rage? If so, you should probably get some help. Maybe find another line of work.

In the meantime, here’s one way to ease your regular file processing anxieties. With just one application of Google Cloud Functions, eased gently up your Dataflow Pipeline, you can find lasting relief from troublesome cronjobs.

TypeScript, Flow and the importance of toolchains over tools

EDIT: The initial version of this post stated that the TypeScript compiler won’t emit code if it finds errors in the source. This is not correct. By default, the compiler will emit code even if it detects errors, unless the –noEmitOnError flag has been set. This post has been updated accordingly.

I’ve recently been working on a project that uses TypeScript. I also have been playing with Flow on a personal project. In this post I want to talk about why I think these tools are important, some of the fundamental differences between them, and why the choice of which one to use might best be determined by the broader toolchain that you are working within, rather than just the particular technical merits of one or the other.

YOW! Connected 2016: The typed-functional future of UI platforms

I just spent a couple of days at the YOW! Connected conference and had a great time, despite nursing a bit of a cold. There were a tonne of great talks at the conference covering a wide range of topics, but in this post I’m going to briefly reflect on one specific trend that interested me at the event: the way in which UI platforms are advancing to adopt modern languages, and are even influencing each other in the process. The end-result: they’re all moving towards languages that are both functional and statically typed.

Full disclosure: This year I was a member of the programme committee for the conference. So in writing this post, there’s a bit of a risk that I’m creating an echo chamber for myself. All I can really say in my defence is that I hadn’t consciously made these connections in advance – it was only afterwards that I saw a trend!

Creating a serverless ETL nirvana using Google BigQuery

Quite a while back, Google released two new features in BigQuery. One was federated sources. A federated source allows you to query external sources, like files in Google Cloud Storage (GCS), directly using SQL. They also gave us user defined functions (UDF) in that release too. Essentially, a UDF allows you to ram JavaScript right into your SQL to help you perform the map phase of your query. Sweet!

In this blog post, I’ll go step-by-step through how I combined BigQuery’s federated sources and UDFs to create a scalable, totally serverless, and cost-effective ETL pipeline in BigQuery.

Style Guides and AEM: Fitting a Square Peg in a Round Hole


There is a push in the industry to code against an external style guide to maintain consistent styling, have a reusable set of components to build applications with and provide a shared vocabulary for teams to communicate. The goal is that any web application built in an organisation can make use of this style guide to re-use existing CSS rules and/or Javascript functions. For example, one of the more well-known and recently-published style guides is the U.S. Web Design Standards, which will enable U.S. government agencies to create a unified user experience throughout their web applications.

When dealing with modern web applications, integrating a style guide is a relatively straightforward process. It often involves leveraging the existing Javascript build tooling to pull assets down via npm, and then having those assets processed as part of the build pipeline along with your application’s styles/scripts. Alternately, you can simply copy-paste a version of your style guide’s artifacts into your application – the quick and dirty way.

However, things are not always this easy. In my experience working with AEM/CQ, integrating a style guide into a project has consistently been a challenge.

To be fair, style guides are not to be blamed for this. AEM’s strict file structure, meta-data (.content.xml files and the like) and reliance on Java technologies can make it challenging to integrate with Javascript-based tooling. Each project generally ends up with a set of custom scripts to achieve this integration, resulting in a solution that is simply not maintainable. If you’ll indulge me for a moment, I’d like to take this opportunity to run through a few solutions I’ve come across to integrate style guides with AEM.

Shiner Ben Teese to speak at YOW! Connected


Shine is proud to announce that senior consultant Ben Teese will be speaking at the YOW! Connected conference being held in Melbourne on the 17th and 18th of September.

Ben’s topic will be React Native, an innovative new framework that applies the principles of the React web development library to native mobile application development.

If you haven’t purchased a ticket to YOW! Connected yet, be sure to get one whilst they’re still available. And if you’re already coming, be sure to check out Ben’s talk and say hi afterwards!

ES6 with Babel.js

With Babel.js, we can all use ES6 before browsers support it

ECMAScript 2015, also commonly known as ES2015 or ES6, is the specification that defines the ECMAScript language, of which JavaScript is one implementation. This new version of the specification introduces language features to JavaScript that can improve developer efficiency and happiness.

Some features of the ES6 spec have already been implemented in browsers, whilst others are only beginning to be implemented. However if your desired features are not implemented yet, or you need to support older browsers, it is still possible to get the benefits of ES6 now by using Babel.js.

Over the last few months we have been using Babel to gain access ES6 features, while still maintaining support for browsers like Internet Explorer 9. In this blog post I will explain what Babel is, and how you can use Babel for yourself.

Web Directions Code 2015: Conference Report

webdirectionsWeb Directions’ Code is a front end engineering conference that’s been run in Melbourne, Australia since 2012. I was lucky enough to attend this year’s conference, held under the spire at the iconic Melbourne Arts Center.

It featured a number of expert speakers and aimed to provide a refresher on the state of the industry concerning both web development technologies and best practises. This post is a rundown of some of the things I learnt throughout this two day event as well as a detailed look at some of the presentations I found most engaging.