I could have used the following title for this article: “React Native Splash Screen done right on Android”. And you could have asked me, why done right? Who are you to say how to do it right? Well, it’s not you it’s me (or something like that!). It is actually Google and they know some things about Android. First of all, I’d like to suggest you to watch the following 3 minutes video:

Now, in order to add a splash screen into a React Native app (on the Android side), let’s follow their suggestions.

First attempt

The example app of this article does not have a white background by default, so having the transition from white to blueish is probably not really what we want:

Let’s apply some concepts from the video including handling the status bar:

Note: With colorPrimaryDark you can change the status bar color on Android without waiting for the JS to load. You won’t even need to use the StatusBar component for it.

With that we got the following effect:

Much better with a couple of lines, but let’s proceed.

Second attempt

Ok, now we want to add an image to the splash screen. We can use windowBackgroundas it was explained in the video we watched (right?) just a few moments ago. First, we need to create a drawable file:

Then let’s update our styles to add the SplashTheme:

We modify our AndroidManifest.xml to change the default theme of our MainActivity:

// AndroidManifest.xml

<activity
    android:name=".MainActivity"
    ...
    android:theme="@style/SplashTheme">

And finally we change our MainActivity to switch to the default theme when the app starts:

@Override
protected void onCreate(Bundle savedInstanceState) {
  setTheme(R.style.AppTheme);
  super.onCreate(savedInstanceState);
}

Everything we did here so far is from the Google’s video. All of it. This is the final result:

I was not fully satisfied with it. There is still an empty blue screen in the middle (because the JS and everything else needed by React Native is still loading). So the following is the extra React Native mile I came up with.

Final attempt

The idea is:

1. Show the splash screen while loading JS without mounting the React default view
2. When the JS is ready, mount the React view using a native fade-in animation

Note: The following code is not documented so it might change in future versions of React Native.

We are gonna override the createReactActivityDelegate method from theReactActivity. This is to defer adding the ReactRootView so then we can have a nice fade-in effect (we will call setContentView later). Thus, inside of our MainActivity let’s place this piece of code:

After that, we are going to add the following method (where the magic happens):

And we are also going to create a small native module that we will use from the JS side:

Anywhere in our JS side, depending on ours app needs we can call that method:

// JS side

import { NativeModules } from 'react-native';
const RNSplashScreen = NativeModules.RNSplashScreen;

RNSplashScreen.hide();

And with that, we got the one I was looking for:

Note: Another benefit from this approach is that we do not have to use any extra Activity or Dialog.

It took me quite some time but I am really happy with the final result and if you would like the same, feel free to use that in your React Native apps for a delightful Android splash screen experience.

Thanks for reading and happy coding!

Hooray! While react-native-paper has just reached 2000 ⭐️ on Github, we were announcing it at React Native EU 2018 as a major update for Paper that is aligned with the new Material Design guide. This is react-native-paper 2.0. Don’t want to read? No problem, I got a lighting talk that gets you covered:

Key concepts of Paper 2.0

Material design guidelines

New style and new components are awaiting for you, ready to be used on Android and iOS.

Platform adaptation

As you saw in version 1, we continue to provide platform adaption so your iOS users keep feeling comfortable.

Full theming support

We extracted the theming logic into https://github.com/callstack/react-theme-provider. You can easily switch from light to dark theme or give to your users any choice they want!

Portal

Render dialogs, floating action buttons, snackbars… One thing above the other. Thanks to Portal you can easily manage it.

Accessibility and RTL

We’ve been working very hard for this version to be much better regarding accessibility. We want each and every of our components to be fully accessible and RTL compatible.

Developer experience

Not only our example is Expo compatible but now you can also check any component in our docs and look for this link:

And you can just try it! Oh and we are also working in bindings for ReasonML!

1.0 vs 2.0

Some component differences between versions.

Button

TextInput

Appbar

Yes, not a Toolbar anymore!

Want to see more? Check the the docs at https://callstack.github.io/react-native-paper!

Wanna help? Be a contributor? There a are lot of components to be made so just join us in this beautiful journey and do not hesitate to send a PR! We also have a channel in Discord.

Don’t forget to check our repo: https://github.com/callstack/react-native-paper

Happy Paper day 2!

This article was originally published at callstack.com on September 28, 2018.

Your next React Native app will still be done with Paper (2.0) was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today I am proud to announce the release of react-native-paper 1.0.0 🎉 🎉 🎉 .

React Native Paper or just Paper was started a long ago, around October 2016. It was an idea from ahmedlhanafy and satya164. Some time ago, we decided that Callstack could take care of it as part of our open source mission and here we are today — Paper is now ready for you to use it in production. Yey!

Why?

We love Material Design because it provides a consistent and smooth user experience. We wanted to have the same look and feel in our React Native apps. We wanted to support both Android and iOS platforms, closely following the Material Design guidelines, all with a nice and easy to use API.

