I’ve said before that D3 is the best, most powerful tool we have in React-Native (and maybe even all mobile development) for creating charts and data visualizations 📈. In the past, I’ve written about how to use React-Native and D3 with React-Native SVG and Re-Animated 2.

Since writing that article, React-Native Skia has become the better library for presenting and animating D3’s SVG charts. Because of this, I thought I’d write a new article on how to create and animate D3 Charts with React-Native Skia.

If you get stuck at any point, have a look at my code sample on Github. Also, feel free to check out my YouTube tutorial on this subject if you prefer visual learning.

What are we Building?

As always with my how-to guides, I like to start by showing what we are building. We will be creating the line chart you see in the GIF below complete with the animation between line graphs.

Getting Started

The first thing you’ll want to do is generate the project using this command:

npx react-native init MyAwesomeProject --template react-native-template-typescript

After this, run the following commands to add D3 and Skia to your project.

yarn add @shopify/react-native-skia
yarn add d3
cd ios && npx pod install
yarn ios

Our environment for the project is now set up and ready to go!

Familiarizing Ourselves with the Data

Let’s start by familiarizing ourselves with the structure of our data. Each point has these values:

export type DataPoint = {
  date: string;
  value: number;
};

export const originalData: DataPoint[] = [
  {date: '2000-02-01T05:00:00.000Z', value: 250},
  {date: '2000-02-02T05:00:00.000Z', value: 300.35},
  {date: '2000-02-03T05:00:00.000Z', value: 150.84},
  ...

All the data for this app can be found in the Data.ts file in the sample project. I recommend copying and pasting it into your project if you are following along.

Organizing our Data

This next part is almost identical to when you use React-Native SVG. To build a chart, we need to organize our data so it can be handled by D3. The first thing we’ll want to do is add constants for height and width at the top of the file.

const GRAPH_HEIGHT = 400
const GRAPH_WIDTH = 370

After that, we need to create a method that returns an object with our processed chart data in the App.tsx file.

const makeGraph = (data: DataPoint[]) => {};

The next step we’ll take is calculating the max and min values in our dataset. These values are used to form the y domain of our chart. This is pretty simple to do, we can just feed the values of our data into the Math.max and Math.min methods.

const max = Math.max(...data.map(val => val.value));
const min = Math.min(...data.map(val => val.value));

After that, creating the y axis is as easy as calling scaleLinear in the D3 library. Note the use of GRAPH_HEIGHT in the range. This will ensure all our data points are mapped to y coordinates on the screen that is no greater then the graph’s height.

const y = scaleLinear().domain([0, max]).range([GRAPH_HEIGHT, 35]);

For the x-axis, we know our data is always going to be fifteen days so we’ll set the starting point and ending points at the first and fifteenth of the month respectively. Note the use of GRAPH_WIDTH in the range. Like the y axis, it maps our values to x coordinates on the screen and makes sure they are no greater than the graph’s width.

const x = scaleTime()
    .domain([new Date(2000, 1, 1), new Date(2000, 1, 15)])
    .range([10, GRAPH_WIDTH - 10]);

We then finish off by creating the line chart using the line function from D3.

const curvedLine = line<DataPoint>()
    .x(d => x(new Date(d.date)))
    .y(d => y(d.value))
    .curve(curveBasis)(data);

After this we convert our curved line into a Skia path.

const skPath = Skia.Path.MakeFromSVGString(curvedLine!);

We return the max, min and skPath values from our function. They will be needed soon to draw our chart.

return {
    max,
    min,
    curve: skPath!,
 };

Finally, let's define a type for the processed Graph Data we just created.

interface GraphData {
  min: number;  
  max: number; 
  curve: SkPath;
}

Altogether, our makeGraph function should look like this:

Drawing a Single Graph

The next thing we’ll do is draw our graph. Let’s start by adding our first data set to the component in App.tsx.

const graphData = makeGraph(originalData);

At this point, we are in a good position to add the canvas to our app and set its width and height.

<Canvas
  style={{
    width: GRAPH_WIDTH,
    height: GRAPH_HEIGHT
  }}
>
</Canvas>

For some style points on our graph, let's draw some guidelines. You’ll notice the API for drawing lines differs a bit from SVGs. Instead of passing a first and second coordinate, you pass in coordinates for two points and Skia draws a line in between them.

The last thing we’re going to want to do is to draw our graph. We do this by passing the Skia path we created earlier into the Path component from React-Native Skia.

  <Path
    style="stroke"
    path={graphData.curve}
    strokeWidth={4}
    color="#6231ff"
  />
</Canvas>

The canvas code should be in this state.

At this point your graph should look like this:

Animating Multiple Graphs

Finally! The moment we’ve all been waiting for - animating multiple graphs 🙂. You’ll find the Skia animation API to be pretty different from ReAnimated and ReDash if you are used to those libraries but it's still about as easy to use. This animation is borrowed from the William Candillon video on Chart Animations.

Start by copying in these buttons and adding them under the canvas. We’ll use them later to control the animation.

Now, back in our component, let's give it some state.

const transition = useValue(1);
const state = useValue({
  current: 0,
  next: 1,  
});

The transition value here functions similar to a boolean. This value is 1 if the animation is completed and 0 if we need to animate. The state value is the index of the graph that we want to show.

Now let’s create the transition.

As you can see here, we start by setting the current graph to the index passed in and the previous graph as the current one. The transition value is then set to 0 so that Skia knows an animation needs to take place. runTiming then animates the graph through a number of values between 0 and 1 until the graph animation reaches its completion.

Next, we use the useComputedValue hook to create SVG paths for all values of the transition using the state we created above.

At this point, you’ll want to make graphData into an array:

const graphData: GraphData[] = [
  makeGraph(originalData),
  makeGraph(animatedData),
];

Then pass the path into the Skia path component

<Path style="stroke" path={path} strokeWidth={4} color="#6231ff" />

Finally, add the startTransition method to the pressables we added earlier:

<Pressable
  onPress={() => transitionStart(0)}
  style={styles.buttonStyle}>
  <Text style={styles.textStyle}>Graph 1</Text>
</Pressable>
<Pressable
  onPress={() => transitionStart(1)}
  style={styles.buttonStyle}>
  <Text style={styles.textStyle}>Graph 2</Text>
</Pressable>

Our final result is the graph in this GIF 📈!

Final Thoughts

I hope you enjoyed this exercise and through it were able to learn more about D3 Charts and React-Native Skia. I am doing my best as a community member to raise awareness about the power of D3. There’s really no need for the pre-built chart libraries when we have them at our disposal. Until next time, happy coding.

More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter and LinkedIn. Check out our Community Discord and join our Talent Collective.

D3 Charts and React Native Skia for Beginners was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

In the last article, we implemented and enabled TurboModules in Android. If you haven’t completed that blog yet, you’ll need to go back and finish it before starting this one. The previous article contains additional instructions you need to complete in TypeScript code. This article will deal with how to get things up and running in iOS. As usual, if you ever get stuck you can check out the GitHub repo here. If you prefer visual learning, you may want to check out my YouTube tutorial on this subject. To recap the last post a bit, we are building the following app that can call into the Native layer using a TurboModule and print a message.

Updating our package.json

iOS requires an extra step in the React side to get things up and running. iOS doesn’t have the same ability as gradle to find folders so we need to specify the path to the Spec file in the package.json. You can do this by adding the following code to the end of the file:

"codegenConfig": {
  "libraries": [{
    "name": "NativeSampleModule",
    "type": "modules",
    "jsSrcsDir": "./js"
  }]
}

Enabling Codegen on iOS

Next, we’ll need to enable the new architecture on iOS. You can do this by opening the ios folder in Xcode then going to Build Settings. Find the section Other C++ Flags under Apple Clang — Custom Compiler flags and add -DRCT_NEW_ARCH_ENABLED=1.

We now have to run a special pod install command for everything to work with the new architecture:

RCT_NEW_ARCH_ENABLED=1 pod install

You should see a bunch of new architecture libraries being installed.

Hooking up Objective-C to React-Native

Now that everything’s been enabled we can move on to writing our native code. We start by adding a Podspec file to the js folder. We do this because Cocoapods are used to manage the TurboModule ecosystem and iOS needs to be aware that you are installing a module. Call the file NativeSampleModule.podspec and copy and paste the following contents:

folly_version = '2021.06.28.00-v2'

folly_compiler_flags = "-DFOLLY_NO_CONFIG -DFOLLY_MOBILE=1 -DFOLLY_USE_LIBCPP=1 -Wno-shorten-64-to-32"

Pod::Spec.new do |s|
  s.name = "NativeSampleModule"
  s.version = "0.0.1"
  s.summary = "NativeSampleModule"
  s.description = "NativeSampleModule"
  s.homepage = ""
  s.license = "MIT"
  s.platforms = { :ios => "11.0"}
  s.author = ""
  s.source = { :git => "https://github.com/facebook/react-native.git", :tag => "#{s.version}"}
  s.source_files = "./**/*.{h,m,mm,swift}"
  s.compiler_flags = folly_compiler_flags
  s.pod_target_xcconfig = {
    "HEADER_SEARCH_PATHS" => "\"$(PODS_ROOT)/boost\""
  }
  s.dependancy "React"
  s.dependancy "React-RCTFabric"
  s.dependancy "React-Codegen"
  s.dependancy "RCT-Folly", folly_version
  s.dependancy "RCTRequired"
  s.dependancy "RCTTypeSafety"
  s.dependancy "ReactCommon/turbomodule/core"
end

Now if we run RCT_NEW_ARCH_ENABLED=1 pod install again we should be able to generate the bindings for Objective-C. If you see something like this it means the Codegen succeeded:

[Codegen] >>>>> Processing NativeSampleModule

[Codegen] Generated schema: /var/folders/70/796_sfnj3xn48tzsx0tzz4g80000gn/T/NativeSampleModuleJbRobp/schema.json

[Codegen] Generated artifacts: TurboModuleSampleProject/ios/build/generated/ios/NativeSampleModule

Back in Xcode right click the project and select Add files to TurboModuleExampleProject:

Next look for ios > build > generated > ios > NativeSampleModule. Make sure Create Groups is checked and click add:

At this point you should see the NativeSampleModule package under your TurboModuleSampleProject:

Now create a header file and an Objective-C++ file called RCTNativeSampleModule. In the header file you’ll want to add the following code:

#ifndef RCTNativeSampleModule_h
#define RCTNativeSampleModule_h

#include "NativeSampleModule.h"

@interface NativeSampleModule : NSObject<NativeSampleModuleSpec>
@end

#endif /* RCTNativeSampleModule_h */

Finally, let’s finish things off by making the methods in the Objective-C++ file. The contents of RCTNativeSampleModule.mm should be as follows:

#import <Foundation/Foundation.h>

#include "RCTNativeSampleModule.h"

@implementation NativeSampleModule
RCT_EXPORT_MODULE()

- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params {
  return std::make_shared<facebook::react::NativeSampleModuleSpecJSI>(params);
}

- (NSString *)getHelloWorld:(NSString *)first second:(NSString *)second {
  return [NSString stringWithFormat:@"HelloWorld %@ %@", first, second];
}

@end

Now if you compile with yarn ios we should be able to tap the button and see the alert message.

Conclusion

So there’s your introduction to TurboModules in React-Native. I am excited for the architecture to move forward with these better tools for calling into native code. Until next time, happy hacking!

More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter and LinkedIn. Check out our Community Discord and join our Talent Collective.

iOS Guide to TurboModules in React-Native for Early Adopters was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

When using React Native earlier, we would communicate between the “Native” layer of our application and the “JavaScript” layer using the JavaScript Bridge. Although the bridge served its purpose, it had a few major issues.

First, the bridge was asynchronous meaning it batched several calls to the native layer and would invoke them at a set interval. If this wasn’t enough, on the native side you had to serialize and deserialize data coming to and from the bridge. These two operations together made things quite slow.

Second, the bridge was not type safe. You pretty much passed whatever you wanted across the bridge and it was up to the native layer to do something to process that data. Finally, at app startup, all native modules needed to be loaded into memory. This meant slow startup times for users.

The creators of React Native have introduced Codegen and TurboModules to solve these problems. TurboModules address the async and loading issues because they behave in a synchronous way in JavaScript and lazy load into memory allowing the app to start faster.

Codegen addresses the problem with type safety because it allows us to generate interfaces we can use to make sure our native code stays in sync with the data we are passing in from the JavaScript layer.

This guide will show you how to use Codegen and TurboModules together with React Native in Android. The second article in this series will address doing the same thing in iOS. Note that this is an early adopters guide intended for React Native 0.68.2 to 0.69.0. The new React Native Architecture is still in flux and may change over time. If you get stuck, feel free to have a look at my sample project here. If you are interested in my video tutorial on this subject, checkout my video here.

EDIT: Users of React-Native 0.69.0 will see false errors in Android Studio stating that imports cannot be found. I’ve complained about this issue here and Meta seems to be aware of it. If you follow these instructions and take imports from my sample project when needed the app will still compile just fine. The Android Studio errors are from a bug in their IDE not in this code. It might make sense to do this tutorial in Visual Studio code so you can avoid the Android Studio error noise.

What are we building?

In this article, we are going to build a simple app that calls into a TurboModule which prints a message. Simple, I know, but with Codegen you can create functions as complex as you like after reading this blog. It will look like this:

The React Native Setup

Start by generating a TypeScript project using the following command:

npx react-native init TurboModuleSampleProject --template react-native-template-typescript

It’s important we use TypeScript because Codegen requires that we use types. A vanilla JS project will not do here.

Next, let’s create a folder called js at the root of the project. Inside js we are going to create a file called NativeSampleModule.ts. Be very careful to always prefix the name of your file and the Module with the word Native. If you don’t do this, Codegen won’t be able to find your code and won’t generate anything. It doesn’t give you any error here and fails silently. Finish up by copy and pasting this code into your file.

import type {TurboModule} from 'react-native';
import {TurboModuleRegistry} from 'react-native';

export interface Spec extends TurboModule {
  getHelloWorld(first: string, second: string): string;
}

export default TurboModuleRegistry.getEnforcing<Spec>('NativeSampleModule');

Android Gradle Setup

In Android, we start by going to the app level build.gradle and adding this line to the top of the file

apply plugin: "com.facebook.react"

After that, we need to tell Android where our Codegen file is. We do that by adding this code to line 88

react {
  jsRootDir = rootProject.file("../js/")
}

Next, find the property enableHermes and set it to be true. The new architecture for React-Native will not run unless you are using Hermes. After that, uncomment the line:

preBuild.dependsOn("generateCodegenArtifactsFromSchema")

Finally, go to the gradle.properties and set newArchEnabled=true

Run yarn android to generate the files we need

Writing our Java Code

Now that we have our build configured and have generated the bindings for JavaScript functions let’s open the android folder in Android Studio and write some native code.

Start by locating the com.turbomodulessampleproject package

Under that package create a new file named NativeSampleModuleImpl.java . Inside this file we are going to extend the interface created by Codegen. It will look like this.

package com.turbomodulesampleproject;

import androidx.annotation.NonNull;

import com.facebook.fbreact.specs.NativeSampleModuleSpec;
import com.facebook.react.bridge.ReactApplicationContext;

public class NativeSampleModuleImpl extends NativeSampleModuleSpec {

    public static String NAME = "NativeSampleModule";

    public NativeSampleModuleImpl(ReactApplicationContext reactContext) {
        super(reactContext);
    }

    @Override
    public String getHelloWorld(String first, String second) {
        return "HelloWorld: " + first + " " + second;
    }

    @NonNull
    @Override
    public String getName() {
        return NAME;
    }
}

Next, we'll want to add our package to the application host. To do this find the newarchitecture directory under the turbo modules package from above and look for the MainApplicationReactNativeHost.java file. Override the getPackages method as follows. Import any classes you need with alt + enter

@Override
protected List<ReactPackage> getPackages() {
  List<ReactPackage> packages = new PackageList(this).getPackages();

  packages.add(new TurboReactPackage() {
    @Nullable
    @Override
    public NativeModule getModule(String name, ReactApplicationContext reactContext) {
      if (name.equals(NativeSampleModuleImpl.NAME)) {
        return new NativeSampleModuleImpl(reactContext);
      } else {
        return null;
      }
    }

    @Override
    public ReactModuleInfoProvider getReactModuleInfoProvider() {
      return () -> {
        final Map<String, ReactModuleInfo> moduleInfos = new HashMap<>();
        moduleInfos.put(
                NativeSampleModuleImpl.NAME,
                new ReactModuleInfo(
                        NativeSampleModuleImpl.NAME,
                        NativeSampleModuleImpl.NAME,
                        false, // canOverrideExistingModule
                        false, // needsEagerInit
                        true, // hasConstants
                        false, // isCxxModule
                        true // isTurboModule
                )
        );
        return moduleInfos;
      };
    }
  });


  return packages;
}

Writing the C++ Code

The last step we’ll need to take here is configuring the C++ side of things. Start by locating the Android.mk file at this path.

TurboModuleSample/android/app/src/main/jni/Android.mk

Then uncomment the Codegen paths as follows:

include $(GENERATED_SRC_DIR)/codegen/jni/Android.mk

then

LOCAL_C_INCLUDES += $(GENERATED_SRC_DIR)/codegen/jni
LOCAL_SRC_FILES += $(wildcard $(GENERATED_SRC_DIR)/codegen/jni/*.cpp)
LOCAL_EXPORT_C_INCLUDES += $(GENERATED_SRC_DIR)/codegen/jni

At the bottom add your library. It should be named react_codegen_AppSpec it will look like this:

LOCAL_SHARED_LIBRARIES := \
  react_codegen_AppSpec \
  libfabricjni \
  libfbjni \
  libfolly_futures \
  libfolly_json \
  libglog \
  libjsi \
  libreact_codegen_rncore \
  libreact_debug \
  libreact_nativemodule_core \
  libreact_render_componentregistry \
  libreact_render_core \
  libreact_render_debug \
  libreact_render_graphics \
  librrc_view \
  libruntimeexecutor \
  libturbomodulejsijni \
  libyoga \

Then in the android/app/src/main/jni/MainApplicationModuleProvider.cpp file add #include <AppSpec.h> and uncomment and replace the following lines:

#include <AppSpec.h>

....

auto module = AppSpec_ModuleProvider(moduleName, params);
if (module != nullptr) {
    return module;
}

At this point lets run yarn android to make sure the app compiles.

The Triumphant Return to React Native

Let’s finish up by testing everything out. Anywhere in your App.tsx file add the following code.

import NativeSampleModule from './js/NativeSampleModule';

...
const showMessage = () => {
  const message = NativeSampleModule.getHelloWorld('Daniel', 'Friyia');
  alert(message);
};

...
<Button title="Click here" onPress={showMessage} />

When you click the button you should see an alert pop up with the message we created in the native layer.

Conclusion

Hopefully, you enjoyed this introduction to TurboModules in React Native for Android. Soon enough they will be removing the old bridge so it’ll be important for us to stay up to date with how TurboModules are coming along. Please check out part two where I show you how to get TurboModules and Codegen to work on iOS.

More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter and LinkedIn. Check out our Community Discord and join our Talent Collective.

Android Guide to TurboModules in React Native for Early Adopters was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Now for the moment, we’ve all been waiting for! Setting up the JSI to work with Android. If you haven’t yet, please read Part 1 of this series to see how to set things up in iOS.

Special thanks again to Oscar Franco for this article. Although I haven’t seen any content from him on the Android side of things I rummaged through his “Quick SQLite for React-Native” library to figure out how to do everything. He is the true master of this tech, not me, I am just a humble instructor. Feel free to rummage through his code after this article to learn more. Hopefully, I can give you the tools to do so!

GitHub - ospfranco/react-native-quick-sqlite: Fast SQLite for react-native.

Remember, this is a really hard process. If you get stuck check out the GitHub project here. I will refer back to it a lot because this article requires a lot of long files.

🚨 NOTE: If you are on an M1, you’ll need to follow these additional steps before starting the article.

Setting up the Android Build System

Remember how in iOS we started writing C++ code out of the box? Unfortunately, in Android, this is not the case. C++ development is a kind of second-class citizen where Android Studio forces you to set up all the build steps manually.

Configuring the build.gradle

The first thing we are going to do is update thebuild.gradle file at the library level with some new code. At the top of the file add these two imports:

import org.apache.tools.ant.filters.ReplaceTokens
import java.nio.file.Paths

Next, update your gradle tools to the following:

classpath 'com.android.tools.build:gradle:4.2.2'

Add this code to the file before the android block. We’ll use it later to get the path to the node_modules.

Add this code right after the function so that we can use the React-Native version in our build later on. We’ll also be using this to pass the path to all the Facebook React-Native libraries into the C++ build system.

Under the externalNativeBuild block in the defaultConfig copy and paste this cmake command. Notice we use the node module path and React-Native version here. We are actually passing these values to the C++ build system for Android.

Add packaging options to the top level of the gradle file. It will prevent duplicate facebook RN libraries from being generated.

Finally, add this code for configurations we are going to write this code in a moment, but it's code that executes during the build steps.

configurations {
  extractHeaders
  extractJNI
}

Under repositories add the following code which finds the React-Native Android sources.

Then under dependencies add this code so that we can extract the JNI files for React-Native and add them to the project.

Finally, copy and paste these functions at the bottom of the file. These facilitate the addition of JNI files to the project.

Normally, at this point, I would show you the whole thing together. Unfortunately this time we’ve made a massive file. Don’t worry though, you can have a look at this all together in my GitHub repo here.

Setting up the Android C++ Build System

With the CMakeLists.txt file we are just going to start from scratch. Most likely you’ve never made one of these before and it's really intimidating. Don’t worry about it though. These are actually pretty easy to understand once someone has talked you through them. Let's start by setting up a few variables:

Next, we’ll have to set a few more variables if you are using a React Native version of less than 68.

After this, we’ll have to tell the C++ build system which directories we want to require files from. At the top, we put our cpp folder then follow this up with a list of all the libraries we want to include.

We then have to add libraries to our build. We do this with the following code.

Next, tell the build where our included directories can be found. You’ll find this list is similar to the one earlier.

At this point, we are going to finish up by adding libraries to our build and assigning those libraries to variables. You can do this as follows:

Finally, we finish up by linking all these libraries when the build completes.

target_link_libraries(
  ${PACKAGE_NAME}
  ${LOG_LIB}
  ${JSI_LIB}
  ${REACT_NATIVE_JNI_LIB}
  ${FBJNI_LIB}
  android
)

Again this file is crazy long. To see all this code together check out my GitHub repo here.

Adding your First Android C++ Code

To get everything to compile, go to your cpp-adapter.cpp file and add this code:

#include <jni.h>
#include <jsi/jsi.h>
#include <fbjni/fbjni.h>
#include <ReactCommon/CallInvokerHolder.h>
#include <typeinfo>
#include <android/log.h>
#include "react-native-teaching-jsi.h"

using namespace facebook;

JNIEXPORT jint JNI_OnLoad(JavaVM * vm, void * ) {

}

At this point run your app and make sure it compiles. Awesome right! You’ve built your first C++ library! Unfortunately, your app will instantly crash on launch 🙃. Isn’t the Android C++ build system great?

Finishing up the CPP Adapter

Just like in iOS we need to run some code to tell the app that we are installing a function in the global JS object. We start this by creating a struct in cpp-adapter.cpp. Note the use of installMath this is the C++ function we wrote in Part 1.

Be very careful about the kJavaDescriptor variable. That string has to match the path to your Java package. If you didn’t copy my naming you’ll need to adapt this to your app. If it’s wrong, the app will crash frequently and it will be hard to debug.

After that, we call the initialize function when the app starts.

The app will still crash if you try and compile it, however, that should take care of all the C++ we need. To double-check your code have a look at this file. In the next section, let's fix this crash and get everything up and running.

Writing our Java Code to Link with JavaScript

I wish I could tell you the weirdness of setting up the C++ part of this build ended there, but unfortunately that's not the case. We now need to set up the Java code that links the C++ code to the JS engine.

The Android Native Java Class

The first thing we’ll do is create a class called AndroidNative. It's going to act as the interface between Java and C++. Start the file off by adding these imports:

Next, add this code:

Note the use of public native void here. Methods marked native in Java can call directly into C++. We are going to be using that method to “install” our C++ methods into the JS global object.

Add these lines to the file because they are required by the React-Native framework:

public AndroidNative(ReactApplicationContext reactContext) {
  super(reactContext);
}

@Override
@NonNull
public String getName() {
  return NAME;
}

Finish up by adding the install method. This loads the C++ library and calls the install function. Note the use of isBlockingSynchronousThread. This needs to be set to true in order to have the library load at app startup.

Making the JSI Module Package

At this point, we’ll use the code from the previous section. Really all it does is get our native module and call the install function we created earlier.

Making the React Package

The last of the code we need to write is the React Package which is what allows React-Native to see our code. We simply create this file and add our Android Native class to it.

Add Library to your Example App

Add this code to the React Native host in your MainApplication.java file in the example app.

import com.facebook.react.bridge.JSIModulePackage;
import com.reactnativeteachingjsi.TeachingJsiModule;
import com.reactnativeteachingjsi.TeachingJsiPackage;

public class MainApplication extends Application implements ReactApplication {

  private final ReactNativeHost mReactNativeHost =
      new ReactNativeHost(this) {

        @Override
        protected JSIModulePackage getJSIModulePackage() {
          return new TeachingJsiPackage();
        }

You’ll also want to change the package in MainApplication to be:

@Override
protected List<ReactPackage> getPackages() {
  @SuppressWarnings("UnnecessaryLocalVariable")
  List<ReactPackage> packages = new PackageList(this).getPackages();
  // Packages that cannot be autolinked yet can be added manually here, for TeachingJsiExample:
  // packages.add(new MyReactNativePackage());
  packages.add(new TeachingJsiModule());
  return packages;
}

Check out the entire MainApplication.java file here.

Conclusion

At this point if you run the app you should see the following:

Wow, that was a lot of work, wasn’t it? I personally can’t wait until the JSI libraries are ready for general consumption so we don’t have to do all this. Either way, I hope you enjoyed the journey and have fun hacking with the base project 🙂.

More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter and LinkedIn. Check out our Community Discord and join our Talent Collective.

React Native & the JavaScript Interface: A Guide for Early Adopters was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

My journey as a programmer began around the time smartphones became popular. I can still remember the excitement I felt compiling my first hello world app on an Android phone at university. As my career progressed, I worked with Bluetooth Low Energy, and C++ libraries, and wrote highly optimized apps. Nothing is as exciting to me as getting the most I can out of the hardware I am working on.

In React-Native, this was hard to do for a long time because we had to pass values back and forth across the JavaScript bridge. Fortunately, the team at Meta recently exposed JavaScript Interface (JSI) modules. JSI Modules can call native functions synchronously through shared memory.

Although JSI Modules are not yet in a state where they are ready for general consumption, they are powerful enough to experiment with and prepare for when the real thing is released.

This article is the first of a two-part series. The goal of this series is to make a quick, easy, copy-paste guide to JSI modules so you can start experimenting with them as soon as possible. As far as I can tell, nothing like this exists in the community and is sorely needed.

Part 1 is based on the YouTube playlist by Oscar Franco on setting up JSI with iOS. If you want a long, in-depth explanation of things, I recommend you go here and check out his channel.

Part 2 no one has talked about as far as I can tell. This is setting up JSI Modules for Android. Never fear though, I’ve labbed 🧑‍🔬 out this process for you and will explain everything there.

Remember, if you get stuck, check out the GitHub project here.

What are we building today?

As always, I want to explain what we are building before we build it. Today’s project will seem, at face value, a little boring. That being said, this project is really about learning to set up the JSI. Once you have that knowledge you can make modules as complex as you like.

Here we are creating an app to calculate the Greatest Common Denominator using a C++ function that will be shared between Android and iOS.

Generating the Library Boilerplate

Currently, there is no easy way to generate a JSI library. Instead, what we are going to do is generate a JavaScript bridge library and migrate it over to a JSI lib. The first thing you’ll want to do is run this command:

npx create-react-native-library react-native-teaching-jsi

You can just hit enter until you get to this menu:

Make sure you select C++ for Android and iOS here. This will make sure all the C++ code we write is fully cross-platform.

Remove Flipper for Faster Compilation (Optional)

Before starting, I recommend you comment on Flipper in your example/Podfile. It has a lot of broken releases and sometimes causes things to not compile. When you are done with the tutorial you can always circle back and try to set it up if you feel inclined.

Making the Cross-Platform Code

After generating the template, you’ll want to start by running yarn in the root of your project to install all the dependencies. Next run open example/ios/TeachingJsiExample.xcworkspace from the project root to open Xcode in the project example. It will seem strange to most but we’ll be editing our Pods from there. We do this so Xcode can give us auto-complete functionality. I recommend trying to run the app from Xcode at this point to make sure everything is working properly. You should see a blank screen with the text “Result: 21”.

Next, find the library files in Xcode under Pods/Development Pods. It will look like this.

Update the contents of the react-native-teaching-jsi.h file to the following:

#ifndef react_native_teaching_jsi_h
#define react_native_teaching_jsi_h

#include <jsi/jsilib.h>
#include <jsi/jsi.h>

using namespace facebook;

void installMath(jsi::Runtime &rt);

#endif /* my_cpp_module_hpp */

Next, move over to the react-native-teaching-jsi.cpp file. Here we are going to write our shared function to calculate Greatest Common Denominator in C++. Pretty cool right?

Let’s start by using the facebook namespace and writing a fast GCD function. It will look like this.

#include "react-native-teaching-jsi.h"

using namespace facebook;

int computeGcd(int a, int b) {
  while (b) b ^= a ^= b ^= a %= b;
  return a;
}

Surely by now, you must be curious. How do we tell JavaScript/TypeScript that this function exists? The way this happens is by getting access to the JavaScript runtime and “installing” the various functions you want to use in the JS Global object. Before we do that though we need to create the install function that registers compute gcd.

Add this function to your react-native-teaching-jsi.h file.

I am sure that function is quite a lot to digest 😅 so let's break it down.

void installMath(jsi::Runtime & rt) {

The function header takes in a reference to the jsi::Runtime. This is required to access the JS engine and call our functions from JavaScript.

auto propId = jsi::PropNameID::forAscii(rt, "gcd");

The prop id is just a unique id for our function.

auto lamda = [](jsi::Runtime & rt,
    const jsi::Value & thisValue,
    const jsi::Value * args,
    size_t count
  ) -> jsi::Value {
    auto data = args->asObject(rt);
    auto aValue = data.getProperty(rt, "a");
    auto bValue = data.getProperty(rt, "b");
    int a = aValue.asNumber();
    int b = bValue.asNumber();
    int gcd = computeGcd(a, b);
    return jsi::Value(gcd);
  };

The code above is where things get interesting. This C++ lambda function extracts data from the JavaScript Interface and converts it into primitive values we can use. We use the utility methods asObject and getProperty to convert the raw data into data types that can be processed by C++.

jsi::Function gcd = 
      jsi::Function::createFromHostFunction(rt, propId, 2, lamda);

rt.global().setProperty(rt, "jsiGcd", gcd);

We then finish up by calling rt.global() which tells JavaScript we want to register this function on the global module.

Registering the Function on the JavaScript Runtime

The last step we need to take before calling this function from JavaScript is to install our function in the JavaScript runtime. We need to write a little bit of Objective-C code here. This Obj-C code is really just the glue between C++ and JavaScript.

Under the iOS directory, find the TeachingJsi.h file and add the following code:

@interface TeachingJsi : NSObject <RCTBridgeModule>
  @property(nonatomic, assign) BOOL setBridgeOnMainQueue;
@end

This tells Objective-C you will be registering the function on the main thread which is required for the JSI to work.

Once you’ve completed this go into your TeachingJsi.mm file. Start by adding these imports:

#import <React/RCTBridge+Private.h>
#import <React/RCTUtils.h>
#import <jsi/jsi.h>
#import <ReactCommon/CallInvoker.h>
#import <memory>

Then under @implementation add this code:

@synthesize bridge = _bridge;

After exporting the module you’ll want to tell Objective-C that you will be registering your method on the main thread:

+ (BOOL)requiresMainQueueSetup {
  return YES;
}

Next set up the bridge:

- (void)setBridge:(RCTBridge *)bridge {
  _bridge = bridge;
  _setBridgeOnMainQueue = RCTIsMainQueue();
  RCTCxxBridge *cxxBridge = (RCTCxxBridge *)self.bridge;
  
  if(!cxxBridge.runtime) {
    return;
  }
  installMath(*(facebook::jsi::Runtime *) cxxBridge.runtime);
}

Finish off by deleting all other code in the file. Everything together should look like this:

Finishing things off

The last thing you’ll want to do is check that all the code we’ve written so far works as expected. Since this isn’t an article on how to make UIs, just copy and paste my UI code into your App.tsx.

Your final result should be something like this:

Conclusion

And there you have it! Setting up JSI with iOS. Stay tuned for Part 2 where I’ll be going over how to get this to work with Android. Fair warning, that article isn’t going to be anywhere near this easy. If you haven’t worked with the Java Native Interface (JNI) or CMakeLists before it’ll be a bit of a ride. I promise though that it’ll be fun and really interesting 🙂. Look forward to seeing you there!

More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter and LinkedIn. Check out our Community Discord and join our Talent Collective.

React Native & the JavaScript Interface: A Guide for Early Adopters was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by: Daniel Friyia, Agile Software Engineer, TribalScale

📫 Subscribe to receive our content here.

💬 Have any questions about transforming a swift codebase to MVVM? Click here to chat with one of our experts!

We’ve all been there, you get put in charge of a codebase written by another group of developers and you have to maintain it. Problem is, all those developers left the company awhile ago and you have no idea why any decisions were made. This isn’t always a bad experience. I can think of times where developers before me made good decisions and it was easy to dive in and start making changes 🙂. Recently though, my team had a really negative experience with a messy codebase that had basically no architecture to speak of 😞. In this article I’ll be talking about how we went about refactoring this app piece by piece into something we could maintain. Obviously every codebase is different so this article isn’t meant to be a strategy for all refactors. That being said, I hope you’ll pick up a few good ideas from our experience that you can implement when doing architectural refactors in your project.

Diagnosing the Health of an Inherited Codebase

When starting out with any project it’s first important to understand what we are dealing with. Obviously there can’t be any meaningful changes until we can identify what parts of the app are well built and which are not. When assessing a new codebase I like to think in terms of, what I feel, are the five pillars of any mobile or front-end project: User Interfaces, Navigation, State Management, Networking and Peripheral Management. Through this framework, I can get a feel for the app’s architecture and overall code health. There were the results of our diagnosis:

User Interface Development ✅

In our case this app was written in Swift so it wasn’t a legacy project or anything. When building user interfaces, the previous developers used XIB files in combination with Swift View-Controller files. This was a bit annoying because the team had mostly worked with storyboards, but it wasn’t technically wrong or anything, so we felt we could leave this as-is.

Navigation ❌

This app had no structured form of navigation. Because we weren’t using storyboards, we had no segues. The previous developers were simply getting the UIApplication root view controller and replacing it. Code snippets like this were randomly all over the place.

let vc = MyViewController()
UIApplication.shared.theKeyWindow?.rootViewController = vc

We would need to fix navigation before making any progress.

State Management ❌

The state management of this code base was a crude form of Model-View-Controller (MVC). Although there are structured ways to do MVC, the developers before us didn’t use it. There were view controllers of 3000+ lines that were hard to navigate through. It would be important to create shorter, more focused files before moving forward.

Networking ✅

The networking layer was another part of this app we didn’t feel needed rework. This is because the app used GraphQL and Apollo which generates most of the queries based on the schema you provide. Even if we wanted to re-write large portions of this, we wouldn’t be able to.

Peripheral Management ❌

The final layer we assessed was the peripheral connection layer. This app used a Bluetooth device. The previous developers only exposed Bluetooth to one part of the app. Future feature development would require Bluetooth to be exposed to the entire app, so this piece wasn’t where it needed to be.

If I was to diagram the early architecture it would probably look something like this:

The architecture taken at face value seems simple. But it’s the lack of focused classes and objects that was leading to overloaded view controllers that were verbose and challenging to navigate.

The Refactor Begins

We diagnosed the app with having three main problems: state management, navigation and peripheral management. After fixing some initial bugs and negotiating refactor time with the client, we were off the the races.

Choosing Model-View-View-Model (MVVM)

The first decision we made as a team was that we were going to refactor to MVVM. As you’re probably aware, VIPER is another strong candidate for state management. Problem is, we only had a month or so for this refactor and it would take too long to build out the more sophisticated VIPER. Although MVVM is not as flexible as VIPER, it's no slouch. MVVM would enable us to separate our view logic from our business and navigation logic, effectively hitting two birds with one stone.

Refactoring Navigation

Once we were set on using MVVM, the first thing we needed to do was to fix the navigation structure of the app. The app was making screen transitions like this on the old architecture:

let vc = MyViewController(
  val1: 1
  val2: 2
)
UIApplication.shared.theKeyWindow?.rootViewController = vc

This meant that navigation logic and building view controllers were taking place in the host View Controller. Without a clear separation of concerns between navigation and the View Controllers, it would be impossible to make any progress on View Models.

We chose to use the coordinator pattern of navigation which allowed us to keep our navigation functionality in one place. For those who have never used the coordinator pattern before, it’s basically a way of managing access to navigation functions on a global UINavigationController. We paired this with an extension to the UINavigationController that allowed us to simplify navigation primitives such as pushing, popping, and presenting modals. At this point we could set up navigation using a pattern like the following:

func goToNewScreen(param1: AnyParam) {
  let sampleVM = SampleViewModel(
    param1: param1,
    networking: self.networkingLayer,
    user: self.userModel
  )
  let sampleCV = SampleViewController(viewModel: sampleVM)
  self.push(sampleVC)
}

Then in the View Controller:

class MyViewController {
  ...
  func transition() {
    self.coordinator.goToNewScreen(
      param1: sampleParam
    )
  }
}

At this point two of our problems were solved.

1. We no longer had our business logic entangled with our view logic like what you see in the MVC pattern.
2. We were able to remove navigation logic from view controllers. If I were to make a diagram at this point it would look like this:

There is definitely a lot more going on in this diagram, however, the app had a much better separation of concerns at this point. The Navigation Coordinator handled navigation, View Models handled business logic, View Controllers handled View Logic and the networking layer handled networking.

Peripheral Management

The final part of this project that needed rework is the peripheral layer. It was a Bluetooth object that was available in only one part of the app. To fix this, we started by transforming it into a singleton. This wasn’t enough though, we still needed to be able to access the delegate methods of Bluetooth from different screens. To do this, we created a superclass for all View Controllers that required Bluetooth connectivity. Extending this class would allow all core controllers to have access to Bluetooth without having to rewrite the protocol methods in all delegates over and over again.

Final Thoughts

In the end, the app architecture ended up looking like this:

As you can see there are a lot more layers to this app than we started out with. This ends up being a strength because every part of our codebase has a defined purpose. This makes the system not only easier to extend, but a lot easier to explain to stakeholders in plain English when the need arises.

Thanks for giving this a read! This refactor was actually quite fun and really allowed us to flex our OOP muscles. Hopefully hearing our story will empower you to make some of these decisions in your next major refactor.

Daniel is an Agile Software Developer specializing in Flutter and React-Native. As much as he likes cross platform, he is passionate about all types of mobile development including native iOS and Android and is always looking to advance his skill in the mobile development world.

TribalScale is a global innovation firm that helps enterprises adapt and thrive in the digital era. We transform teams and processes, build best-in-class digital products, and create disruptive startups. Learn more about us on our website. Connect with us on Twitter, LinkedIn & Facebook!

Transforming a Messy Swift Codebase to MVVM — A Case Study was originally published in TribalScale on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently, I was working on an app that required access to YouTube videos. To my surprise, there wasn’t much in the way of good libraries on NPM. After taking a deep dive on YouTube and React-Native development, I realized that YouTube wants you to just use their embed.

This posed an interesting problem.

If we were working in browser-based JavaScript, it would be trivial to just copy and paste the JS from the YouTube documentation. When working on mobile though, we don’t have the same luxury. Luckily, the WebView in React-Native provides a robust API that allows us to communicate between mobile and the WebView’s browser.

In this blog, I’ll be explaining how we can take advantage of that API to create a YouTube component we can control from React-Native. As always, if you get stuck at any point, check out the complete project repo here.

What Are We Building?

Today, we’ll be building this simple app that plays videos through the YouTube embed. You’ll learn how to display videos as well as how to communicate between the WebView’s JavaScript and React-Native.

Getting Started

The first thing you’ll want to do is generate an empty TypeScript project using this command:

npx react-native init YoutubePlayer --template react-native-template-typescript

After generating the project, run the following command to install the react-native-webview:

npm i react-native-webview

Finish up by installing the new Cocoapods in your project.

cd ios && npx pod install

Writing the Markup

When using a complex web component like the YouTube player, we can’t just pop in a URL and watch the WebView work. In order to support such a feature-rich component, we need to use the YouTube embed.

I recommend starting by creating a file called iFrame.tsx under your src directory. After creating this file, we can start by making a function called buildIFrame. This function will build the embed part of our HTML code.

Start by adding a player div that we can use as a target for the embed.

const buildIFrame = (videoId: string) => `
  <div id="player"></div>

Next, we’ll want to build the script that makes the YouTube player appear. We start by loading the iFrame player code asynchronously.

...
var tag = document.createElement('script');
tag.src = "https://www.youtube.com/iframe_api";
var firstScriptTag = document.getElementsByTagName('script')[0];
firstScriptTag.parentNode.insertBefore(tag, firstScriptTag);
...

At this point, we need to create the YouTube player and target the player div we created. We do this as follows:

The videoId will be passed in a bit later, but for now, you can get the screen width from the React Native dimensions like this.

import {Dimensions} from 'react-native';
const {width} = Dimensions.get('window');

Your buildIFrame function so far should be as follows.

The next step is to style our iFrame. Keep in mind the styles for this are pretty specific. This is because we want the iFrame to fill its parent view.

Finally, let's create a method that takes in a videoId from YouTube and uses it to build the entire iFrame HTML page.

Creating the Component

Now that we have the markup we need, let's create the WebView Component. Navigate back to your App.tsx file. At this point, you want to import the WebView component and use it along with the buildHTML function we just finished creating. Altogether, the file should look like this:

At this point, you should be able to watch the video if you tap on it.

Building the Controls

To create the controls we are going to add more code to the buildIFrame function from earlier. On the web, the YouTube player gives you access to several functionalities. The ones we use in this project are playing and pausing the video, seeking to a time, and getting the current time in the video.

We wrap these functionalities in JavaScript browser functions so we can call them from React-Native later on. After doing this, your buildIFrame will take this form.

Back in the App.tsx file, we have the trivial task of wrapping these functions in React-Native functions so that we can call them in the browser. Start by grabbing a ref to the WebView.

const webRef = useRef<WebView>(null);
...
<WebView
  ref={webRef}

After that, you can call whatever JavaScript functions you want on the WebView. Here are the ones we’ll use for this project:

const playVideo = () => {
    webRef.current?.injectJavaScript('play()');
};

const pauseVideo = () => {
    webRef.current?.injectJavaScript('pause()');
};

const restartVideo = () => {
    webRef.current?.injectJavaScript('seekTo(0)');
};

If we throw in a few buttons and some light styling, our component ends up in its penultimate form.

We’re almost there! At this point, you should be able to play the video with the controls.

Displaying the Timer

The last thing we’ll want to do is display the timer. To do this, we’ll have to post messages from the WebView and send them to React-Native every second or so.

We can add this functionality to our WebView using the postMessage function. You can add this snippet to your iFrame.ts.

setInterval(() => {
  const data = {
    currentDuration: getCurrentTime()
  }
  window.ReactNativeWebView.postMessage(JSON.stringify(data));
}, 1000)

The function should now contain the set interval, shown below:

We can finish up by grabbing these events from the WebView and displaying them using a state. Your final App.tsx will look like this:

Your final result should be this:

Final Thoughts

With YouTube being the primary hosting service on the internet, it’s really important to be able to use it in our apps. Above, I gave you the basics for how to add it to your app.

Feel free to style the controls as you see fit in order to suit your user experience!

Building a YouTube Component Using the React-Native WebView was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

📫 Subscribe to receive our content here.

💬 Have any questions about React-Native? Click here to chat with one of our experts!

The React-Native (RN) community can seem quiet at times. This is especially true if you are new to the ecosystem and don’t know who the key influencers in the community are. Unlike iOS or Android, big developments to React-Native are not met with large conference announcements and fanfare. Instead, they are reliant on social media and developers making recommendations to one another. I sorely wish our community was better at PR when major developments take place, but unfortunately that’s not the case. Knowing this, I thought I would take a break from my usual tutorials and do my civic duty as a member of the React-Native community to promote changes to the ecosystem I think will make a huge difference in 2022.

More progress on the new architecture

The first big development we will see in 2022 is the new React-Native architecture becoming increasingly more mature. I know not everyone is up to speed on what the components of the RN architecture are, so let me explain. The RN refactor has three parts: Turbo Modules, Fabric and Codegen. Turbo Modules allow JavaScript to hold a reference to C++ host objects and manipulate them. Fabric is the new renderer for RN that is meant to increase rendering performance and make Android and iOS UI behaviours more consistent with one another. Finally, Codegen is used to generate native code at build time. A great explanation of this can be found in the React-Native Radio (RNR) Podcast 222 with React-Native’s Engineering Manager Kevin Gozali.

React Native Radio on Twitter: "❤️🖤RNR 222 is out❤️🖤We interview Meta engineer @fkgozali to discuss the React Native new architecture - TurboModules, Fabric, codegen, and whether React Native developers need to go learn C++!@jamonholmgren @jonmajorc @mazenchami #ReactNative https://t.co/EueMCk1mfH / Twitter"

❤️🖤RNR 222 is out❤️🖤We interview Meta engineer @fkgozali to discuss the React Native new architecture - TurboModules, Fabric, codegen, and whether React Native developers need to go learn C++!@jamonholmgren @jonmajorc @mazenchami #ReactNative https://t.co/EueMCk1mfH

In the RNR Podcast, Kevin let us know that up to this point TurboModules and Fabric have been mostly completed. In accordance with his statement, Meta’s React-Native blog just announced that the architecture will be open-sourced this year so that everyone has a chance to try it out. It will be exciting to see all the new libraries and app optimizations that come out of the release!

Moving towards Hermes as default across all React-Native platforms

This next point builds on the last related to the RN re-architecture. Late last year, Meta announced they are working towards making Hermes the default JavaScript Engine on all platforms.

React Native on Twitter: "With community adoption and feedback, @HermesEngine has flourished.Today, we'd like to share all the progress we've made and the case for making Hermes the default engine for React Native.https://t.co/P9mIe8f6KH / Twitter"

With community adoption and feedback, @HermesEngine has flourished.Today, we'd like to share all the progress we've made and the case for making Hermes the default engine for React Native.https://t.co/P9mIe8f6KH

Although Hermes has been available for a while, especially on mobile, it’s great to see it will be a core part of the RN ecosystem moving forward. Hermes is a Meta’s JS engine tailored specifically for running with RN, as opposed to engines like V8 that are optimized for Google Chrome. Using Hermes results in faster app start-up times, less memory usage and smaller apps. Basically, it’s a much welcomed overall buff for the RN ecosystem 😅. I’ve been enabling it on all the demo projects I write for Medium and will be enabling it on all future projects even before it becomes default.

Major improvements to animations

Another big development in the RN community this year is going to be animations. Mid last year we saw the release of React-Native ReAnimated 2 which allowed us to have access to the native UI thread. As the library continues to gain popularity this year, we will see the performance of animations improve by leaps and bounds on lower performance devices where, in the past, RN animations would struggle because of the old bridging architecture.

As if ReAnimated 2 wasn’t enough of a leap forward, a few months ago, development on a new, equally powerful, animations project was announced. Twitter followers of William Candillon and Shopify Engineering will be aware that a new project called React-Native-Skia is being worked on.

Shopify Engineering on Twitter: "A lot of great work happening on #ReactNativeSkia! https://t.co/mg3SY9TBqP / Twitter"

A lot of great work happening on #ReactNativeSkia! https://t.co/mg3SY9TBqP

This library brings Skia functionality to RN. For those who don’t know, Skia is the rendering engine used by Google Chrome, Android and Flutter that gives the user control over every Pixel on the screen. It is especially popular for its two dimensional drawing optimizations. It will be interesting to follow this library’s journey to production readiness this year. I know I’ll be following this work on William Candillon’s YouTube channel.

William Candillon on Twitter: "Is that how they do the mirror dimension in doctor strange? pic.twitter.com/xxkdcsLlyP / Twitter"

Is that how they do the mirror dimension in doctor strange? pic.twitter.com/xxkdcsLlyP

Final thoughts

Thanks for giving this a read! I hope you’ll find this article useful coming into 2022. If there are any parts of the React-Native ecosystem you think will be significant in the coming year feel free to share them in the comments. It would be great to share the cool emerging libraries and technologies everyone is working with.

Daniel is an Agile Software Developer specializing in Flutter and React-Native. As much as he likes cross platform he is passionate about all types of mobile development including native iOS and Android and is always looking to advance his skill in the mobile development world.

TribalScale is a global innovation firm that helps enterprises adapt and thrive in the digital era. We transform teams and processes, build best-in-class digital products, and create disruptive startups. Learn more about us on our website. Connect with us on Twitter, LinkedIn & Facebook!

Why 2022 Will Be a Huge Year for React-Native was originally published in TribalScale on Medium, where people are continuing the conversation by highlighting and responding to this story.

D3.js is the best, most powerful tool we have in React-Native (and maybe even all mobile development) for creating charts and data visualizations 📈. If there is any doubt in your mind I recommend checking out the D3 gallery.

The amazing amount of variety in the gallery demonstrates the versatility of D3 when it comes to visualizing data. D3 is the way to go if you want full freedom over what your data visualizations look like.

I was inspired to write this article because there aren’t many resources that exist on D3 line charts let alone D3 and React-Native. I assume that readers of this post are already familiar with SVG Animations in React-Native.

If not, you can learn about them from my last post here. I want this article to serve as a guide for React-Native developers looking to get into D3 for themselves and start crafting beautiful charts.

What are we Building?

As always with my how-to guides, I like to start by showing what we are building. We will be creating the line chart you see in the GIF below complete with the animation between line graphs.

Getting Started

Unlike my other tutorials, I am going to start this one from a boilerplate. If you want to follow along, you can clone the starter project here. You should be in the main branch at this point.

There won’t be anything to set up since I’ve already installed the ReAnimated and SVG libraries for you. All you need to do is run yarn install and then cd ios && pod install in your terminal from the root of the project. If you get stuck and want to view the solution, check out the solution branch.

Note that the boilerplate does not include all imports. You’ll need to import library values as you go with cmd + . in your VSCode editor. Your project so far should be an empty card with some buttons that looks like this.

Familiarizing Ourselves with the Data

Let’s start by familiarizing ourselves with the structure of our data. Each point has these values:

export type DataPoint = {
  date: string;
  value: number;
};

export const originalData: DataPoint[] = [
  {date: '2000-02-01T05:00:00.000Z', value: 250},
  {date: '2000-02-02T05:00:00.000Z', value: 300.35},
  {date: '2000-02-03T05:00:00.000Z', value: 150.84},
  ...

All the data for this app can be found in the Data.ts file under the src directory. Notice the dates are saved in ISO-8601 string format. This is because ReAnimated for Android isn’t able to handle JavaScript date objects well. The only way to pass our dates to ReAnimated later on will be in the form of ISO date strings. Our values are numbers representing real-life dollar amounts.

Organizing our Data

To build a chart, we need to organize our data so it can be handled by D3. The best way to start things off is to create a method that returns an object with our processed chart data in the App.tsx file.

const makeGraph = (data: DataPoint[]) => {};

The next step we’ll take is calculating the max and min values in our dataset. These values are used to form the y domain of our chart. This is pretty simple to do, we can just feed the values of our data into the Math.max and Math.min methods.

const max = Math.max(...data.map(val => val.value));
const min = Math.min(...data.map(val => val.value));

After that, creating the y axis is as easy as calling scaleLinear in the D3 library. Note the use of GRAPH_HEIGHT in the range. This will ensure all our data points are mapped to y coordinates on the screen that is no greater then the graph’s height.

const y = scaleLinear().domain([0, max]).range([GRAPH_HEIGHT, 35]);

For the x-axis, we know our data is always going to be fifteen days so we’ll set the starting point and ending points at the first and fifteenth of the month respectively. Note the use of GRAPH_WIDTH in the range. Like the y axis, it maps our values to x coordinates on the screen and makes sure they are no greater than the graph’s width.

const x = scaleTime()
    .domain([new Date(2000, 1, 1), new Date(2000, 1, 15)])
    .range([10, GRAPH_WIDTH - 10]);

We then finish off by creating the line chart using the line function from D3.

const curvedLine = line<DataPoint>()
    .x(d => x(new Date(d.date)))
    .y(d => y(d.value))
    .curve(curveBasis)(data);

We return the max, min and curvedLine values from our function. They will be needed soon to draw our chart.

return {
    max,
    min,
    curve: curvedLine!,
 };

Altogether, our makeGraph function should look like this:

Drawing the Graph

The next thing we’ll do is draw our graph. Let's start by adding our first data set to the array of graph data sets in App.tsx.

const graphData: GraphData[] = [makeGraph(originalData)];

Since graphData is already passed into the LineChart component, lets jump back over into the LineChart.tsx file. Start by de-structuring all component values in the method header.

const LineChart: FC<LineChartProps> = ({
  height,
  width,
  data,
  bottomPadding,
  leftPadding,
}) => {

When we called the line method earlier, D3 took in a set of domain and range values and used them to construct an SVG path. Our chart then is really just an SVG we display on the screen. To host our line graph, we add the SVG canvas to our LineChart component.

<Animated.View style={styles.chartContainer}>
  <Svg width={width} height={height} stroke="#6231ff"></Svg>
</Animated.View>

At this point, we’ll see our graph snap into its proper height.

Now we’ll add some gridlines to make the graph stand out a more. We can do this by drawing a few SVG lines.

Note the use of x1, x2, y1, andy2 values here. The first value of x or y is the coordinates of where you want the line to start. The second value for the coordinates is where you want the line to end. Our result will be this empty chart:

Finally, the moment has come, let's place our graph on the canvas. Add the following code to the file under the lines we drew earlier.

<Path d={data[0].curve} strokeWidth="2" />

The result will be a graph that looks as follows.

Your code for the LineChart component so far should look like this:

Animating Multiple Graphs

That was exciting! Not only did we draw our graph to the screen, but we were also able to add guidelines for good measure.

The next phase of this article will focus on switching between multiple line charts and animating those transitions. This section is only possible because of the react-native-redash TypeScript library authored by the Godfather of React Native animations William Candillon.

To start the process of animating our graph, start back in the App.tsx by adding the other datasets to our array of graphs:

const graphData: GraphData[] = [
  makeGraph(originalData),
  makeGraph(animatedData),
  makeGraph(animatedData2),
  makeGraph(animatedData3),
];

You will also need to run redash parse on the curve attribute of makeGraph and adjust your types accordingly.

import {parse, Path as RePath} from 'react-native-redash';
...
export type GraphData = {
  ...
  curve: RePath;
};

const makeGraph = (data: DataPoint[]) => {
  ...
  return {
    max,
    min,
    curve: parse(curvedLine!),
  };
};

Navigate back to your LineChart.tsx file and create a sharedValue for the graph you’ve currently selected. This is also a good time to make a function that can transition between graphs (without animating). Altogether the code should look like this:

const selectedGraph = useSharedValue(data[0]);
const onQuarterTapped = (quarter: number) => {
  selectedGraph.value = data[quarter - 1];
};
const animatedProps = useAnimatedProps(() => {
  return {
    d: selectedGraph.value.curve,
  };
});
const q1Tapped = () => onQuarterTapped(1);
const q2Tapped = () => onQuarterTapped(2);
const q3Tapped = () => onQuarterTapped(3);
const q4Tapped = () => onQuarterTapped(4);

You can also add these functions to the button section at the bottom of the file:

<ButtonSection
  q1Tapped={q1Tapped}
  q2Tapped={q2Tapped}
  q3Tapped={q3Tapped}
  q4Tapped={q4Tapped}
/>

Your code will appear like this so far.

At this point, you’ll have a chart that can jump between graphs like in the GIF below.

Obviously, this looks a little weird, so let's add in the animation now. Back in LineChart.tsx we add a state for our current graph, the graph we are transitioning from, and the status of our transition.

const selectedGraph = useSharedValue(data[0]);
const previousGraph = useSharedValue({...data[0]});
const isAnimationComplete = useSharedValue(true);
const transition = useSharedValue(1);

We will need to update the animatedProps to reflect the transition between these graphs. The new code will be as follows:

const animatedProps = useAnimatedProps(() => {
  return {
    d: mixPath(
      transition.value,
      previousGraph.value.curve,
      selectedGraph.value.curve,
    ),
  };
});

Note the use of the function mixPath. This redash function interpolates two paths with an animation value that goes from 0 to 1. Let’s finish by updating our onQuarterTapped function to animate from one state to the next.

The above code does a number of things, so I’ll break it down here. First, we have an if statement that blocks new animations from happening if there is already an animation in progress.

If there are no active animations, we set the selected graph as the graph we tapped on.

At this point we use the withTiming to slowly increase the transition value to 1 which allows mixPath to animate the chart. Finally, when the animation is complete, we set isAnimationComplete to true so that the user is free to tap the buttons again and transition to another chart.

Bonus: Animating Text

Let’s finish up by animating the text at the top of the screen where we see the dollar amount. Start by adding a mostRecent property to the makeGraph function. You can do it like this:

const makeGraph = (data: DataPoint[]) => {
  ...
  return {
    max,
    min,
    curve: parse(curvedLine!),
    mostRecent: data[data.length - 1].value,
  };
};

We can then create a derived value in LineChart.tsx so that this string is visible to the UI Thread.

const mostRecent = useDerivedValue(() => {
  return `$${selectedGraph.value.mostRecent}`;
});

Finally we can use ReText from react-native-redash to show the value on the UI:

<View style={styles.titleContainer}>
  <Text style={styles.titleText}>FACEBOOK</Text>
  <ReText style={styles.priceText} text={mostRecent} />
</View>

Our completed code is as follows:

Our final result is the graph in this GIF

Final Thoughts

Wow that was a tough one! D3 definitely has a steep learning curve and can be a bit tricky at times. I hope by using this article you were able to get through this exercise and learn more about how to use it.

I’d love to see the React-Native community rally around this technology and cast more light on fun and interesting charts we can add to our apps. Until next time, happy coding.

D3 and React-Native — An Essential Guide to Line Graphs was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the most important but most neglected practises in Agile Software Development is unit testing. I’ve worked with a lot of tools and languages in my career, but haven’t found any that makes it as easy to test your code as it is in TypeScript/JavaScript. As front-end engineers, it’s our responsibility to make sure as much code as possible is covered by some kind of unit test. Beyond the obvious benefit of checking for errors, unit testing can serve as a form of documentation and an exercise in making our functions and components smaller and more reusable.

In the last few years, we’ve been blessed in the React world by having the ability to work with TypeScript and Redux Slices. TypeScript gives us types (obviously 🙂) while Redux slices make our state management code less verbose than traditional Redux. Together they serve as powerful tooling for your React app. This article will use a todo list example to show users of these tools how to unit test their code effectively and build bulletproof apps.

Getting Started

To build our todo list, we are going to use the red/green refactor model of unit testing. This means for every function we will go through the following steps:

1. Write a function with just enough code to compile (no logic yet 🙅)
2. Write a unit test containing the desired outcome for that function
3. Run the test and watch it fail
4. Write a function that we think will pass the unit test
5. Run the function and watch the test pass

To get started, we’ll create a boilerplate reducer and unit test to make sure things are working. We aren’t writing any logic, just enough code to compile the app. The Redux Slice should look like this:

import { createSlice } from "@reduxjs/toolkit";

const todoSlice = createSlice({
  name: "todo",
  reducers: {}, 
  initialState: {}, 
});

export default todoSlice.reducer;

Your unit test file should look like this:

import todoSlice from "../todo.reducer";

describe("Todo Slice", () => {
  describe("My First function", () => {
    it("should compile", () => {
      expect(1).toEqual(1);
    });
  });
});

If you run yarn test at this point, the tests should compile and pass.

Adding a ToDo

The first function we’ll build in this article is one which adds a todo to our state. Because we’re using the red/green method of unit testing, we start by writing just enough code to compile, but not enough to pass our test. Once our test fails, we can work backward to create our function. Let’s start by creating a model for our todos. Our todo model will have isCompleted, text, and id properties. We can then use that model to create our initial state. It will look something like this:

type Todo = {
  id: String;
  text: String;
  isCompleted: boolean;
};

export type TodoState = {
  todos: Todo[];
};

export const INITIAL_STATE: TodoState = {
  todos: [],
};

const todoSlice = createSlice({
  name: "todo",
  reducers: {},
  initialState: INITIAL_STATE,
});

We’ll also write a function with a body that does nothing and add it to the reducers:

const todoSlice = createSlice({
  name: "todo",
  reducers: {
    addTodo: (state, action) => {
      return state;
    },
  },
  initialState: INITIAL_STATE,
});

export const { addTodo } = todoSlice.actions;

Finally, we can write our first failing test 😄! Our test will create a todo model, create the todo action and attempt to modify the state. We can refactor the test we had before into the following form:

import todoSlice, {
  addTodo,
  INITIAL_STATE,
  Todo,
  TodoState,
} from "../todo.reducer";

describe("Todo Slice", () => {
  describe("addTodo", () => {
    it("should add a todo to the state", () => {
      const todo: Todo = {
        id: "1",
        isCompleted: false,
        text: "hello world",
      };
      const action = addTodo(todo);
      const expectedResult: TodoState = {
        todos: [todo],
      };
      const actualResult = todoSlice(INITIAL_STATE, action);
      expect(actualResult).toEqual(expectedResult);
    });
  });
});

If we run our tests at this point, we should see the iconic red test failing text.

Cool! So now we’ve set up our todo model so we know what a model looks like, and we’ve set up the todo state so we know what that should look like. Let’s put together a function that can actually add data to the state. Change your reducer function to have the logic for adding a new todo.

reducers: {
  addTodo: (
    state: TodoState, action: PayloadAction<Todo>
  ) => {
    const newTodo = action.payload;
    state.todos = [...state.todos, newTodo];
  },
},

At this point, you should get a passing test! We’ve completed our first red/green refactor 🎉.

Modify a Todo

Let’s do a couple more functions so you can get a better feel for the TS/Redux Slice unit testing experience. This time we’ll address a situation where there is already data in the state by updating an existing todo to the completed state. Like last time, we add an empty stub and export it.

updateTodo: (state, action) => {
  return state;
},

...

export const { addTodo, updateTodo } = todoSlice.actions;

Then we write our failing test where we show what the state should look like after marking as complete.

describe("updateTodo", () => {
  it("should update a todo in the state", () => {
    const todo: Todo = {
      id: "1",
      isCompleted: false,
      text: "hello world",
    };
    const state: TodoState = {
      todos: [todo],
    };

    const updatedTodo: Todo = {
      id: "1",
      isCompleted: true,
      text: "hello world",
    };

    const action = updateTodo(updatedTodo);

    const expectedResult: TodoState = {
      todos: [updatedTodo],
    };

    const actualResult = todoSlice(state, action);
    expect(actualResult).toEqual(expectedResult);
  });
});

Notice how I used the todo to create a “state” to simulate the application state in the todoSlice reducer function? This way of “mocking” the state is often difficult for beginners to pick up on. I wanted to highlight it as a bit of a pro tip for beginners in this area. With this test though, we are back into the red.

Let's fix this by implementing our update function for real.

updateTodo: (
  state: TodoState, action: PayloadAction<Todo>
) => {
  const updatedTodo = action.payload;
  const newTodoArray = [...state.todos];
  const index = newTodoArray.findIndex((todo) => {
    return updatedTodo.id === todo.id;
  });
  newTodoArray[index] = updatedTodo;
  state.todos = newTodoArray;
},

With that, red/green cycle two is completed 🔥. We can now add and update todos in our application.

Delete a ToDo

Let’s finish off by implementing delete. This will be really similar to update, but I wanted to finish off with the last of the CRUD operations for the sake of completeness. Implement your deleteTodo stub and export as follows:

deleteTodo: (state, action) => {
  return state
}
...
export const { addTodo, updateTodo, deleteTodo } = todoSlice.actions;

Then make the deleteTodo test as follows:

describe("deleteTodo", () => {
  it("should delete a todo in the state", () => {
    const todo: Todo = {
      id: "1",
      isCompleted: false,
      text: "hello world",
    };
    const state: TodoState = {
      todos: [todo],
    };
    const action = deleteTodo("1");
    const expectedResult: TodoState = {
      todos: [],
    };
    const actualResult = todoSlice(state, action);
    expect(actualResult).toEqual(expectedResult);
  });
});

Let’s watch it fail

Then finish up by implementing the function:

deleteTodo: (
  state: TodoState, action: PayloadAction<string>
) => {
  const id = action.payload;
  state.todos = [...state.todos].filter((todo) => id !== todo.id);
},

With that, all tests are passing and we have a working todo reducer:

Final Thoughts

Thanks for checking out my article on TDD with TypeScript and Redux Slices. Because this code is so short I won’t be posting the whole thing on GitHub. If you want an example with a project that has unit testing with TS and TDD you can check out this repo and navigate to the final-solution branch. This is a small project that fetches a Pokemon from the internet using its Pokédex number. I hope you enjoyed this article and look forward to trying out the red/green refactor technique with TS and Redux in your next project!

More content at plainenglish.io. Sign up for our free weekly newsletter. Get exclusive access to writing opportunities and advice in our community Discord.

Modern Test-Driven Development with TypeScript and Redux Slices was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.