In this article I explore how combining React’s new useReducer hook with a simple event bus can deliver much needed scalability to your application architecture, whilst at the same time prevent some of the problems that Redux often promotes in larger applications.

Redux in light of new React features

The popular state container Redux provides several benefits for a frontend application including sharing data between separated components, ensuring data consistency, as well as providing a template for code organisation. However, recent additions to React’s core API could suggest it might be worth re-considering, whether or not Redux is the right fit for your app.

A shift in thinking has begun to appear due to recent API changes, resulting in more than two thirds of Redux’s functionality now being found within React core itself. Alongside this, one can argue that the missing pieces provide more flexibility when maintained as ‘separate’ entities as opposed to within a large extra dependency.

Some have examined the basic idea of using the new Hooks and Context APIs for state management but what I would like to explore here is how breaking up Redux into it’s composite parts and then replacing the ones that React does not provide actually enables us to create more flexible architectures than pure Redux and without some of its implicit pitfalls.

Exploring Redux and some tradeoffs

Redux is a functional immutable state management container that is controlled using Action objects which effectively act like Events. It allows an application to use these Events to represent updates to a global immutable data object that is propagated to state change listeners. One of the defining and effective features of Redux is the way the programmer uses a Reducer function (think Array.prototype.reduce) to merge any given Action object with the store’s current State.

Nevertheless using Redux has both benefits and tradeoffs. Let’s explore some of the pros and cons using Redux within a React application.

There are many benefits to using Redux.

• It allows developers to easily share state data between different components throughout an application via the use of helper libs such as react-redux.
• You get control flow, a middleware pattern and the resulting ecosystem of middleware extensions available.
• By using a single master store you can be sure your state remains consistent which has been an issue prior to Redux and Flux with certain MVC patterns.
• Subsequently centralisation allows for developers to potentially explore and debug application state over time a technique supported by Redux Devtools also known as time travel debugging.
• The state reducer pattern is an effective and simple way to manage and configure atomic state changes and importantly Redux provides a common language and conventions for managing state within JavaScript applications.

So that all is great however Redux is still not without some problems:

• Redux tends towards becoming a global dependency that will have its tentacles throughout your codebase.
• It can lead developers to be tempted to store far more state globally than is actually required.
• Redux is considered as a state management container but is often used as an event bus which is a practice that depending on context could be considered an anti-pattern.
• Redux does not deal well with asynchronicity out of the box and requires middleware to even support async events.
• Redux does not deal with side effects out of the box either.
• Integration with other implicit state management containers such as Routers have always been problematic.
• You don’t actually need Redux to manage your application data because of the new React APIs.

Some of these tradeoffs can be partially addressed with splitting apart Redux to separate components and others not. At the same time we can loose some of the advantages that a standard library such as Redux provides. To look at our options let’s now examine the flow of a data change transaction to better understand what both Redux and is now providing us.

Breaking down a data transaction

Before exploring how best to use what React now brings to the table, it makes sense to take a deeper look at the ways in which Redux works conceptually so we can make meaningful distinctions with the new in-built React tools we have at our disposal.

The (state, action) => state Reducer is at the heart of Redux as it controls the transformation stage of a data transaction. This is the crucial piece of configuration that defines much of the frontend business layer but around this there are sub-systems or building-blocks that make up a chain in the sequence of a transaction. When building a Redux driven React app you might want to think about the building blocks looking a little like this:

1. A Component dispatches data in the form of an Action to the Pub/Sub or Event Bus implementation within Redux.
2. The Pub/Sub sends the data through a series of Middleware that manipulate the Action proceed with a mutation or defer it. I like to call this Transaction Pre-processing
3. Eventually the Action is sent through to a Transaction Engine which runs a pure Reducer function to merge the current State with the given Action immutably to produce a new state tree.
4. The new state tree is stored in a Data Store which exists as an in memory object but can also be cached elsewhere such as localStorage or a database.
5. The State Dependency Injector receives changes from the data store and provides the new state to components that require it
6. A recipient Component finally receives the new state and re-renders displaying the updated data.

You can think about this flow and the technology mix that provides each piece in the following way where react-redux is the state dependency injector and redux itself provides several pieces. See diagram below:

So what does React now bring to the table?

React’s new APIs provide facilities to replace a large chunk of the Redux components as well as all of react-redux. A comparable transaction engine can be found within its useReducer API. The useReducer hook also manages to provide an immutable data store. Then we can take advantage of the new useContext API to act as a state dependency injector. When including the client component in the count you could say that pretty much two-thirds of the whole transaction flow is now managed within features bundled with React. That’s a huge amount to offload!

Now above you can see that what is missing is a Pub/Sub (or Event System) and a Transaction Pre-processor.

Some might argue that useReducer provides an Event System already in that it exposes a dispatch function that can be shared to children. The thing is that because of the details of React’s Fibre re-write and eventually-consistent state resolution there is no easy way to apply a sequential transaction-preprocessing layer to useReducer. Basically this means it is far less problematic to use dispatch as a client of an Event System and the influx into the React side of the transaction as opposed to the Event System itself. You also get an extra advantage in separating your event dispatcher from your state which becomes important when you are temporally tying app contexts together that should not mix their data.

There are also some concerns (see comments below) about createContext’s performance in terms of being able to render very fast state updates to a large shared state redux tree. You can see evidence of this in react-redux’s technical challenges moving to createContext as they grapple with supporting pre-existing performance problems for minor edge cases. One of the things you gain by separating your event bus out from your state management is the ability to treat each part of state differently in terms of it’s performance requirements. So for most situations using React’s createContext will be fine but when you require faster update performance one technique available to you is to simply listen directly to dispatched events from the event bus and manage this internally with a local cache if required.

You may be forgiven for thinking that not avoiding Redux means you have to loose access to great tooling workflow such as the popular Redux Devtools project, however, with projects such as reinspect allowing developers to hook up Devtools to useReducer and useState, there is now no hard dependency on Redux for Redux devtools anymore.

Adding an Event System

So what should you actually use as your event system? Well, pretty much anything you like. You might consider something like RxJS because you get a transaction pre-processing engine for free. This might be the right move if you were migrating an app off redux-observable lets say.