That’s why we created Paper. We are very picky and detail oriented and that is why we made sure to make every pixel count.

Paper gives you all the beautiful of well crafted material design components that work and look (almost) exactly the same for both Android and iOS. Why almost? Well, we are following the Platform Adaptation guide:

Tell me more!

We are releasing a bunch of components like Buttons, Toolbar, Papers!, Cards, Typography, etc. But we plan to add much more so we expect 1.0.0 to be just the beginning of our big plans (CollapsibleToolbar? 😄). And of course, we will be very thrilled to get more contributors on board.

Let’s play a game, I’ll show you some real apps. You tell me if they are written in pure native code or using Paper:

Did you guess it? You are right, they are all built with Paper!

To conclude, just to make it easier for playing with our internal example, scan this QR code with Expo and you are good to go!

Checkout the docs to get started with Paper. If you have any issues or ideas for improvements, open an issue on our repo, and don’t forget to star it!

Happy Paper day!

Your next React Native app will be done with Paper was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the core features of your app is internationalization (aka I18n), right? Internationalization is all about offering your products in such a way that they can be localized for languages and cultures easily.

In react native there is a very nice library to handle it: https://github.com/AlexanderZaytsev/react-native-i18n. With this library, you can define a list of locales your mobile app supports:

I18n.fallbacks = true;
I18n.translations = {
  en,
  es,
  pl,
  fr,
  it,
};

Note: Fallback is important for unfinished translations. So if your fallback language is en and you have a key that is not translated (so not defined in another language) it will use the key from the fallback language instead.

Using the module is also pretty familiar if you come from the web:

I18n.t('some_key')

One of the lovely things to handle this on the JavaScript side (I developed pure Android apps) is that you can update your .js language files and upload them on the fly using CodePush. That way, for any new language, any new key, any typo being fixed, you do not need to do a full app release (YEAH!).

There was some trickery involved though and that is why I am writing this article. I found out that when using this library on Android, if we change the system language, the app will not update to the new locale till I reload the JS bundle. That is not the Android default behavior so… Let’s fix it!

Solving the reload Android problem

Let’s see first what happens on iOS when changing the system language and going back to our app:

As you can see, everything works as expected, our app and bundle gets restarted when coming back to it and we see the new language in place. Let’s see how it behaves on Android:

I googled for an existing solution, I followed this post https://medium.com/@maximtoyberman/changing-locale-in-react-native-android-86fe25cde318 but it did not work for me (the part of restarting). Plus you need a couple of more dependencies: react-native-locale-listener and react-native-restart. In fact, we can solve this on the native side with a few lines of code and we won’t need any more dependencies. Actually, we won’t even need to go through the bridge (all will happen in the native side).

We need to add a couple of cases in our AndroidManifest.xml, look for this line and add the two bold cases:

android:configChanges="keyboard|keyboardHidden|orientation|screenSize|layoutDirection|locale">

In theory we just need locale but there is a bug in the Android platform where the locale change won’t trigger if we do not add layoutDirection too.

After that, we can go to our MainActivity.java, it should look like:

Unfortunately, inside onConfigurationChanged we cannot access the old locale and that is why I am using the currentLocale variable. But basically, if we change the locale (change the phone language) we will recreate the react context. This is the result:

Just as we wanted! Not sure about you but I am going to use this technique in any app I need to write, I18n is a must!

Happy coding!

React Native: Handling language changes on Android the right way was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

You can check all the official Material spec for the drawer, but what we are going to focus here is in the following part:

The nav drawer spans the full height of the screen, including behind the status bar.

Thus, a drawer following this spec would look like:

If you go deep down into the material intro guide, you’ll find the opacity value for the StatusBar:

Let’s try that 20% of black. To do so, we can define the StatusBar as follows:

import { StatusBar } from 'react-native';

<StatusBar
  translucent
  backgroundColor="rgba(0, 0, 0, 0.20)"
  animated
/>

You will get:

Now, we have the drawer above the status bar giving us a nice visual effect (you can use an image as a header too). However, we need to adjust our screens as you can see at the screenshot on the right. For that, we can just make a View with the desired color to be our colorPrimaryDark:

Now it will look like as we wanted:

Pitfalls of using <StatusBar /> and how to avoid them

The main problem of using <StatusBar translucent />is that it will load after the React JS context loads. So if you pay attention when opening the app, there is going to be a glitch after that loading because the status bar will become translucent and we will be moving the screen down to adjust it.

Check it out (check the button in the center):

To fix the glitch, we can write the translucent logic natively. We can check howreact-native does this and just base our solution on it (in our MainActivity.java):

The important part here is just to call our function before super.onCreate(savedInstanceState) where the actual JS context initialization will happen.

With this, the glitch will be gone when you first open the app:

And that’s it! I hope to start seeing more beautiful drawers above the status bar from now on!