Alternatively, we could use the isomorphic port of Node’s EventEmitter module to dispatch events. This will work but it doesn’t support listening to wild-carded or name-spaced events which can be useful when we want to separate out sections of our app to only respond to relevant events. I have found success with EventEmitter2 that allows for wildcard events. It may not be for everyone but my technique was to wrap this in a simple Event Bus API that contains good TypeScript support providing only the small subset of the features I actually needed in an Event Bus. I have created my own library for this technique called ts-bus .

Either of these arrangements provides more flexibility than using Redux alone.

Some benefits of a separate Event System

There are many benefits to separating out the Event System from state management.

You don’t always need state to change based on an event
Whilst it is common for state to be changed in response to an event you don’t always need to connect state change with an event. Sometimes all that is needed is to start an asynchronous background process and have it report when it is done. Bringing external state in where it is not required leads to added complexity and overhead.

You have limited your dependency exposure to a small simple component
An eventing system will become a major dependency hazard for any large app as every component that has to communicate with another will need to have access to an instance of your event dispatcher. By using a separate Event System we have avoided automatically connected state management to all your app components.

You can manage asynchronicity however you like
Events are no longer tied to state change so async becomes easier. Want to use an async function to manage asynchronous events? Easy. You control how asynchronicity is managed and what state dependencies you have available. Admittedly, implementing a cancellable saga workflow is more difficult but that is never an easy problem to solve to begin with and is rarely actually required.

It’s simple to track state in a separate store such as a Router
Occasionally state needs to be managed but cannot be tracked in your state container. This most often occurs with navigation where state is held within the browser URL via some kind of Router. Having a separate Event System means that you can easily provide a point of abstraction for your Router. An added benefit to this technique is that you don’t need to share your router code all over your application.

You have the flexibility of an event driven architecture
By using a simple Event Emitter you can handle your events however you like. Whether that be by running handlers in service workers or by setting up Observable streams or offloading computation to a server. Send events to the server, receive events from the server, synchronise a second micro-Vue frontend application, Manage side effects with RxJS; So long as you can share your event bus, your application architecture can support it. This is the power of an event based architecture you have the ability to connect up your app however you like.

As an example here we can see how conceptually you might share an Event Bus to communicate between various frontend frameworks. This might be a good approach for a huge organisation that has several teams working on their frontend stack or for teams slowly re-writing a system piece by piece:

Alternatively you can setup your event bus with a bridging system over something like socket.io for example to create a multiplex messaging channel between the browser and say an industrial event streaming platform such as Kafka in order to feed a large Event Sourced application. This might be a good approach for something like a financial exchange that needs realtime data.

Lastly, because we are talking about basic Event Bus architectures and Redux contains an Event Bus, these systems can certainly be set up by using Redux itself. The caveat here is that with Redux you drag along data with your bus that may actually cause more harm than good as developers inadvertently share state between systems that should remain separate.

Conclusion

Redux is a valuable and versatile library but it is more than just a state management container. When you choose to use Redux you are choosing your Event Bus, your Data Store, your canonical DI mechanism and so on and depending on a single package for all of these separate application functions may not be what you need in every situation.

Whilst it certainly makes no sense to re-write a large app to remove Redux, due to Redux’s tendency towards becoming a global dependency, new or smaller apps should think carefully about whether or not their needs can be served by selecting an appropriate event bus and using in-built React state management as this will lead to a cleaner and more flexible architecture.

This article is a living document please reach out if you want to contribute or see anything inaccurate here.

You can follow Rudi Yardley on Twitter as @rudiyardley or on Github as @ryardley

Life after Redux was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mobile development is inherently a multi-lingual enterprise. Usually this means writing the same functionality in multiple languages which is a bad practice. In this series I want to explore an interesting technique for simplifying our codebase by utilising the power of C++ to achieve more maintainable cross platform development.

Other articles in this series:

1. Why React Native needs C++
2. Talking like a React Native
3. Mobile to C++ with Djinni
4. Connect React Native to C++

So what about C++? Let’s groove with Djinni

So in our last instalment we setup basic communication between React Native and native code. In this article I want to cover how to set up our bridging code in order to communicate with C++.

Djinni is a great solution for sharing C++ code between mobile platforms. This bit is a little more involved but once you have it set up it is not too hard to work with.

Install Djinni

First, let’s install Djinni directly from their github. Djinni is the tool that is going to generate all our bridging code for us so we can maintain this interface over time by regenerating code.

yarn add --dev dropbox/djinni

Dropbox are not providing any official ‘releases’ of Djinni. I have been installing directly off the master branch and things have been working for me however you may want to use a commit hash for a big project.

yarn add --dev dropbox/djinni#51bf14f228579a78bc979f0e57c6849a708ed8aa

Create Djinni file

We now need to create an interface definition that describes our C++ interface we would like to use in our Native modules.

Create a file at ./helloworld.djinni with our interface definition in it:

hello_world = interface +c {
  static create(): hello_world;
  get_hello_world(): string;
}

This will expose a class from C++ that has a get_hello_world() method as well as a static create() method for simplifying object creation. For more information about Djinni and it’s IDL consult their documentation.

Create a run script

Djinni needs quite a bit of configuration so to do this easily we can create a run file in bash. I have called it ./run_djinni.sh.

Be sure to give this file executable permissions.

chmod +x ./run_djinni.sh

Time to run it.

./run_djinni.sh

Grab a twisty puzzle and a cup of joe as this will take ages the first time it runs as it must download all of Djinni’s Scala dependencies. Don’t think it is dead and stop it in the middle the way I did the first time I tried it.

Once this has completed you should find the following files created for you:

djinni/
├── cpp
│   └── hello_world.hpp
├── java
│   └── com
│       └── cppreactnative
│           └── helloworld
│               └── HelloWorld.java
├── jni
│   ├── NativeHelloWorld.cpp
│   └── NativeHelloWorld.hpp
└── objc
    ├── HWHelloWorld+Private.h
    ├── HWHelloWorld+Private.mm
    └── HWHelloWorld.h

Let’s explore what Djinni has output.

Files for both iOS and Android

• hello_world.hpp
  This file is the header file your C++ implementation that links everything together. Your implementation can extend from it. It defines the interface of your C++ module located by shared pointer reference. This is used by the Djinni bridging modules both through JNI and Objective C++.

Files for Android