Give this some ❤️ if you like me to continue with a series of articles based on making your React Native base app look and feel like an Android/Material application.

Happy coding!

Android Drawer & StatusBar done right for React Native was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

I came into the need of using a SyncAdapter for an Android app I want to fully convert into React Native. In this app, I already have the native piece of code working and I could not find a library out there that actually exposes such functionality. This is how I ended up writing it by myself.

What is the SyncAdapter ?

Basically it is a framework that Android provides to synchronize the data between an Android device and web servers. You could design your own, but they always recommended to use their solution since it provides you with several nice features that you cannot implement by yourself. Basically:

• Schedule syncs: If at scheduled time is not possible to sync, the system will run when possible
• The system only runs your data transfer when the device has network connectivity (so no need to check/worry about it)
• Improved battery performance: Your data transfer is scheduled in conjunction with data transfers from other apps. These factors reduce the number of times the system has to switch on the network, which reduces battery usage
• No need to worry about device being restarted so you do not need to listen for ACTION_BOOT_COMPLETED

You can read more advantages here.

What is the HeadlessJS ?

It is just another Native Module that wraps an Android Service which starts the JavaScript engine where you can run background tasks written in JavaScript. Headless JS is part of React Native since version 0.36.0.

For this native module that I named as react-native-sync-adapter, we are gonna combine the Android SyncAdapter with the HeadlessJS. Let’s start!

Writing native code

I will not go into details in this part but it is a must to use Android Studio. It will provide you with auto-imports and tones of other features. For writing native code, I have basically followed Creating a Sync Adapter training. If you want to read through the code you can do it here. For this section, I am actually going to focus on parts of the code that would actually be new for an Android developer (including React Native code interaction).

Using HeadlessJS

When our SyncAdapter is ready to sync, it basically calls the Java method onPerformSync (see this file). In there, we want to start our HeadlessJS so we can write all the actual sync code in JavaScript (like fetching from an API):

Our HeadlessService.class is almost the same as the one explained on the docs but with some extra checks:

There are several things worth mentioning here:

new HeadlessJsTaskConfig(
        TASK_ID,
        null,
        300000);

• We hardcoded our TASK_ID to be TASK_SYNC_BACKGROUND so you will need to register a task with this exact same name and that is the task our SyncAdapter will run
• We pass null as parameter so the actual JS task will receive null as extra (since we do not need any param)
• Default timeout is set to 5 minutes which should be enough for any task of this kind. It could have been also possible to pass a parameter for the timeout the same as we do with syncInterval and syncFlexTime (see API)

What about the isAppInForeground check? From the docs:

By default, your app will crash if you try to run a task while the app is in the foreground. This is to prevent developers from shooting themselves in the foot by doing a lot of work in a task and slowing the UI. There is a way around this.

Indeed there is a way around this which is taking a look at the source code and passing a specific parameter. But, I prefer to stick into only launching the service when the app is in the background. My workaround would be:

1. In your HeadlessJS task, save (for example in the AsyncStorage) the last timestamp where a sync was completed
2. When opening the app, check that timestamp, if a sync is required, just make the app to do the job
3. Done

Another thing worth mentioning, have you spot the stopSelf() ? If we actually return just null, it will start a non-sticky Service that will not be stopped (which is bad for memory/battery) so we make sure that we handle this edge case.

Creating the module

Let’s go ahead and create a native module, named SyncBackground that will be responsible for interacting with our SyncAdapter:

Basically we do two things here:

• Override getName so from now on, our Native Module will be called SyncBackground
• Expose (using @ReactMethod), in this case, just the method init that will set up all the sync hassle for us

Now, loading that module is just a matter of adding a new instance of it to the native modules list, as shown below:

So the apps that want to actually use this module will be able to add new SyncBackgroundPackage() just as we do in the example app.

More on the native side, we want our module to act as an Android library so we can use it in other projects, to do so, take a look at the build.gradle file. The only required thing to convert our module into an Android library (so Android won’t generate an apk for it) is to add the following line:

apply plugin: ‘com.android.library’

To learn more check Create an Android library.

And voilà! Our library is ready to be consumed.

Android library perks

One requirement to set up a SyncAdapter is to provide unique resources (strings in this case) plus our app launcher icon. If you check the Android library considerations:

Resource merge conflicts: The build tools merge resources from a library module with those of a dependent app module. If a given resource ID is defined in both modules, the resource from the app is used.

Which basically means that if you define a resource in your library named my-library-string-name and define the same resource name in your app, the one from your app will take precedence. We can take advantage of this since our SyncAdapter needs unique values for each app, so in the app that we will be using this library, we should override these values:

As you can see, I prefixed the specific strings from the library with rnsb so they are safer to override (app_name is a common pattern so I left it like that). The launcher icon that is used in the library should be named ic_launcher.png which is also a default pattern.

If you run the example app and in your phone, go to Settings -> Account you will see how the strings and the launcher icon are correctly being overridden:

As you can see, the values that are used are from our app and not from the library. To your question: Yes, I AM A WIZARD.

By the way, notice at the second screenshot, you can select the option Sync Now which will trigger onPerformSync which will trigger your HeadlessJS task so you can try it out without waiting at all.

Exposing a typed API

I find it nice not to expose the Native Module as it is, but wrap it into your own API where you can actually use some typing (Hello Flow!).

Indeed, I could expose this library as:

import { NativeModules } from 'react-native';
export default NativeModules.SyncBackground;

But as I said, I would like to provide a more JS-like API and provide Flow types so we make sure we use the library correctly. Here is this tiny API:

I use an Object as parameter so it is easy to extend it in the future without breaking changes. Flow will make sure you call the function with correct parameters plus I do some error checking. Therefore, the internal implementation is totally transparent to the user and they do not need to know/care how do I use/call functions in the native (Java) code.

Binding it all together

Our native module is ready to use. You can actually follow the setup instructions in the repository: https://github.com/ferrannp/react-native-sync-adapter.

Thanks to React Native modular approach, when one solves a problem on Android (that we do not really want to solve ourselves), then you do not need to do it by yourself never again. Which is nice, isn’t it?

Let me know what you think in the comments below and if you would like me to continue writing about Native Modules even if they are simple examples.

Happy coding!

React Native and Native Modules: The Android SyncAdapter was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s a well known paradigm in the React world for any big app you want to write to extract your business logic (aka manage the state of your app) out of your components. The majority of your components should be a small piece of reusable code that just renders UI based on the app state that is triggered mainly by: User input and API calls. The same paradigm is used in React Native.

I will talk about Redux together with React Native since testing Redux is easy. However feel free to apply the same concepts to another state management you choose. That’s what we will do here:

• Testing Reducers: Manual comparison vs. Snapshots
• Mock the built-in React Native fetch
• Re-mock the redux-mock-store
• Testing Actions (including async ones): Manual comparison vs. Snapshots

Please refer to Unit testing React Native with the *new* Jest (I) — Snapshots come into play! for setting up Jest with React Native.

Reducers

Testing a reducer might be one of the easiest parts to test from your app: Given the current state and an action, a reducer should return a new state after that action is applied. Let’s see how to test part of this example:

We will focus on testing that LOAD_REPOS.success action. Let’s create version 1 of our test:

Quite short, right? I just went and copied and pasted the initialState from my reducer and added the part that changes (repos). When you work in larger projects and your state starts to grow (0r you do some refactoring), you will find this process to be so repetitive that you will want to do something better, so, version 2:

This is better, right? I can add or delete anything to the state (except the isLoading & repos part) and I won’t break the test. I just need to go back here if that action.success does actually affect another part of the state in the future. But, don’t you feel that test it is actually very similar to:

Again, what we are doing in the test is basically reimplementing the reducer. Anytime I change the logic in my reducer, I need to come back here and do the same. It get’s so repetitive… Can we do better? Let’s snapshot that output. Hello version 3:

I know, it’s just one line and I did not have to repeat myself at all (DRY?). Do you like it? I do! Let’s see how the snapshot looks like:

Wow! I can actually see how my state will exactly look like after applying the action. So as you can see, we are forcing Jest to do the hard work while we are just watching. In this case, if you add or remove any part of your state, this test will break: Which is what you should expect, since the outputted state would be different. But as I explained in the first part of these series, the only thing we need to do here is:

• Review the Jest error output
• If it’s expected, run the test again using -u to re-generate the snapshot:

npm test -— -u YourTestName

• If it’s not expected, go and fix it (obviously)

This is a great example of how fast and easy is to write your tests first, aka TDD (Test-driven development):

1. Write your test first
2. Start writing your reducer with the Jest — watch mode enabled
3. Once the outputted snapshot is the one you are expecting, just tell Jest to save it
4. Done!

Actions

A simple action creator is just a function that returns an object:

Which can be tested like:

For the second part, let’s check out the generated snapshot:

Yea, the exact same thing as the reducer: I (and my team) can read the output instead of re-creating the action again (which includes the need to maintain that code in both places).

By the way, if you are already bored of reading, you can watch the same concept in a nice and short explanation here thanks to Kent C. Dodds. If you are not, let’s continue. Since testing such simple actions is so meh, let’s go and test an async action that uses the built-in fetch of React Native and dispatches more than one action at once.

Async actions

This is the async action we will test:

We need some mocking help here to be able to have a nice way to test that so… Let’s mock!

Mocking the built-in fetch of React Native

Similar way that you can use whatwg-fetch in your web apps which will include a fetch polyfill into window.fetch, React Native uses the same idea and includes fetch into the global object as global.fetch.

We don’t want to make real api calls into our unit tests but we would like to mock the responses to write better assertions. There are some mock libraries out there but I just wrote a smaller version that fits my purposes:

Then, we can tell Jest to load that config using the package.json field setupFiles:

"jest": {
  ...
  "setupFiles": [
    "./config/jest/globalFetch.js"
  ]
}

You will see when we are testing our async action how I used this mock. For now, let’s continue mocking.

Mocking a Redux store

I am sure that a lot of Redux users are familiar with redux-mock-store. It’s a simple helper that provides a mocked version of the Redux store and makes it very easy to test what actions have been called. Once you have your mocked store, you can use store.dispatch and get the list of actions that has been dispatched using store.getActions.

But you know what? I feel so lazy that I don’t want to do the same in all my tests where I need a store and a thunk, so I am going to re-mock the redux-mock-store module. See, in Jest you can create a __mocks__ folder in the same level as your node_modules to mock any npm module. So I can actually create a redux-mock-store.js file (name of the module) in the __mocks__ folder:

And use it in my tests like:

Async test

I feel that we are ready to test our async action now, don’t you? Basically what we want to test here is:

1. A successful request should trigger request & success actions
2. A failure request should trigger request & failure actions

First case:

And what output will be generated?

Just as expected and in this case, I think this one is very useful and easy to read: Quick read by reading “type” and longer read by checking that actually the “data” matches what we told fetch to return.

The second case is very similar:

And its output:

As you can see, when you have the mocks in place, writing this kind of tests become very straightforward, and most likely, you won’t need to mock anything since you can find them out there or write your own and reuse them for other projects.

Wrap up

This is it, with this part and the first one, we pretty much covered (I hope) unit testing of your React Native components + your state management logic. We also re-discovered Jest and its new superpower: Snapshots. On contrary, I am sure the way to test React Native apps will continue to improve as much as Jest keeps growing. So this article might get out of date quite soon!

Let me finish with some personal thoughts:

Why would I use Jest?

• You can easily test your React & React Native components
• Snapshots are a plus, but they are totally optional
• You can easily test Redux or other state management libraries with Jest: Shared logic between web and mobile could share tests too!
• The same community have created React Native & Jest. What does that mean? They will be the ones who care the most about making React Native and Jest to play nicely together in the future

To sum up: If you test your web & mobile app with Jest, you can use the same core principle of React Native:

Learn once, write anywhere — React Native

Of course, that is only my opinion. I just hope you enjoyed this short journey about testing a React Native app with the new Jest and remember…

Happy testing!

Testing React Native with the *new* Jest — Part II was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my journey with React, I have been always testing and encouraging people who surround me to test their apps. I have always used Jest for it. But let’s not talk about it again and let’s focus on React Native. Wouldn’t it be nice to use the same framework to test our amazing mobile apps? Furthermore… Wouldn’t it be nice to reuse some tests if we are reusing logic between our web app and our mobile app?

I will try to answer those questions in the following series. In this first article, I will focus on testing React Native components and the pros and cons of using the new Snapshot system provided by Jest vs. shallow rendering comparison (test utils and Enzyme).

The new Jest ?

Before you ask me why I am calling it the new Jest, please check out the updates notes from Jest 14 and Jest 15. It is not only me who says that Jest has a total new face compared to 1 year ago… It is also his number one core contributor:

Christoph Pojer on Twitter

@pedrasmachado @dan_abramov @matzatorski yeah, it has nothing to do with what Jest was then. Just the same name and logo.

In this series we will focus on one of the new Jest features: Snapshot testing.

Jest can capture snapshots of React trees or other serializable values to write tests quickly and it provides a seamless update experience.

Let’s begin to prove the above quote!

Set up Jest in a React Native project

Trivial, seriously. Just follow the docs:

// Install dependencies
npm install --save-dev jest babel-jest jest-react-native babel-preset-react-native react-test-renderer

// package.json
"scripts": {
  "test": "jest"
},
"jest": {
  "preset": "jest-react-native"
}

// .babelrc
{
  "presets": ["react-native"]
}

DONE. Try it out with:

npm test

Time to test components

The example repo for this article renders a list of Github repositories. You can read several test examples in there but for the purpose this article, let’s focus on testing a simple component called RepoItem:

As you can see, this component has an interesting prop called isSelected:

The problems of Shallow Rendering comparison

Have you ever used Shallow rendering from react-addons-test-utils or Enzyme? They are pretty similar, Enzyme got popular cause it has a nicer API which also allows you to find elements in your React trees. Let’s choose this one and try to test a React Native component using it.

Enzyme

First problems when trying to use the shallow function from Enzyme (forget about mount in react-native):

react-addons-test-utils is an implicit dependency in order to support react@0.13–14. Please add the appropriate version to your devDependencies. See https://github.com/airbnb/enzyme#installation

react-dom is an implicit dependency in order to support react@0.13–14. Please add the appropriate version to your devDependencies. See https://github.com/airbnb/enzyme#installation

So we actually need to install react-dom and react-addons-test-util to our devDependencies for Enzyme to work… Ouch!:

npm install react-dom react-addons-test-util --save-dev

Ok, let’s go and try to do the first full shallow comparison:

Ok, actually, this first example won’t work. See the onPress property? The first problem that we have here is the way it’s defined in the component:

onPress={() => {props.selectRepo(id)}}

Both functions won’t be the same (we are creating a new function instance) thus the comparison will fail. We could make some workarounds here but… Let’s be lazy and skip the TouchableHighlight part and assume that nobody will break it:

Don’t you feel we are reimplementing the render() again? Any prop you add/remove or any change you make… You need to come back here and do the same.

All right, now we want to test the component when the prop isSelected is set to true:

Since recreating the bigger picture gets so repetitive, developers tend to test only the dynamic parts, see:

This seems better, right? Let’s continue…

Assume that at some point on this project, our client decides that when you click a list item, a part from the selected background color, we also want to show more information, specifically, the repo description. It would look like:

With this change, two things will happen:

1. The test that checks all the render output will fail: We will need to go back and reimplement it
2. The test that checks only the dynamic part will pass anyway (Oops! is that good?)

In the first case, we need to go back and copy-paste this line into it’s corresponded place:

In the second case, we need to remember to go back to the test and add the new cases:

Do you see the problems? The way I see it… The bigger picture (full render) is complicated to create, tedious to maintain and very repetitive (copy-paste). The second approach (using find, contains…) is unstable: We need to remember to implement all the cases since the new ones won’t break those tests.

Check the full RepoItem-Shallow-test.js file for a bigger picture.

Shallow rendering summary

Pros

• Powerful selector api (find, contains, etc)
• It is actually working in React Native (shallow part)

Cons

• It feels you are repeating yourself all the time, thus, people will usually tend to test only specific parts of the output (render) instead of the big picture
• Copy-paste from the component to the test
• Difficult to maintain
• Go try convincing people to write them

Snapshots to the rescue

Jest 14 introduced Snapshots testing: Check out why are they so great:

No flakiness: Because tests are run in a command line runner instead of a real browser or on a real phone, the test runner doesn’t have to wait for builds, spawn browsers, load a page and drive the UI to get a component into the expected state which tends to be flaky and the test results become noisy.

Fast iteration speed: Engineers want to get results in less than a second rather than waiting for minutes or even hours. If tests don’t run quickly like in most end-to-end frameworks, engineers don’t run them at all or don’t bother writing them in the first place.

Debugging: It’s easy to step into the code of an integration test in JS instead of trying to recreate the screenshot test scenario and debugging what happened in the visual diff.

After the read, let’s try it out and convince ourselves.

We can write a Snapshot test for our first RepoItem (when isSelected is set to false):

Check the result at: RepoItem-Snapshot-test.snap. You will find that it does not use the background color property (as expected) because isSelected is false:

// RepoItem-Snapshot-test.snap

...
style={
  Array [
    Object {
      "backgroundColor": "transparent"
    },
    undefined
  ]
}
...

Now, let’s test the output when isSelected is set to true (it needs to render a green background). Since our component is actually a pure function, this becomes trivial:

And we can find the expected part inside the resulted snapshot RepoItem-Snapshot-test.snap:

// RepoItem-Snapshot-test.snap

style={
  Array [
    Object {
      "paddingHorizontal": 24,
      "paddingVertical": 8
    },
    Object {
      "backgroundColor": "#B2DFDB"
    }
  ]
}>

Great! Now, remember that our client came and asked us to implement the expanded part to show the repo description (a part from the background color). Let’s run the tests:

Let’s check why:

At developing time, Jest will show us very useful error outputs (you can use the watch argument to see them live). Since this change is expected, we can run:

npm test -- -u RepoItem-Snapshot

And that will update our snapshot for free. Check it out:

...
    50000 stars
  </Text>
  <Text
    accessible={true}
    allowFontScaling={true}
    ellipsizeMode="tail">
    Useful description goes here.
  </Text>
 </View>
</View>
...

Boom! Our test failed, we inspected it, the failure was expected and we re-generated the snapshot. We did not have to modify our test. Moreover, this snapshot difference will be shown in our next Pull Request.

And that is all, seriously. Our render output is fully tested for both cases and it is capable to react to changes giving us nice error outputs and an easy way to fix them. Quiet neat, right?

Can I test components with internal state?

Before you ask, yes, you can. Check this example in the Jest repo: Link.react-test.js. Of course, if your component has internal state (side effects), it will get much more complicated to test. See:

I am missing a selector api like Enzyme

Specially if your component has state and you need to trigger some event, it can be very tedious to find the node inside the tree. However, this question has been already asked https://github.com/facebook/jest/issues/1411 and it has an official answer:

We are working on a selector API for the test renderer which will make this possible through an official API — Christoph Pojer