• HelloWorld.java
  This sets up a proxy class that is mapped to our C++ JNI bridge. This class has a similar interface to our C++ implementation we will write. We can use this proxy class as an entry point into C++ land.
• NativeHelloWorld.hpp
  NativeHelloWorld.cpp
  This is JNI. JNI maps methods using convention to specific Java classes. They are usually complex and arduous to write and are held together by sticky tape. This code uses a bunch Djinni helper classes to marshal data and handle errors. The fact that Djinni autogenerates this code is its real value.

Files for iOS

• HWHelloWorld.h
  HWHelloWorld+Private.h
  HWHelloWorld+Private.mm
  The HWHelloWorld+Private.mm Objective-C++ class utilises a shared pointer to reference the C++ implementation we will write. It uses a bunch of Djinni helper libs to marshal data and ensure errors are reported correctly between the world of Objective-C and C++.

Create a C++ class to implement our interface

We now need to create our core C++ entry point. For now let’s just make it a simple class with a method that returns a greeting string.

First let’s write a header file that includes the hello_world.hpp header that Djinni generated and then extend from the class that gives us.

Now let’s create the actual implementation. For now let’s simply return a string from the get_hello_world() method:

Our bridging code is now setup!

So far in this instalment we have used Djinni to generate complex bridging code that allows us to interface with Objective-C and C++ as well as Java and C++. We have also created a basic HelloWorld implementation in C++ to serve as our C++ backend for our React Native code. In our next and final instalment we look at how to connect our Djinni bridging code to C++ and React Native in both iOS and Android.

You can find the code associated with this article on my github.

Other articles in this series:

1. Why React Native needs C++
2. Talking like a React Native
3. Mobile to C++ with Djinni
4. Connect React Native to C++

This article is a living document and I am constantly learning please reach out to me if you want to contribute or see anything inaccurate here.

You can follow Rudi Yardley on Twitter as @rudiyardley or on Github as @ryardley

Mobile development is inherently a multi-lingual enterprise. Usually this means writing the same functionality in multiple languages which is a bad practice. In this series I want to explore an interesting technique for simplifying our codebase by utilising the power of C++ to achieve more maintainable cross platform development.

Other articles in this series:

1. Why React Native needs C++
2. Talking like a React Native
3. Mobile to C++ with Djinni
4. Connect React Native to C++

Making the Connection

In our last instalment, we created a simple C++ backend service to connect to and covered how to generate bridging code with Djinni. In this article we complete the connection and finally get ReactNative talking to C++.

Setting up iOS to talk to C++

Open up Xcode to add the bridging files we created in the last article to our project. The following can be a little fiddly if you have not done this before so please be sure to import each file individually or as a multi-select. Don’t import whole folders or this does not work properly.

Let’s start by adding a few groups for organisational purposes. Right click the CppReactNative group and select “New Group”. Create the following groups:

• “ObjCBridge”
• “Djinni”
• “CppSrc”

Now let’s add some files to our groups. Right click each group and then multi-select the files as you add them. This way Xcode makes the correct associations and doesn’t mess around too much with your files. There might be a better way to manage this but this is the best I could work out.