Snapshots summary

Pros

• Easy to write
• Don’t repeat yourself (DRY)
• Compatible with React Native: Check RepoList-Snapshot-test.js and its snapshot which renders a ListView with its items (try to do that without snapshots if you can)
• Error messages on develop time (you can use —watch t00)
• More goodies to come!

Cons

• Missing a selector API like Enzyme (but you read above that Jest community is working on it)
• S̶n̶a̶p̶s̶h̶o̶t̶s̶ ̶c̶a̶n̶ ̶b̶e̶ ̶h̶u̶g̶e̶ ̶a̶n̶d̶ ̶s̶o̶m̶e̶t̶i̶m̶e̶s̶ ̶i̶t̶ ̶m̶i̶g̶h̶t̶ ̶b̶e̶ ̶t̶e̶d̶i̶o̶u̶s̶ ̶t̶o̶ ̶f̶i̶n̶d̶ ̶t̶h̶e̶ ̶p̶a̶r̶t̶ ̶y̶o̶u̶ ̶a̶r̶e̶ ̶l̶o̶o̶k̶i̶n̶g̶ ̶f̶o̶r̶ ̶(̶l̶o̶t̶ ̶o̶f̶ ̶n̶o̶i̶s̶e̶)̶.̶ ̶I̶n̶ ̶c̶o̶n̶t̶r̶a̶s̶t̶,̶ ̶p̶u̶l̶l̶ ̶r̶e̶q̶u̶e̶s̶t̶s̶ ̶w̶i̶l̶l̶ ̶h̶i̶g̶h̶l̶i̶g̶h̶t̶ ̶a̶n̶y̶ ̶c̶h̶a̶n̶g̶e̶s̶ ̶f̶o̶r̶ y̶o̶u̶ . Update 27 Jul 2017: We created snapshot-diff to overcome this issue. Third part of this article is coming soon.
• I am missing a comparison-tool-like between Snapshots. In my example, I manually need to look the differences between the Snapshot with isSelected set to false vs. isSelected set to true

What is the true value of Snapshots?

I want to wrap up stressing the pull request part again. From Kent C. Dodds:

Kent C. Dodds on Twitter

@spencercarnage that's not where the value is... The value is in this [1] at develop time and this [2] at PR time

I could not agree more: Code reviews shine using snapshots. But, be aware then that for the Snapshot concept to work you need to:

Christoph Pojer on Twitter

@VilleImmonen @Vjeux but I need to stress that when using snapshots it's integral that the resulting file is being reviewed properly.

Which means:

You need to make sure that the __snapshots__ folders are reviewed in your PRs

Let me add yet another value: Don’t repeat yourself. This has been demonstrated (I hope!) here when we do not have to re-rewrite our component output. But if you want to go further on that, check out the next article of this series:

Unit testing React Native with the *new* Jest (II) — Redux: Snapshots for your reducers and actions

Happy testing!

Testing React Native with the *new* Jest — Part I was originally published in Callstack Engineers on Medium, where people are continuing the conversation by highlighting and responding to this story.

I feel there is still a lot of discussion around this topic today. Some people will tell you that state is evil and you should never use it, some people will tell you to use Redux even if you don’t know React and some others will tell you just to do whatever you like. This is still happening today! Check this recent discussion from one of the co-creators of react-router:

Ryan Florence on Twitter

When in React, and you think, "I heard state is bad". Open http://facebook.com , go to the React Inspector, look at their components.

The dropdown example

What I am going to do here is present a real example I encountered several times when writing React applications that have suffered from this topic: A component as simple as a Dropdown. Here is the main idea:

For a particular app, this is what I needed:

State that I needed to access outside of this component

• data (coming from an external API)
• optionSelected (which would affect other parts of the app)

State that I did not need to access outside of this component

• isOpen

So here is where the debate started. What do I do with the isOpen state? I can think of 3 different approaches to tackle it:

1. Write your state as up as you can on your hierarchy and pass a callback as a prop (scales pretty badly)
2. Add the state in your Redux store:
   - Create a reducer or reuse another one if it makes some sense
   - Create an action for it
   - Do the same if you want to reuse this dropdown into another application
3. Use a High Order Component (HOC) that ‘enhances’ your component injecting state and/or functionality

In this post I am not going to discuss the pros and cons of number 1 and 2 (because that would probably be too subjective) but rather I am going to show an example of the option we will be using here: Number 3 that is based on this gist from sebmarkbage.

Here is our shinny stateless dropdown:

This guy has been also named as dump/presentational component. The thing is that it can not do anything by its own (a part from render a view), it actually needs an app that controls it or a HOC that enhances it.

So I did actually want an enhancer that was capable to:

• Open and close the dropdown (state)
• Close the dropdown when clicking outside of it (functionality)
• Close the dropdown when clicking on one of its options (functionality)
• Be reusable

Proposed solution:

This enhancer is teaching our stateless Dropdown when to be opened or closed using isOpen and what to do onToggle and onSelect. Another cool thing is that it is handling the click oustide functionality using a wrapper.

This approach has few advantages:

• It is reusable: You can write another kind of dropdown (different markup) and it will work if you respect the prop names
• You can use it or not, if your isOpen state affects other parts of the app, you can go with other options of using the stateless dropdown (like together with Redux) without enhancing it
• A state (isOpen) that only affects that component has been encapsulated into it, thus, when changing it, the React DOM reconciliation algorithm will only look at this portion of code to decide whether we need a re-render or not

Wrap Up: To state or not to state

So, what now? Do I use state or not? Well… I want to think there is not a clear and 100% proven answer for this. React is so close to pure JS that gives you almost all the freedom in the world. I would say that sometimes it might be beneficial and sometimes it might be not, the key here is that you need to find what is suitable for your app and go for it without being afraid of sentences like:

• Always use props
• Never use state
• State is evil
• You are doing it wrong

And… That’s it! Hope this was helpful and happy coding!

Final note: You can try the example code here or visit the demo page.

LAST UPDATE: June 24, 2017. Original writing: May 19, 2016.

I have been using Jest since its beginnings. I won’t lie, the path has been painful: Things like updating from version 0.x.0 to version 0.y.0 (specially to version 0.4.0) was particularly terrible for my tests. Furthermore, I struggled myself more than once with the way Jest works and I even bothered the community with questions like 1, 2, and 3.

But stay with me, Jest has also good things that I am going to show you in a moment. I hope somebody will find this particularly useful because, in my humble opinion, the biggest drawback of Jest is its lack of real examples.

Recently (May 19, 2016), I’ve been writing an app with the React/Redux combo. It uses an external API and I decided to use a fetch polyfill in order to make my network requests. Following the Redux-way, I’ve used Async Action Creators in combination with redux-thunk. Here is how my action looks like:

(Notice that nowadays you can use async/await too).

Ok, now, let’s test it step by step based on the WritingTests from the Redux docs.

A big change here since I first wrote this article in 2016 is that Jest now does not mock your dependencies automatically like it used to. You can read more about it on its blog: Jest 15 — Disabled automocking

Therefore, we do not need to manually unmock modules we want to test.

On the contrary, we are going to use redux-mock-store which is a small package that will help us mocking a redux store as it’s name suggests. Basically, it emulates the redux store (same API) but just for test purposes. You can check the code which is very simple.

Let’s get started! We import everything we need:

import { fetchData } from '../api';
import configureMockStore from 'redux-mock-store'
import thunk from 'redux-thunk'

const middlewares = [ thunk ];
const mockStore = configureMockStore(middlewares);

And I am also going to write a helper method to mock the fetch response (we don’t need nock as suggested in the Redux Writing Test example):

const mockResponse = (status, statusText, response) => {
  return new window.Response(response, {
    status: status,
    statusText: statusText,
    headers: {
      'Content-type': 'application/json'
    }
  });
};

After that, let’s actually write our first it (previously we needed to use pit for async test: Not anymore)

Do you see what I am doing? I don’t care what the real fetch does, I will reinvent it with jest.fn().mockImplementation and force it to return the response I want to test with (in this case a successful one). And with that, I assert that two and only two actions have been called and that they are FETCH_DATA_REQUEST and FETCH_DATA_SUCCESS.

Very similar with the error test case:

Well done! Let’s go one step further, remember this?

if(getState().id === id)) {
      return; // No need to fetch
}

Well, that might be the most basic caching system in the world. Let’s see how can we easily test that too:

See, I am mocking a new store that already has the id 1234 ‘fetched’, so if we dispatch our action, window.fetch should not be called because it is the same id we already “fetched”. Instead, it should be called if it is a different one. As you can see, I don’t even care what fetch returns here so I just make it to return a Promise.

With that, we got our async action fully covered. But wait! It’s not over, there is a bonus and this is very important. Do you remember the import at the beginning of our example action code?

import ‘whatwg-fetch’

If you or your team forget to use the polyfill version of fetch, Chrome or FF will still work and you won’t notice it! But poor the user who tries to use your website on older versions or other browsers if you know what I mean. For that reason, we will write a unit test to avoid such case too. Look at the polyfill code, it has:

self.fetch.polyfill = true

Awesome, we can write a test like:

it('makes sure window.fetch is the one from the polyfill', () => {
  expect(window.fetch.polyfill).toBe(true);
});

Splendid Jest!

And that’s it my friends, this is actually everything I wanted to show you. If you find a similar example with Jest, please share it because it does get really hard to find them. Thanks to the Redux docs for the great explanation of how we can test those async actions and for the mocha example (2017 note: They changed the example to use Jest!).

By the way, this is my first article in Medium, I hope you enjoyed, thanks for reading and hopefully, write you soon!