• From ObjCBridge right click and multi-select each file within ./djinni/objc/*
• Again from ObjCBridge right click and select the file./djinni/cpp/hello_world.hpp
• From Djinni right click and multi-select each file within ./node_modules/djinni/support-lib/objc/*
• From CppSrc right click and multi-select each file within ./src/cpp

I don’t know why we have to do this to get Xcode to link to the files properly. I also looked at ways to script this and I could not really work out a better way than doing this. If anyone knows a better way to do this or communicate how to do this I would appreciate a comment.

In the end your Xcode asset browser should look like this:

Finally let’s alter our ReactBridge code to use our Objective-C Bridge:

Type Command + R to build and run the project. You should see React Native provide you a message from our C++ Hello World class!

Congratulations! You have just connected React Native with C++!

Setting up Android to talk to C++

Install the NDK

You need the NDK in Android Studio in order to run C++ code from Java on Android.

1. Navigate to Android Studio -> Preferences -> Appearance & Behaviour -> System Settings -> Android SDK
2. Select the SDK Tools tab
3. Check the NDK item in the tools list.
4. Click the “Apply” button.

Add the NDK path to your project’s `local.properties` file

1. Open up the local.properties file and ensure the following vars are set to reasonable locations for your SDK and NDK. The following are the default locations on a macOs system:

ndk.dir=/Users/<yourusername>/Library/Android/sdk/ndk-bundle
sdk.dir=/Users/<yourusername>/Library/Android/sdk

Create make files to build our C++ code

First we need to use a make file to specify our build config for the C++ components of our Android build. NDK will pick up this makefile when the build process runs ndk-build.

Let’s create a JNI folder in our Android project.

mkdir -p ./android/app/src/main/jni

Now we can create an Android.mk file there to specify all our dependencies and paths for our C++ code:

We also need to specify the style of compiler we will be using so next to our Android.mk file so let’s do that in an Application.mk file:

Edit the build.gradle file

Next we need to add the Java code that Djinni created for us to our project. We can do this by altering the gradle config file build.gradle. We do the following:

• Specify our module name associated with our JNI calls.
• Add the new java sources to our project.
• Specify where our makefile is for our C++ code as an external build.

Alter React Native Module

Finally we can now alter our HelloWorldModule.java file to call our JNI component.

React Native meet C++

Now if you shut down your terminal from before start the React Native server again by running the following in the React Native root folder:

yarn start

Then giving the green arrow in Android studio a pop. You should now finally see React Native presenting a message from C++ in Android!

Conclusion

Bridging C++ and React Native is not trivial but it does offer a large amount of promise for cross platform code without duplication.

I look forward to implementing lower level audio processing in React Native but with the full power of C++ now at disposal this opens up infinite possibilities for ReactNative moving forward.

You can find the code associated with this article on my github.

Other articles in this series:

1. Why React Native needs C++
2. Talking like a React Native
3. Mobile to C++ with Djinni
4. Connect React Native to C++

This article is a living document please reach out to me if you want to contribute or see anything inaccurate here.

You can follow Rudi Yardley on Twitter as @rudiyardley or on Github as @ryardley

References

• https://github.com/dropbox/djinni
• https://thebhwgroup.com/blog/react-native-jni
• http://mobilecpptutorials.com/hello-world-app-part-1.html
• http://mobilecpptutorials.com/hello-world-app-part-2.html
• http://mobilecpptutorials.com/hello-world-app-part-3.html
• http://android.mk/

Mobile development is inherently a multi-lingual enterprise. Usually this means writing the same functionality in multiple languages which is a bad practice. In this series I want to explore an interesting technique for simplifying our codebase by utilising the power of C++ to achieve more maintainable cross platform development.

Other articles in this series:

1. Why React Native needs C++
2. Talking like a React Native
3. Mobile to C++ with Djinni
4. Connect React Native to C++

On the road from React Native to C++

In our last instalment, I cover why we would want to use C++ alongside React Native to create DRY cross platform code. Over the next few articles I want to cover how exactly to do that step by step.

So let’s get started getting React Native talk to C++. The broad process goes as follows:

1. Get React Native talking to Objective-C and Java
2. Generate our C++ bridge with Djinni
3. Connect Objective-C and Java to our C++ Djinni bridge

This particular article covers the first point on the list and can be used as a guide to getting React Native talking to iOS and Android. If you already have this set up you may want to skip ahead to the next instalment where I cover more on how the C++ bridge works.

React Native Bridge — Talking like a Native

For folks coming to this article not from a JavaScript background, before we begin we should ensure we have yarn installed. Yarn is an alternative package manager that serves a similar function to npm.

On macOs you might use homebrew:

brew install yarn

You need to check the correct installation method for your system.

Now we have Yarn installed we can proceed with creating a blank React Native project. To do that I like using npx as it ensures our dependencies are up to date.

Now, let’s alter our React file to accept a message from NativeModules:

It’s time now to get some information to the NativeModules object by writing some native code. First let’s start with iOS.

React Native Bridge — iOS

This section focussed on how to get React Native talking to iOS specifically.

Let’s first create a folder to hold our bridge code.

Now create a header file for our bridging code

And some simple implementation to get a message to JavaScript. To learn more about React Native Bridge you can have a look at the documentation.

This is basically all the code we have to write to get JavaScript to call Objective-C functions. It is worth noting that by default ReactNative will call the NativeModule export the class name you define. If it encounters a name that starts with RCTsuch as RCTHelloWorld it will remove the prefix and call the module HelloWorld as is happening here. So some sprinkles of magic fairy dust… normally this sort of thing annoys me but that’s what happens as you leave the familiar explicit culture of JavaScript.

Add the bridging files to Xcode

Open up ios/CppReactNative.xcodeproj in Xcode.

Next add the contents of ios/ReactBridge folder as a group to your CppReactNative group by right clicking the CppReactNative group. Groups are virtual folders within xcode. Ensure the “copy files” checkbox is not checked as this may mean you might be building from a cached copy and not your actual code which might cause problems. Also ensure your target is selected so Xcode knows to include those files when compiling your target.

By adding the folder, the classes you just created will be picked up automatically and be made available to React Native once you build your project.

Your Xcode file tree should look something like this:

Build your project using the `⌘+R` keyboard shortcut and you should see your app display a message from Objective-C.

React Native Bridge — Android

Before pushing ahead let’s keep this setup cross platform and setup NativeModules for Android. This section focussed on how to get React Native talking to Android specifically.

First create a package folder:

mkdir -p ./android/app/src/main/java/com/cppreactnative/helloworld

Now the module class:

We then need to create a package that uses the module. This is how we package up bridging code for React Native Android. If this seems like extra steps in Objective-C dependencies are slurped up automatically but they are not for Java and we need to be explicit.

Finally we add our package to our application’s `MainApplication.java` by adding the following line to the getPackages() method:

Ensure you have Android studio setup according to Facebook’s instructions and build and run your project.

If you don’t still have the terminal session running from your Xcode build, you might want to run yarn start from your project root in a terminal. Once that is done your JS code should load up just fine and you should see your message from Android appear in the emulator:

Our app is now speaking like a native!

So far in this instalment we have covered connecting React Native with Objective-C and Java. In the next instalment in this series we will cover setting up our C++ bridge with Djinni.

You can find the code associated with this article on my github.

Other articles in this series:

1. Why React Native needs C++
2. Talking like a React Native
3. Mobile to C++ with Djinni
4. Connect React Native to C++

This article is a living document and I am constantly learning please reach out to me if you want to contribute or see anything inaccurate here.

You can follow Rudi Yardley on Twitter as @rudiyardley or on Github as @ryardley

Mobile development is inherently a multi-lingual enterprise. When working in React Native we must embrace not only JavaScript, but Objective-C, Java, Swift and Kotlin in order to be effective. Usually this means writing the same functionality in multiple languages. In this series I want to explore an interesting technique for simplifying our codebase by utilising the power of C++ to achieve more maintainable cross platform development.

Other articles in this series:

1. Why React Native needs C++
2. Talking like a React Native
3. Mobile to C++ with Djinni
4. Connect React Native to C++

Mobile is inherently polyglot

If you are a JavaScript developer eyeing off the mobile app space, you might be forgiven in thinking you can whip up a cross platform app pretty quick using React Native. Chances are the polyglot reality of mobile development will leave you in for quite a surprise. That was certainly the case for me as I attempted to get cross platform audio processing to work with React Native for a recent project. So after much study and mucking about getting it working I thought I would share the process for the benefit of folks coming to React Native from a web development background.

Realistically to create React Native mobile applications you need to have at least a basic proficiency in JavaScript, Objective-C, Java and probably now Swift and Kotlin. Mobile development is a polyglot enterprise and will likely continue to be so while major players compete for platform dominance. Evidence can be found in the failure of bridging projects such as React Native and Cordova from shielding us from this reality. NativeScript might do a little better?

Why reach for native code

Due to the tendency for app developers to gravitate towards novel ideas, as well as the attempt to squeeze more and more performance from those little mobile processors, it’s likely you‘ll find the corners of the React Native ecosystem somewhat lacking and eventually be forced off the beaten track to bust out a custom native component or two.

This can happen for all sorts of reasons but generally React Native is pretty good at handling UI so these days breaking out to native would likely be for algorithmic performance-critical behaviour such as image, audio and video processing, machine learning, 3D graphics or facial detection amongst other things.

You may also find yourself in a situation as a React Native developer where in order to tailor components to your needs, you must customise components you already use. That too can often mean making the leap to native platforms.

Don’t repeat yourself

Now whilst it’s ok for mobile development to be inherently polyglot, if the component is complex enough (and most of the above example are) then the thought of coding functionality twice for both platforms alongside the associated maintenance costs should rightfully make your hair stand up on end!

Thus, it is important to find a solution to the maintenance problems created when native code diverges, but how can we provide performant code for both platforms without having to rewrite everything twice?

Ideally what we need is a way to code all our high performance app components once and only once. In reality there will be times we must take advantage of platform specific functionality in native languages, but for complex performance sensitive advanced functionality, we can avoid overhead by settling for a third option.

Searching for a ‘lingua franca’ of computers

There are a few ways to solve this problem. As you can tell from the title of this article I settled on C++ because of my needs but you may find other techniques work for your project. For example, you may want to look into Kotlin Native which can compile Kotlin for iOS targets, which is a perfectly valid solution to the problem. Alternatively, you might be able to make some headway by compiling Rust or another similar language to Web Assembly then shipping that with your app however the non-natural wasm execution environment could limit your ability to use 3rd party libraries.

In my case, I wanted to work with performance critical audio processing libraries and unfortunately pretty much every serious audio lib out there is written in cold hard C++. Nevertheless, it turns out that one thing just about all computer systems have in common in that they can act as a compilation target for C and C++ and both Android and iOS are certainly no exception. The hoops one has to jump through to get Java or Objective-C to successfully talk to C++ are numerous, however, especially when you are first and foremost a JavaScript developer with only a passing familiarity with each platform.

It might surprise you coming from web development that bridging to C++ is actually a common approach to shared code in mobile development outside the React Native space. Dropbox have actually been doing it for years now for their shared business logic.

Modern C++ is actually pretty approachable

To be honest I had not looked at C++ since attempting and failing to create VST plugins around 20 years ago. Initially the thought of using it filled be with as much joy as going to the dentist or doing my taxes. However through the lens of two decades of professional programming experience, I began to notice modern C++ is actually not as tough as I expected. There are newer features that help with some of the harder elements of the language such as smart pointers for memory management. I find it easier and more intuitive than approaching Haskell for example however things do still get complex quickly in some cases. If you need a video primer I highly recommend Cherno’s tutorials on youtube.

Lost in translation

Nevertheless, getting native systems talking to C++ is more difficult than I expected. It becomes apparent rather quickly there is a tonne of indirection when attempting to access one language from another on mobile systems. React Native provides a mechanism to access Objective-C on iOS and Java on Android which gets us native execution, but that is only the easy part of the challenge.

Because they share the same C-based memory model, things turn out to be ok-ish when moving from Objective-C to C++. We can reference C++ objects using Objective-C++ (a hybrid language that shares constructs from Objective-C and C++). However by nature as a hybrid language Objective-C++ can accommodate 2 types of exceptions, 2 types of ref counting and 3 types of bugs*. So having a lot of logic there is definitely a bad idea. Basically we want to wrap our calls and get out.

Things get more difficult and disturbing in Java where we are stuck mapping types over JNI which can be extremely tedious and error prone even when doing simple things. The whole system works using magic method names in the C-language space and every data type needs to be marshalled explicitly and correctly. Basically there are lots of details and the results will likely be fragile and error prone when building this bridging code by hand.

The Djinni is out of the bottle

Luckily Dropbox had that very same problem a few years ago and came up with a great little open source solution called ‘Djinni’ (pronounced like Genie). Djinni generates mobile bridging code based on a simple interface definition language that can describe your bridging API. You might want to checkout dropbox’s introductory video to Djinni.

Djinni sounds like a great solution to sharing C++ code between platforms however scouring the web for tutorials on how to set up Djinni specifically with React Native didn’t bear much fruit apart from a couple of mysterious repositories that generally were out dated and didn’t work when I tried to use them.

In the end I found elements from a handful of tutorials helped me get this working and have successfully been able to get C++ talking to both platforms. I have referenced them at the bottom of this article.

Broad architecture for now

This is the broad architecture I am considering for reusable “write once” mobile apps.

As a side note it may be possible to make a Djinni plugin to bake a bridge from React Native directly into C++. It has been attempted here yet I found the code was custom, out of date, lacked detailed documentation and I did not want to use unsupported code for my purposes. As I work more with this architecture I will attempt to get the react-native djinni plugin to work since I think it would result in a cleaner architecture and will write about it and update this tutorial but for now I will stick to keeping ReactNativeBridge and Djinni as separate.

Next Steps

Hopefully I have made the case for how and why it is useful that we can bridge to C++ within the context of React Native. The rest of this series acts as a guide to implementing cross platform communication with React Native. In the next instalment we will cover getting React Native talking to both Objective-C and Java as the first step in bridging React Native and C++.

Other articles in this series:

1. Why React Native needs C++
2. Talking like a React Native
3. Mobile to C++ with Djinni
4. Connect React Native to C++

This article is a living document please reach out to me if you want to contribute or see anything inaccurate here.

You can follow Rudi Yardley on Twitter as @rudiyardley or on Github as @ryardley

As an IT professional and as an Australian citizen, I have been compelled to write to you to ask you to re-consider your recent position on encryption. I am a professional computer programmer and software engineer with over 18 years experience in the field. I understand the technical details of how encryption works.

The fact is that with server-less non-commercial peer to peer end to end messaging technology there is simply nothing that can be done by law enforcement to get access to messages sent by terrorists and eliminating server-based services such WhatsApp or Signal don’t do much to affect their plans nor make them easier to catch. Any smart terror organisation will be moving to or developing peer to peer systems as we speak. Terrorists will flock to hardened systems that cannot be legislated against while Australian lay-persons will stick with systems they know.

This legislation will not stop terrorists.

Any attempts to compromise security protocols will make it easier for bad actors to hack the private communications of Australians which will allow crimes such as extortion and blackmail to be easier to execute.

This legislation will make communications more dangerous for ordinary Australians.

By removing the technical apparatus for privacy protection you make it so that a system of amendments that future governments create will further erode Australians’ right to privacy in the future.

We have seen oversight already creeping in with applications for warrantless access to metadata including agencies that have no place having access to that information such as Greyhound Racing Victoria. This type of thing will happen with legislation like this no matter what safeguards you put in place. Simply look at what happened with the NSA in America.

This legislation’s only accomplishment is to make Australians less safe and expose their private communications to the government of the day.

Saying this legislation makes Australians safer is exactly the opposite of the truth.

This is unethical. This is not the Australia we know. This is not the Australia we want.

This is too dangerous for too many people to pass this legislation. You should oppose this legislation.

Regards,

Rudi Yardley

This article is a living document please reach out to me if you want to contribute or see anything inaccurate here.

I encourage you to send similar letters to Bill.Shorten.MP@aph.gov.au

You can follow Rudi Yardley on Twitter as @rudiyardley or on Github as @ryardley

I am a huge fan of the new hooks API. However, it has some odd constraints about how you need to use it. Here I present a model for how to think about using the new API for those that are struggling to understand the reasons for those rules.

Unpacking how hooks work

I have heard some people struggling with the ‘magic’ around the new hooks API draft proposal so I thought I would attempt to unpack how the syntax proposal works at least on a superficial level.

The rules of hooks

There are two main usage rules the React core team stipulates you need to follow to use hooks which they outline in the hooks proposal documentation.

• Don’t call Hooks inside loops, conditions, or nested functions
• Only Call Hooks from React Functions

The latter I think is self evident. To attach behaviour to a functional component you need to be able to associate that behaviour with the component somehow.

The former however I think can be confusing as it might seem unnatural to program using an API like this and that is what I want to explore today.

State management in hooks is all about arrays

To get a clearer mental model, let’s have a look at what a simple implementation of the hooks API might look like.

Please note this is speculation and only one possible way of implementing the API to show how you might want to think about it. This is not necessarily how the API works internally.

How could we implement `useState()` ?

Let’s unpack an example here to demonstrate how an implementation of the state hook might work.

First let’s start with a component:

The idea behind the hooks API is that you can use a setter function returned as the second array item from the hook function and that setter will control state which is managed by the hook.

So what’s React going to do with this?

Let’s annotate how this might work internally within React. The following would work within the execution context for rendering a particular component. That means that the data stored here lives one level outside of the component being rendered. This state is not shared with other components but it is maintained in a scope that is accessible to subsequent rendering of the specific component.

1) Initialisation

Create two empty arrays: `setters` and `state`

Set a cursor to 0

2) First render

Run the component function for the first time.

Each useState() call, when first run, pushes a setter function (bound to a cursor position) onto the setters array and then pushes some state on to the state array.

3) Subsequent render

Each subsequent render the cursor is reset and those values are just read from each array.

4) Event handling

Each setter has a reference to its cursor position so by triggering the call to any setter it will change the state value at that position in the state array.

And the naive implementation

Following here is a naive code example to demonstrate that implementation.

Note: This is not representative of how hooks work at all under the hood but it should give you an idea of a good way to think about how hooks work for a single component. That is why we are using module level vars etc.

Why order is important

Now what happens if we change the order of the hooks for a render cycle based on some external factor or even component state?

Let’s do the thing the React team say you should not do:

Here we have a useState call in a conditional. Let’s see the havoc this creates on the system.

Bad Component First Render

At this point our instance vars firstName and lastName contain the correct data but let’s have a look what happens on the second render:

Bad Component Second Render

Now both firstName and lastName are set to “Rudi” as our state storage becomes inconsistent. This is clearly erroneous and doesn’t work but it gives us an idea of why the rules for hooks are laid out the way they are.

The React team are stipulating the usage rules because not following them will lead to inconsistent data

Think about hooks manipulating a set of arrays and you wont break the rules

So now it should be clear as to why you cannot call `use` hooks within conditionals or loops. Because we are dealing with a cursor pointing to a set of arrays, if you change the order of the calls within render, the cursor will not match up to the data and your use calls will not point to the correct data or handlers.

So the trick is to think about hooks managing its business as a set of arrays that need a consistent cursor. If you do this everything should work.

Conclusion

Hopefully I have laid out a clearer mental model for how to think about what is going on under the hood with the new hooks API. Remember the true value here is being able to group concerns together so being careful about order and using the hooks API will have a high payoff.

Hooks is an effective plugin API for React Components. There is a reason why people are excited about this and if you think about this kind of model where state exists as a set of arrays then you should not find yourselves breaking the rules around their usage.

This article is a living document please reach out to me if you want to contribute or see anything inaccurate here.

You can follow Rudi Yardley on Twitter as @rudiyardley or on Github as @ryardley

React’s new Hooks API allows us to finally share behaviour without any of the intrinsic problems that have plagued the community previously

Sharing behaviour between components

I have been developing with React since its early days and during that time there have been many attempts by both influencers, as well as the core team to improve the API and patterns developers are using to creating software. One of the biggest challenges we have had was how to share behaviour neatly between components to enable reuse or even just separation of concerns. Every single solution proposed up until this point had some problems associated with it.

Luckily React has just released a their new API for sharing behaviour in React components that solves many of the problems we have had in the past.

This is what it looks like:

First lets have a little look at how we got here…

Mixins and magic methods

When React was first released, classes were not available in ES5 so React shipped with its own class creation method, which included the ability to merge in a bunch of methods from an object into the component you create.

This unfortunately led to similar problems you find with classical inheritance; mainly indirection from magic undocumented methods appearing out of nowhere and being used on components. The developer has no idea what functionality is available to them and more importantly what is not.

This smell was so bad the React team decided to remove Mixins completely when they introduced a new ES6 class based API.

Things got better but there is still a problem

Both the more recent attempts at sharing functionality between Components, namely Higher Order Components and Render Props, have also fallen short on an API level for several reasons.

Higher Order Components still cause indirection

Higher order components (or HOCs) are an attempt at applying the Functional Programming concept of higher order functions to React components. The idea is that you alter your component by wrapping it in an outer component that provides behaviour, composing the original component and passing the behaviour’s results as new props to the original component. This is done in a similar fashion to the way higher order functions pass data via closures.

What’s great about higher order components is that you can see the data coming into the component as a prop. It is no longer magical like with Mixins.

However there are issues. The main problems with higher order components include:

• They are complex to setup.
• You can not distinguish between data that was coming from the HOC and the data that was passed to the component.
• The HOC is external to the component yet the component remains dependent on the HOC. Remove the HOC and the component would not always work if it depends on the HOCs data.
• You can end up with huge render trees as behaviour components contain render components.

Render props and the pyramid of doom

Render props are a relatively new trend and offer an answer to some of the dependency and indirection problems that HOCs can cause. They are created by enabling a component to accepts a function prop that it will use to render its children. This allows the component to provide a closure for its children as well as some behaviour and new data.

However they can be abused. See this (event though contrived, unfortunately rather typical) Apollo React example:

If you have ever worked with me you probably know my hesitation around using render props. I think it can be a useful pattern in certain contexts however it has a few major issues:

• It declares false hierarchies ie. pyramid of doom.
• Encourages passing inline functions to child components which if not checked can lead to performance problems.
• Create confusing closure structures which should actually be inline.
• Leads to very verbose component JSX

In fact class lifecycle methods also suck

Since its inception React has included various lifecycle methods for developers to hang code on based on particular execution times within the lifecycle of the component being rendered in React. Being able to support this asynchronous behaviour is why React components were modelled as classes to begin with. This model is simple and it provides an intuitive way to attach behavioural code to a Component.

There are problems however with this approach. What tends to happen in practice is that code relating to a particular functionality ends up being scattered all over the various lifecycle methods of the class and usually right next to code from unrelated behaviour. This commonly happens whether or not you are using HOCs or render prop components. Also by using classes you inevitably need to use the JavaScript this object which means you need to understand and take care of binding your handlers as you pass them around to child components.

React 14 introduced stateless functional components to resolve this but they did not provide ways to access lifeCycle methods which relegated them to only be used on components that would not grow into requiring complex behaviour

Enter the React “hooks” API

At ReactConf 2018, the React team announced their new hooks API. React’s new API attempts to solve these problems by making HOCs and render props obsolete. The new API allows for true state driven behaviour sharing while also:

• Providing a way to get access to state managed props and be able to easily follow exactly where that state has come from.
• Returning memoized functions avoiding performance penalty from downstream PureComponents
• Not creating a pyramid of doom
• Not touching props. What you pass into the component in JSX is what you get in props.
• Not creating any magic behaviour methods.
• Leading to simpler JSX that is more concerned with component rendering and less with behaviour.
• Removing the performance overhead of wrapping components in layers.
• Allowing for custom behaviours to be bundled off into their own functions that can be exported by libraries.

Example of the Hooks API

Here is an example of how to create a custom hook:

There are a few minor drawback to the new API

The main drawback to using the hooks API is that all the “hooks” methods must be run in the same order every time the component is rendered.

This means that you cannot call hooks functions within if blocks or loops within your functional component.

In fact when I first heard about this I was a little concerned. I don’t like the idea of hidden rules I have to follow. I think it means that new folks coming to the API will struggle to understand why their code is not working.

After thinking about this and reading through the docs for a bit I think I am beginning to understand why the React team has gone down this path.

The React team says they will support us with a suite of linting plugins. Not everyone uses linters however yet I would assume that they will at least attempt to include some kind of friendly runtime error as well eventually although detecting if a bit of code is in a conditional might be impossible at runtime. So this is a shame. Maybe over time the React team will work out clever ways to prevent trip ups for codebases that are not linted as well as on-board new developers to the API. After thinking about this and reading through the docs for a bit I think I am beginning to understand why the React team has gone down this path. Alternative syntax implementations will involve more boilerplate and to be fair this solution is actually rather ingenious.

Conclusion

The ideas presented in the hooks API is a boon for React developers. Finally we have a relatively baggage free API for developing React components. We no longer need to worry about refactoring from functional components to classes and can share behaviour without confusing indirection.

I look forward to seeing libraries such as ApolloClient and Redux develop their own hooks API components for implementing behaviour.

For more information you can check out their write up on the React website and watch the announcement demo below:

This article is a living document please reach out to me if you want to contribute or see anything inaccurate here.

You can follow Rudi Yardley on Twitter as @rudiyardley or on Github as @ryardley

Why React’s new Hooks API is a game changer was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Good developers become great when they have great information.
Great teams become excellent when they share information with each other.

The stakeholders’ linchpin

When developing software there are several primary stakeholders that project teams must take into account to be successful.

The exact priorities vary, but generally managers balance their focus between stakeholders like Users, Customers and the Business etc.

Over the course of my career, however, I have noticed one vital stakeholder consistently and inappropriately pushed down the list. This occurs even when that stakeholder directly affects outcomes for every one of the project’s other stakeholders. Yep I am talking about the Project Team! I would go so far to say they are actually the “linchpin” of your software project. The reason I like to call software teams a “linchpin stakeholder” is for the simple reason that, if you fail to support them, the project will fail to deliver value to it’s wider stakeholders. The Project Team is simply crucial.

There are various aspects of team support we can consider here, however, the biggest problem I see in this area is when a business ignores the way each team member gets and uses information in their daily practice.

Team support is all about managing information

I want to be clear about what I don’t mean by supporting a team. I don’t mean giving everyone a pay rise, getting fancy office fixtures, installing a ball pit, pool table, a pinball machine and offering shoulder massages twice a week.

What I am talking about is refining your team’s information environment and systems. In software engineering all the tools, processes, environment, infrastructure and cultural factors we are presented with are all information vectors.

These vectors might include things such as:

• Knowledge sharing
• Collaboration tools (Source control, Project Management Tools)
• Ritual and processes
• Source control
• Infrastructure
• Application architecture
• Code culture (eg. Clean code, Git hygiene)
• On-boarding and hiring of new team members.
• Conferences
• Supported study
• Mentoring
• Pair programming
• Social culture

Ensuring each team member has the ability to get access to, and share the information they need to work and collaborate as effectively as possible is why those tools exist.

These things are often neglected, especially in a start up environment, yet they all contribute greatly to the effectiveness of a project and the longevity of the startup.

Why are information systems so important?

It can be argued that Software Engineering as a discipline, is effectively doing nothing but rearranging information to achieve certain outcomes. Therefore it stands to reason, developers having access to great information will deliver great outcomes for stakeholders.

This is especially true for junior developers on your team who desperately need the support of great information in order to succeed. Good information systems will be the difference between them making poor decisions and good ones.

That being said, there are several benefits for encouraging a team’s access to and ability to share information. The correct environment for your team will enable greater productivity and better performance through effective collaboration and joint learning. That great productivity actually all funnels value directly to your key stakeholders.

So how can you look after your team’s information environment?

Great processes create great organisations. Here are some of the things project teams should be thinking about.

Hiring great people

Great engineers are simply people that have a huge amount of information at their disposal. The more information they accumulate with experience the better decisions they will likely make and the more information they can share with the rest of the team. So you get ahead by hiring great people and you stay ahead when they share that information with the rest of the team.

Code review like crazy

Code reviewing is probably the second best way to share information in your team after pair programming. If you have more than one developer, encourage a code review culture. In fact, there are so many advantages to code reviews, that it could be argued that for an organisation not doing so is a questionable practice.

Code reviews ensure your application actually fulfils requirements, increases consistency, lowers cognitive code overhead, increases knowledge transfer drastically, can be used as accountability, allows for the creation of better estimates, removes a single point of failure within a team, makes your application easier to reason about & maintain, mitigating the cost of defects and mentoring junior developers …all at the same time!

Communicating well to avoid technical debt

Accidental technical debt is a huge problem that slows your company’s effectiveness over time and in some instances can destroy your company completely.

Proper information processes prevent accidental technical debt by ensuring every team member understands, communicates and discusses why debt has been leveraged and delivers them the power to pay it off as appropriate. It also allows for strategic accrual of technical debt deliberately for specific business reasons via wider consultation.

This is not limited just to the technical team either. If business strategies and requirements have not been properly communicated to the development team one of the main resultant artefacts is extra accidental technical debt. An information problem often results in a technical debt problem.

Constraining via tooling to foster better communication

Increase information flow by enforcing your processes with tooling. There are a huge number of benefits that quality tooling can bring to a teams workflow. These constraints encourage information flow.

Common checks, send signals to team members about the values of the team. Eg. enforcing passing tests or code reviews, using linters to disallow poor practice, using pull request templates to enforce documentation. These all act as queues to make a developer understand what is expected of them. Standard tools like custom bootstrappers or centralised config, communicates that your team values consistency. Developers should question standards consistently and weight up decisions as to refine processes as teams navigate and contribute to the changing culture of the team.

By using tooling to enforce workflow, engineers don’t need to waste time thinking about the ramifications of small poor decisions that add up to larger issues. This means they can think about building the business functionality wider stakeholders expect them to build.

Architecting as if your engineers are visually impaired.

Great system design means engineers are able to think myopically. The less information a developer needs to work on the code the better. In fact within Domain Driven Design bounded context means a model’s applicability is limited to specific areas of the system. CQRS takes this further and suggests that the model a read process needs to do it’s job can be different to that which a write process requires.

When an engineer is working on a bug or feature, they should not need to care about other parts of the stack or even know how the rest of the application works. Armed with the basic patterns, they can hack away, in a neatly boxed off area, blissfuly unaware of the overall system complexity and still remain productive.

Each feature or request chain should be arranged in such a way as it can work or at least can be tested as a separate application. Isolate your dependencies wherever you can. This is a sure way to increase velocity and efficiency.

Here you also constrain poor design to a single feature which can be flagged and refactored as part of code review. Ideally as a side effect you will have setup functionality that can be run in different environments and scaled independently. By limiting an engineering task to an isolated feature at a time you will increase their velocity as they need not cross coordinate with other team members.

Keeping your organisation’s knowledge close to your code.

The knowledge of why approaches have been taken as well as knowledge of the way to work with the patterns setup should ideally be held as close to the code as possible.

Create Issues and PRs in meetings to provide documentation. Avoid using separate knowledge systems that engineers rarely use. Make sure the information that engineers need to be effective is at their finger tips.

This ensures new and remote team members will be able to easily understand rationales for code patterns and make effective decisions about how to conduct their own work.

Remote first is a useful abstraction that promotes sharing and documentation

Great organisations are great information systems. Automate your documentation and grow a system by always paying attention to your remote team members.

Do this correctly and you will have access to a disposable legion of the best engineers in the world. Imagine the power to have engineers come and go without them greatly impacting the business.

This section may come across as a somewhat counter intuitive, however the best teams I have worked with have not needed an office. From the perspective of a remote worker, offices encourage “encapsulated knowledge” a lack of visibility into office decisions and an inability to provide a meaningful impact to a business which results in poor morale and dedication.

The usefulness of thinking about your company as remote first lies in the way it forces you to create a self documenting organisation. Meetings can be run like webinars where the discussions are captured within the company discussion history. Standup should be held accessible to all timezones, using a microphone and should involve live updating project management software in realtime so people get a sense of where they fit in the big picture. Architectural change proposals and discussions can be documented within it’s own space in a repo. Ideally stored near the meeting video archive.

By thinking of your team as remote first you start adding an abstraction around office work that actually encourages better communication, accountability, architecture and community whilst at the same time avoiding some of the more toxic aspects of office culture.

Office time and time together is important and face to face meetings can allow for rapid communication but to leave remote workers out of the equation is dangerous for information flow.

Information putties up cracks

You are only as good as your poor performers. But why are your poorest engineers poor? Often junior engineers are considered poor because they lack experience. But what is experience but simply having access to high quality information about the consequences of bad and good decisions? It is precisely because they have not had great information that they make poor decisions. Fixing this information flow is key to supporting your team.

Teams with great information systems can control the rot and guide the inexperienced or wayward engineer back to the fold and encourage them to perform at the top of their game.

In summary

Your people are your most important asset in any organisation. They need the tools to do their jobs to the best of their ability and knowledge is the best tool you can arm them with.

Your team is your number one dependency the best thing you can do to keep them producing great output over an extended period is service them well with good systems to access and share information so they can produce the best possible outcome.

Your best chance at success will come when you:

• Hire the best people
• Talk about your code often
• Be judicious regarding technical debt
• Use tooling and constraints to communicate values
• Architect like you are short sighted
• Keep your organisation knowledge where your team will see it
• Use remote team members to foster documentation

Keep your team organised give them what they need to succeed and it should not be surprising when they do.

This article is a living document please reach out to me if you want to contribute or see anything inaccurate here.

You can follow Rudi Yardley on Twitter as @rudiyardley or on Github as @ryardley