How to set up an Amazon SES transactional emailer  with a custom template (part 3) -- Managing templates with a CLI

How to set up an Amazon SES transactional emailer with a custom template (part 2) -- The SES Javascript client


## Amazon SES

Amazon’s Simple Email Service (SES) is a service that can be used in applications to send or receive email. It’s [cost effective](https://aws.amazon.com/ses/pricing/) and scalable, and runs on the cloud ☁️. You can use Amazon SES to create transactional, marketing, and bulk emails.

[Marketing emails](https://en.wikipedia.org/wiki/Email_marketing) are emails you send to your users for promoting your products or services. [Bulk emails](https://en.wikipedia.org/wiki/Bulk_email_software) are mass notification type of emails sent to large groups. [Transactional emails](https://en.wikipedia.org/wiki/Email_marketing) are emails triggered by events in your application, such as a new account created, or a purchase confirmation.

## What I plan to discuss

In this series of articles I will show you how you can set up an emailer service with Amazon SES that will let you send transactional emails from your system to your users using custom HTML templates built with MJML.

This will allow you to send custom styled, properly verified and signed emails from a custom domain name you specify. You will also be able to review your overall email deliverability health of your emails by setting up [DMARC aggregate reports](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#dmarc-reports).

I will go through the steps below in this series:

1. How to verify a custom domain name in Amazon SES using the _[DomainKeys Identified Mail (DKIM)](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#introduction-to-dkim)_ authentication standard so we can send emails.
2. How to configure Amazon SES to use our custom domain name as the email sender.
3. How to ensure our emails don’t land in spam using SPF, DKIM, and DMARC records.
4. How to install and configure the [AWS SES Javascript Client](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-ses/index.html) to send emails.
5. How to install and configure the [MJML](https://mjml.io/) library to create a custom responsive email template.
6. How to create a script that converts the MJML markup into plain HTML and uses the SES Client to “register” the template with Amazon SES.

In this particular article I will show you how to do steps 1-3 which deal mainly with configuring our custom domain and Amazon SES to prepare it for our Javascript client integration. Let’s get started!

## Requirements

- You will need to have a custom domain name already [registered](https://www.pcmag.com/news/how-to-register-a-domain-name-for-your-website).
- You will need to create an [Amazon Web Services](https://aws.amazon.com/) account.

## Before we start

### Ensuring your emails don’t land in spam (SPF/DKIM/DMARC records)

I want to briefly discuss the importance of implementing SPF, DKIM, and DMARC records. This implementation is done in your custom domain’s DNS settings and each of the 3 will require that some DNS records are added to your domain.

It’s important to use these to ensure your emails do not land in recipients’ spam folders. You want to make sure you follow proper standards to increase your deliverability.

It’s also important to set these to disallow anyone from doing spoofing/phishing scams using your domain. This prevents your domain name reputation from being affected negatively which would cause more of your emails to land in spam.

Check out the below to find your sending reputation:

- [Barracuda Central](https://www.barracudacentral.org/lookups/lookup-reputation)
- [Sender Score](https://senderscore.org/)

Let’s discuss a broad overview of each DNS record.

### DKIM

This record allows you to “sign” messages sent by Amazon SES. This signature is verified when the receiving email server receives the message, to authenticate the message as legitimately being sent by your domain. Amazon SES makes generating the DKIM signatures very easy (more on this later).

Click for [more info on what is the DKIM record](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#introduction-to-dkim).

### Sender Policy Framework (SPF) record

This is a way to whitelist ip addresses that are known by your domain to be authorized to send emails on the domain’s behalf. We will add an SPF record to your custom domain’s DNS settings when setting up Amazon SES to send email that securely appears to originate from your custom domain name. ip addresses not whitelisted will fail SPF validation.

Click for [more info on what is the Sender Policy Framework (SPF) record](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#introduction-to-spf)

### DMARC

This record enables Amazon SES to indicate that the email is protected with the **SPF** record and/or the **DKIM** record. The **DMARC** record clearly instructs the email recipient what it should do with the message if the message validation passes or fails.

You can configure it to:

- Accept the message
- Reject the message
- Junk the message

I will show you how to set up the records below. If you’d like to do some further reading on this I highly recommend this [fantastic article](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#the-envelope-header-from-mismatch) from [dmarcly.com](http://dmarcly.com) that goes into grueling detail on the benefits of each record, all the various settings for them, as well as general knowledge on email security.

Now that you have a basic understanding of these records and how they will help you, let’s get started with configuring Amazon SES.

The Amazon SES console can be found in your Amazon AWS account by clicking on the Amazon SES link.

Click for [more info on what is the DMARC record](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#introduction-to-dmarc)

## Adding a custom domain to Amazon SES

### **Entering** **Identity Details**

Open the SES console by typing in “simple email service” in the [Amazon AWS console](https://console.aws.amazon.com/)’ search input. On the sidebar click on the “Verified identities” link.

Click on “Create identity”, and select “Domain” as the identity type to create.

![amazon-ses-verified-identities](/images/amazon-ses-verified-identities.png)

In the screen that opens, leave “Assign default configuration set” unchecked. This configuration option won’t be covered in this series but you can learn more about it in the [Amazon SES documentation](https://docs.aws.amazon.com/ses/latest/dg/using-configuration-sets.html).

Enable the “Use a custom MAIL FROM domain” option on. Configuring this will help our emails comply with Domain-based Message Authentication, Reporting and Conformance (DMARC). Set the subdomain value to “mailfrom”, so that the full MAIL FROM domain reads “mailfrom.mycustomdomain.com”

Set the “Behavior on MX failure” to “Use default MAIL FROM domain”. This means if the MAIL FROM related mx record we will add later in this article is misconfigured, it will just default to use the Amazon SES default MAIL FROM subdomain so that your emails are sent. More on this later.

If you use AWS’s [Route53](https://aws.amazon.com/route53/) service to manage your domain’s DNS settings, you can leave the “Publish DNS records to Route53” setting enabled. This will auto-populate the DNS settings. If your DNS settings are managed somewhere else you can uncheck this option.

![Amazon SES Identity Details](/images/amazon-ses-identity-details.png)

### **Verifying Your Domain**

Expand the “Advanced DKIM Settings” and select “Easy DKIM”. Choose “RSA_2048_BIT” as the “DKIM signing key length”.

Check on “Publish DNS records to Route53” to auto-populate your settings if you will be using [Route53](https://aws.amazon.com/route53/) to manage your DNS.

Leave “DKIM Signatures” enabled.

![Amazon SES Verifying Your Domain](/images/amazon-ses-verifying-your-domain.png)

Click on “Create Identity”.

## View domain summary in Amazon SES

You’ll now be routed to a page showing the summary of the domain. Here you can see the domain is marked as “Verification Pending”. This is because we have not yet added the needed DNS records on our domain to verify we own the domain and Amazon SES is authorized to send emails on our domain’s behalf.

![Amazon SES Configuration](/images/amazon-ses-configuration.png)

Scroll further down the page to the next section called “**DomainKeys Identified Mail (DKIM)”.** This section holds 3 CNAME records that need to be put in your DNS settings. If you are using Route53 and chose to automatically add the DNS settings earlier, then you are all set with this part and can skip the next section. If not we will add these records to our custom domain’s DNS now.

![Amazon SES DKIM](/images/amazon-ses-dkim.png)

## Add DKIM records to domain’s DNS

Open the DNS settings for your domain and add the 3 [CNAME](https://www.cloudflare.com/learning/dns/dns-records/dns-cname-record/) records to configure your DKIM message signatures.

If you aren’t sure where you manage your DNS, take a look at the website where you purchase the domain name. The DNS settings management page will likely be there.

💡 Careful when pasting the values, some DNS pages may try to help you by auto-completing part of the record so you may paste more than you need to.

You will add these as [CNAME](https://www.cloudflare.com/learning/dns/dns-records/dns-cname-record/) records in your domain’s DNS.

Once added, head back to the Amazon SES page’s DKIM settings section. After some time the DKIM configuration status should change from “Pending” to “Successful” and the domain summary should change to “Verified”

## Configure custom MAIL FROM records

Next, we will set up the custom MAIL FROM domain.

If you recall, we provided [mailfrom.mycustomdomain.com](http://mailfrom.mycustomdomain.com) as the MAIL FROM domain in this example. This will be your MAIL FROM domain that email servers receive when they get a message from your domain.

Don’t confuse this domain with the “From” address you typically see on an email message. This is the envelope from address, and SPF utilizes that to verify the message sender is correct.

Again, I will refer to the excellent post from [dmarcly.com](http://dmarcly.com) for more info on [the difference between the two “From” addresses](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#a-tale-of-two-from-addresses) where they go in depth on this topic.

Take a look at the MAIL FROM section of the Amazon SES page for your entity. You will see an MX and TXT DNS record.

![Amazon SES Custom Mailfrom](/images/amazon-ses-custom-mailfrom.png)

These two records will need to be added to your DNS settings.

The MX record defines Amazon SES as a mailer for your MAIL FROM subdomain.

The TXT record is used to configure SPF on our custom domain. The settings are as follows:

- `v=spf1` = This is the version of the of SPF to utilize. This should always be set to `spf1`.
- `include:[amazonses.com](http://amazonses.com)` = This includes Amazon SES’s SPF record. Any IP address passing SPF authentication using this SPF record is allowed to send an email.
- `~all` = This controls what you’d like to do if an SPF validation fails for all [SPF mechanisms](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#spf-mechanisms) defined by the Amazon SES SPF record. The `~` means failure for all mechanisms will result in a `SOFTFAIL`. This means that typically a message failing SPF will be delivered but will likely be flagged as SPAM.

If this is properly set up Amazon SES will display a “Successful” indication under the MAIL FROM section.

One thing to note is that adding these will in no way will interfere with any mailers set on your domain name. The MAIL FROM subdomain is intended to be configured only for Amazon SES.

## How to add the DMARC DNS record

As far as Amazon SES configuration is concerned, you should be all set. Your identity status should show as verified, and your DKIM and custom MAIL FROM domain status should show as successful. Now, let’s configure your [DMARC](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#introduction-to-dmarc) record.

Head back to your DNS settings. You will be adding the DMARC `TXT` record.

**Record Name**

The `TXT` record is comprised of a name and a value. The name of the record will be `_dmarc.mycustomdomain.com` OR just `_dmarc`.

The exact name to use depends on your DNS manager. Some may require you type in the full domain to which you wan to set `_dmarc`. Others may already assume you are referring to a specific domain, so you don’t need to put the full domain name.

**Record Value**

The value for the `TXT` record looks like this:

`v=DMARC1; p=quarantine; [rua=mailto:dmarcreports@mycustomdomain.com](mailto:rua=mailto:dmarcreports@example.com); adkim=r; aspf=r; pct=100; sp=quarantine;`

This value includes a few different tags for the DMARC record, and there are more tags I will not apply in my example. Refer to the [DMARC record](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#dmarc-record) section of the [dmarcly.com](http://dmarcly.com) site to get a full list of the options.

Below I will explain the tags we will be setting in this example:

- `v` = The record version. Should always be DMARC1.
- `p` = The policy applied to emails that don’t validate. Change to `reject` or `quarantine`. `quarantine` will issue a “soft bounce” of the email (it will send the email to spam folder), `reject` will tell the email to be bounced entirely.
- `rua` = The email address to send DMARC [aggregate](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#aggregate-report-breakdown) reports to. This is usually the web site’s admin email address. Note: Changing the tag to `ruf` will send [forensic](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#forensic-report-breakdown) reports instead. You can optionally set both.
- `adkim` = Specifies how strict or relaxed the rules for the email domain are for DKIM validation. If you set it to `r` (relaxed) it means your emails will validate just as long as the same domain name is used as the email sender. If you set it to `s` (strict) it means the email sender’s domain name must match exactly the sender configured on Amazon SES. For example if you sent an email from [admin@email.myapp.com](mailto:admin@email.myapp.com), the Amazon SES service must be configured to send emails from [email.myapp.com](http://email.myapp.com/) or else it will not work.
- `aspf` = The same as `adkim` above, but for `spf` record validation.
- `pct` = The percentage of emails that are treated to the DKIM policy. The lower the number, the less emails that will be required to meet the DKIM record’s policy.
- `sp` = The subdomain policy to apply to emails that fail the DMARC check. If you set to `none` then you need to add a specific DMARC `sp` policy on each subdomain you want to send email out from. If you set it to `reject` or `quarantine` that policy will apply to all your subdomains.

## Send a test email

With your DNS records set up on your domain, and a verified identity in Amazon SES, you can now send a test email to make sure you can send emails.

To send a test email simply go to the Verified Identities section in Amazon SES, select the verified identity in the list, and click on the Send test email button.

Entering any “from” email address, whether it exists or not, should work.

## DMARC reports

As you noticed earlier, the DMARC record lets you set an email address to deliver aggregate or forensic reports. These reports give you insight on emails sent from your domain, and their deliverability. In this article I’ll simply point out you can configure this and these reports may be helpful to you. If you’d like to go in-depth on how these reports can help you, you can review the [DMARC reports](https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide#dmarc-reports) section of the [dmarcly.com](http://dmarcly.com) article. I can’t explain it any better than they can 🙂.

## All done

You are all set! Amazon SES can now send properly authenticated emails from any email address with your domain name. In the [next article](https://embusinessproducts.com/how-to-set-up-an-amazon-ses-transactional-emailer-with-a-custom-template-part-2) in the series we will use our Amazon SES verified identity to create an email template, construct the template using the very cool [MJML](https://mjml.io/) library, and send emails using the [Amazon SES Javascript client](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-ses/index.html).


How to set up an Amazon SES transactional emailer with a custom template (part 1) -- Configuring Amazon SES


I want to document how I got custom push notification sounds working on iOS and Android with the React Native Firebase library and Firebase Cloud Messaging (FCM).

The process is not difficult once you understand it. It's just hard to find a complete set of instructions on how to do it. I hope this will save you time when setting it up in your project.

## Groundwork

### Set up the Firebase libraries

First step is an obvious one. Make sure you install [React Native Firebase](https://rnfirebase.io/) core library and the Cloud Messaging modules. Be sure to follow all instructions for each platform carefully.

### Select a sound format

Apple supports `.wav` `.aiff` or `.caf` files. Android supports `.mp3`, `.ogg` or `.wav`.

Since our back-end server used the same push body for both platforms, it was easier to use a format that both platforms could share, so I chose `.wav`.

## Custom sounds

### Set up custom sound on iOS

1. Go to `your_project_root/ios` and place the sound in there. This doesn't yet add it to the project, it just places the sound in a logical spot.
2. Open up Xcode and go to the project navigator tab.
3. Drag your sound into your project. Select "copy files if needed" on the dialog.
4. That's it!

### Set up custom sound on Android

Setup on Android is a little more complex than iOS. As of Android API level 26, notifications need to be set to a notification channel in order for them to work at all.

### Android Notification Channels

The channel defines the sound to use, vibration pattern, and other things about your push notifications. [React Native Firebase](https://rnfirebase.io/) creates its own channel internally to help provide a basic push functionality with their Cloud Messaging library, but if you want a custom sound or other customization, this channel is not accessible to you to edit. You must create your own custom notification channel. On native Android, this is Java code that executes at runtime, it's not done on a configuration file.

[React Native Firebase](https://rnfirebase.io/) does not provide an API to this native API for creating a channel. It used to provide it on v5, but since v6 it has stopped supporting it because it was out of scope of Firebase.

Luckily it's pretty simple to add you own without the need of a custom library to do it. You simply need to update your `MainActivity.java` file in your project so a notification channel is created and configured.

Before you can create your notification channel. You must do the following:

### 1. Define a name for your notification channel

It can be anything, and you will use it to target your custom channel from your push message, so that the custom sound you will tie to your channel plays.

I should note that after installing the app the channel name will remain registered until the app is uninstalled. So keep that in mind if you change channel names later.

### 2. Add your sound as a resource

Drag your `.wav` sound into the `your_project_root/android/app/src/main/res/raw` folder (if it doesn't exist, create it).

### Add the notification channel code

The code below must be placed inside the `onCreate` method of your `MainActivity` class. Fill in the text surrounded in brackets with your own, and customize anything else you need on your notification:

```java
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
          NotificationChannel notificationChannel = new NotificationChannel("{ENTER THE NOTIFICATION NAME HERE}", "{ENTER APP NAME HERE}", NotificationManager.IMPORTANCE_HIGH);
          notificationChannel.setShowBadge(true);
          notificationChannel.setDescription("");
          AudioAttributes att = new AudioAttributes.Builder()
                  .setUsage(AudioAttributes.USAGE_NOTIFICATION)
                  .setContentType(AudioAttributes.CONTENT_TYPE_SPEECH)
                  .build();
          notificationChannel.setSound(Uri.parse(ContentResolver.SCHEME_ANDROID_RESOURCE + "://" + getPackageName() + "/raw/{ENTER SOUND NAME HERE WITHOUT EXTENSION}"), att);
          notificationChannel.enableVibration(true);
          notificationChannel.setVibrationPattern(new long[]{400, 400});
          notificationChannel.setLockscreenVisibility(NotificationCompat.VISIBILITY_PUBLIC);
          NotificationManager manager = getSystemService(NotificationManager.class);
          manager.createNotificationChannel(notificationChannel);
      }

Here's a code example with some values filled in:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
          NotificationChannel notificationChannel = new NotificationChannel("new_email_arrived_channel", "My Emailer", NotificationManager.IMPORTANCE_HIGH);
          notificationChannel.setShowBadge(true);
          notificationChannel.setDescription("");
          AudioAttributes att = new AudioAttributes.Builder()
                  .setUsage(AudioAttributes.USAGE_NOTIFICATION)
                  .setContentType(AudioAttributes.CONTENT_TYPE_SPEECH)
                  .build();
          notificationChannel.setSound(Uri.parse(ContentResolver.SCHEME_ANDROID_RESOURCE + "://" + getPackageName() + "/raw/my_custom_sound"), att);
          notificationChannel.enableVibration(true);
          notificationChannel.setVibrationPattern(new long[]{400, 400});
          notificationChannel.setLockscreenVisibility(NotificationCompat.VISIBILITY_PUBLIC);
          NotificationManager manager = getSystemService(NotificationManager.class);
          manager.createNotificationChannel(notificationChannel);
      }
```

Notice `my_custom_sound` is not written with the extension (`.wav`). You just need to add the file name.

## Test the custom sound

With the sound in place you can now test your implementation. Before you can test it you will need to fish out Firebase's FCM token from your app. This token is used by FCM to route the push notification to the correct device.

### Log the FCM token to your console

Firebase lets you retreive the FCM token using the `messaging().getToken()` function. Use this function to log the FCM token to your console:

```javascript
const _getToken = async () => {
  try {
    const token = await messaging().getToken();
    console.log('FCM token registered:', token);
        ...
  } catch (error) {
    console.error('Error getting FCM token:', error);
  }
};
```

Do this for both Android and iOS devices. It will create a different token for both.

We will use this token to test sending push notifications directly to our test devices.

### Test with the FCM REST API

I will show how to test with the FCM REST API because it will give you all the flexibility you need to edit the push body as you would need to set it on your server.

Follow the steps below to get testing.

#### Install Postman

Postman is a great API testing application for your desktop computer and will make setting up the FCM REST API very easy. [Download and install the Postman app](https://www.postman.com/).

#### Get your Firebase server key

Before we configure Postman we need that our API push requests are authenticated against our project. For this we need to authenticate with our server key. To find it:

1. Go to your Firebase project
2. Click the project settings button (the gear icon) and select Project Settings
3. Go to the Cloud Messaging tab
4. If you followed installation instructions for [React Native Firebase](https://rnfirebase.io/) earlier, you should have a server key listed at the top of this page. If you don't it means you have not yet set up your project for Cloud Messaging and you need to go back to the installation instructions.
5. Copy the server key

#### Configure Postman to send an FCM push request

1. Open Postman
2. Click on the + button on the page to create a new API request
3. For the HTTP method, set it to POST
4. Set the URL to `https://fcm.googleapis.com/fcm/send`
5. Go to the Authorization tab
6. For authorization type select "Bearer Token"
7. Add your server key from your Firebaess project, into the token field
8. Go back to the body tab
9. Set the body type to "raw"
10. Make sure the data type at the end of the body type options is set to JSON and not Text or any other type

#### Set up the push body

Now that your request is configured, let's add the push body. This is done in the body tab in the empty area under the data type options. Here is an example body:

```json
{
  "to": "<FCM TOKEN>",
  "notification": {
    "title": "Some title",
    "body": "Some body",
    "sound": "my_custom_sound.wav",
    "android_channel_id": "new_email_arrived_channel"
  },
  "data": {
    "field1": "value1",
    "field2": "value2"
  },
  "content_available": true,
  "priority": "high"
}
```

The key items here to get your sound to work is the "to", "sound", and "android_channel_id" fields.

**to field**

Here you will need to add your device's FCM token in quotes

**sound field**

Your sound field must set the sound name including the extension.

**android_channel_id field**

The "android_channel_id" field must have the name of your custom Android push channel you created earlier. These names must match or else your channel won't be found and your device will simply play a default sound.

NOTE: You may find some forums out on the internet saying the field name should be "channel_id" and not "android_channel_id". This is half true. They are correct that the REAL name for the push field is "channel_id" on Android. But remember, we are using FCM and FCM handles both iOS and Android. We are not making a request to Google's push server directly.

So for FCM, the field name is "android_channel_id", but once the push is delivered to the Android device this field comes in as "channel_id". FCM translates the field name correctly for us once its delivered.

#### Send the notification

Hit the send button on Postman, you should receive the push with custom sound.

If you get any errors on the API call, make sure you resolve those

### Troubleshoot common problems

If you are having trouble getting the sound to play or the push doesn't come through here are some suggestions you can try to help you troubleshoot.

- Make sure you've followed the Firebase project and [React Native Firebase](https://rnfirebase.io/) library installation instructions exactly, for each platform
- Make sure for iOS that you've either added a push certificate for the sandbox and production APNS servers OR that you've added a push auth key.
- Try re-creating the push certificate OR push auth key. This resolved a push problem on iOS for me on one occassion.
- Make sure the push sound on your FCM body HAS the extension set to it
- Make sure the push sound defined on your Android channel in `MainActivity.java` does NOT have the file extension on it
- Make sure the sounds are being bundled with the build
- It's possible the sound format or compression chosen is not working or not supported by the platform. Try changing the sound compression/format settings.

## Conclusion

Hope this helps you in your push journey. It's strangely a confusing and complex feature to set up.

### Copy of MainActivity.java for reference

```java
package io.myapp;

import com.facebook.react.ReactActivity;

import org.devio.rn.splashscreen.SplashScreen;

import android.app.NotificationChannel;
import android.app.NotificationManager;
import android.content.ContentResolver;
import android.media.AudioAttributes;
import android.net.Uri;
import android.os.Build;
import android.os.Bundle;

import androidx.core.app.NotificationCompat;

public class MainActivity extends ReactActivity {

  @Override
  protected void onCreate(Bundle savedInstanceState) {
      if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
          NotificationChannel notificationChannel = new NotificationChannel("myapp_notification", "MyApp", NotificationManager.IMPORTANCE_HIGH);
          notificationChannel.setShowBadge(true);
          notificationChannel.setDescription("");
          AudioAttributes att = new AudioAttributes.Builder()
                  .setUsage(AudioAttributes.USAGE_NOTIFICATION)
                  .setContentType(AudioAttributes.CONTENT_TYPE_SPEECH)
                  .build();
          notificationChannel.setSound(Uri.parse(ContentResolver.SCHEME_ANDROID_RESOURCE + "://" + getPackageName() + "/raw/myapp"), att);
          notificationChannel.enableVibration(true);
          notificationChannel.setVibrationPattern(new long[]{400, 1000, 400});
          notificationChannel.setLockscreenVisibility(NotificationCompat.VISIBILITY_PUBLIC);
          NotificationManager manager = getSystemService(NotificationManager.class);
          manager.createNotificationChannel(notificationChannel);
      }

      SplashScreen.show(this);
      super.onCreate(savedInstanceState);
  }

  /**
   * Returns the name of the main component registered from JavaScript. This is used to schedule
   * rendering of the component.
   */
  @Override
  protected String getMainComponentName() {
    return "MyApp";
  }
}
```


How to add a custom push notification sound on iOS and Android with React Native Firebase and FCM


When I first looked into how to plan, market, and launch my timesheet and invoicing software product [Dev Dashboard](https://devdashboard.io), I got discouraged because there was more info about how to go about it than I could take in.

After a lot of reading and YouTube-ing, I found myself going through what they call "analysis paralysis". I had too many options, too much info, and I couldn't make a decision.

However, after some time of having this product idea in my head I realized that I needed to stop thinking and do something, **anything**, and start getting one foot in front of the other.

In this post I'd like to share my simple set of questions, to help you take your first step in creating your software product.

## What is your idea?

Describe what your idea is about. Keep it short -- pretend you want to describe it to someone in 30 seconds or less. Mention the benefits of your app to your users. It doesn't have to be perfect. Remember, you can always come back and adjust it.

In my case, for Dev Dashboard, my idea sounds something like this:

_Dev Dashboard helps freelance software developers increase productivity with a simple, easy to use time tracking and invoice app that runs on the desktop._

## Who do you want to help?

Write down some things that describes your user. What are their habits? Where do they hang out online/offline? What sort of pain points do they have that relate to your product? Where do they live? What do the like to eat?

As I said before, it doesn't need to be perfect. The important thing is to get moving forward. Just begin to write some useful things down that helps you better understand your users.

Here's what I wrote for Dev Dashboard:

_Target Users: - Remote freelancers - Digital nomads - Multiple clients with different timesheets - Use a lot of different ways to keep track of time (multiple timesheets) - May use spreadsheets to track time - May use templates for invocing - Use a lot of manual process to create invoices, track time - Wears multiple hats in their business - They are located globally - They work for agencies - They work for mom and pop shops - They work in small teams_

## How does your app benefit your users?

If you can't describe how you can benefit your users you might not have a good app idea. So this one is important. Think about how you can save them time, increase their productivity, increase their revenue, improve their life in some way, make them happier/healthier, etc...

Think about why your app will help them -- what is the reason behind the reason.

Here are some benefits I wrote for Dev Dashboard:

_Benefits: - Make better business decisions by planning and tracking your annual income goals against your current revenue - Improve your work efficiency by using a single source of truth for all your timesheets - Keep clients happy by staying easily informed of project budget progress - Stay organized with all time data and invoices tracked in one spot - Decrease stress by using a clean, easy to use and efficient application_

## Are there similar products out there?

Do a little research on your competition. Maybe you will find that there is already a great solution for what you want to build, and you can move on to your next idea.

### **Get inspired from competition**

You might also find there are some similar products, and as you learn more about them you will think of ideas of improving your own idea that you hadn't even thought about.

Write down the top ones, and describe how your app is similar and different to each.

### **What I did**

For my product, 3 similar apps where [Freshbooks](https://www.freshbooks.com), [Timely](https://memory.ai/timely), and [Toggl](https://toggl.com)

There were a lot of similarities, and they have some features that I just can't compete with at this time, but I did find some differences where I could take advantage:

- No third-party timesheet integrations
- They are larger companies, less nimble so they can't pivot as fast
- Their target market is broad, mine is very focused on only freelance software developers. I should be able to steal users if I do a great product
- The prices range from $5 - $50 a month, I should be able to offer a competitive price
- They don't have a free option. They do have a free trial, but a free option could retain more users which may later pay
- Their UI/UX can be improved on in some areas, in my opinion

## How will you make money?

We all want to make money with our idea. Now you need to think about how you will provide a lot of value to your users at a price they are willing to pay.

### **Get a point of reference**

To get an idea of what the price range could be, I looked at my competitor price points to see what they were doing.

Freshbooks has these prices points: [https://www.freshbooks.com/pricing](https://www.freshbooks.com/pricing) Toggle has these: [https://toggl.com/pricing](https://toggl.com/pricing) Timely has these: [https://memory.ai/timely/pricing](https://memory.ai/timely/pricing)

They all have 3-4 options, ranging between $5-$50, and they also have custom pricing.

### **What I did**

In my case, I think their price ranges are pretty broad. As an individual developer, I should be able to give a lot of value and compete at a reasonable price point.

I'm not yet sure about what my own prices should be, so it's still a work in progress. But I will definitely provide a free option, a middle option with added value, and a custom option where users can pick and choose their features.

### **Provide a free option**

It's important to always give a free option. Users want to test your app out before they buy. As we saw, the timesheet apps provide a trial version. Which is acceptable.

I personally prefer just a "no strings attached" free option, which is what I'll do, but you need to decide on what will be best for you.

## How will you find users?

Ok, the product is a little more fleshed out, and you have some possible price options and target audience. Now, you need to figure out how you will find your audience.

### **I'm not sure where to find them**

If you still have no clue where they could be online, maybe you need to spend more time defining your users. Go back to that step and see if you can flesh it out more.

### \*Make a list of sites\*\*

When you're ready, make a simple list of possible sites, social media, forums, groups, chat channels, or any other place your users visit, online or offline, where you can engage with them and ask them to check your app out and give you feedback once you have a version of your app ready to test drive.

### **What I'm doing**

What I've decided for my product so far has been to join [Indie Hackers](https://www.indiehackers.com), which is a great community for product developers, and start engaging with others who are also building products. I also plan to post on [LinkedIn](https://www.linkedin.com), and connect with other freelance developers who may be interested and build a network that can help me better understand their needs.

In the future I plan on doing more, but the idea here is to get started and moving forward. Don't overthink where you will find users, just select one or two sites, and focus on those. If you see those places aren't working, just choose another.

## Who else do you need on your team to help you?

This is an important question. Do you need a software developer? A designer? Someone in sales?

Get the right team in place. Don't try to do too much on your own, that is if unless you have the time of course. If that's the case, I recommend you do as much as you can, if you're good at it.

## How much will it cost you to build this?

Once you know who you need, define an [MVP](https://medium.com/@sprocompany/what-is-a-minimum-viable-product-and-how-to-build-an-mvp-for-your-startup-9a02c0d4a56a) for your product. Get cost estimates from the team you bring in. Calculate what your infrastructure and third-party service costs are per month.

This may also make you adjust your software price.

## Done!

In conclusion, I hope this helps you get started.


How to plan your software product


Many of us software developers love to build things, and many are creating their own products to add additional revenue to their business, or just to make their own lives easier.

I created Devstimate as a product that will make my life a lot easier (and hopefully the lives of other freelancers out there), and hopefully in the future it can be a way to add a little extra revenue. We have to start somewhere, right? ?

I'll tell you how I came up with it.

## Estimating... so tedious

I've been freelancing and running my own software development company for quite some time already - a little over 8 years. As any software developer will tell you, every project is different, each with its own unique items to consider.

We cannot really use a specific estimation "template" of some kind, that could cover all our cases. They just vary too much. There are some common things, but they apply sometimes differently, or with more or less complexity.

In a month I estimate projects for leads at least once or twice. The process for me goes like this:

1. Lead provides information about their project, and provides wireframes, description, flowcharts, designs
2. I use this information, go through all the documents and begin to form questions for the lead, to clarify details
3. If things are clear, I begin the process of breaking down the project into logical chunks
4. I break down each chunk into tasks, and estimate them
5. Once I estimate all tasks within each chunk, I run these estimations through some form of formula that can give me a cost estimate
6. I then calculate a lower/upper range for this estimate
7. I add any necessary markup
8. I then provide this quote to my client, with a breakdown of the work, and the total cost

I then relax because I won't have to do this tedious process again for another week or two.

Once I estimate, this estimation has been so customized, that I tend to discard it afterwards. It was of value to me for that client, but it won't apply for other clients easily.

I wanted to be smarter about how I used my time. There were some estimation apps and calculators out there, but I didn't feel I had the control I wanted. I wanted to be able to break projects down into tasks, and use some kind of base task as an estimation start, and modify if needed.

The idea to have the flexibility of re-using a task, applying default values when I wanted to, and overriding them when they didn't quite fit, was also something I really wanted.

I also wanted this to be a quick experience. I wanted to search through a list of tasks and find the one I want in just a couple of seconds. And just tap once or twice to add it. No copying or pasting from an excel sheet, and definitely not having to remember what I estimated the same task in the past.

I also didn't want to do math 😖

The app should do the math for me.

I also really wanted to estimate as I already did with Agile teams, which was by using relative estimation with story points. This yielded a more accurate estimation for me than just estimating by hours.

This is why I decided to try and build something that could help me and others estimate their projects. Enter Devstimate 😍

With Devstimate, I designed it to estimate in 3 ways. I can estimate by providing flat fees for each task, I can estimate by hours, and I can estimate using story points.

The first time I used it for an actual client, I could see the change right away. I was estimating a lot faster, and I felt less stressed. It was kinda fun almost, because it had everything I needed and I didn't have to think too much.

I hope I can give this feeling to other developers. There's a lot of work to do though. I just added the bare essentials into it for now.

## How I architected the app

This brings me to more technical details, the architecture I wanted to talk about.

My architecture was based on some goals:

1. Bring it to iOS and Android as soon as I can
2. Don't invest too much time into it. Who knows if I will find it useful let alone anyone else
3. Keep cost low, because, well, you have no budget

With this in mind, I went off on my adventure.

### React Native

I decided to use [React Native](https://facebook.github.io/react-native/) for this task. There was no need to do heavy native work for either platform, and I could share most if not all my logic through React Native.

I kept my idea simple to stick to my goals:

1. No login at all
2. Just a few screens that can be wired up quickly
3. Minimal design, just focus on functionality
4. Generate the totals in the simplest way possible

#### UI

I kept the UI simple, and with the help of [React Native Elements](https://github.com/react-native-training/react-native-elements) and [React Native Vector Icons](https://github.com/oblador/react-native-vector-icons) I was able to get components in place that looked nice, without having to think much about design at this point.

For list swiping, I used [React Native Swipeable](https://github.com/jshanson7/react-native-swipeable#readme). It was simple to implement, and worked just how I wanted it to.

I had the front-end tech decided on, and I really did not want to spend time building a back-end system. This idea is not tested, I felt it would waste time. I did need to save the estimation data somewhere though ?

### Firebase

This looked like a perfect moment for [Firebase](https://firebase.google.com/), which is a serverless technology. I can save info directly to the firebase database, without a back-end.

Firebase also offers anonymous login. This means the user can log into my system anonymously, and their data can be organized by their unique anonymous ID. This was perfect. Saved me lots of time.

On the React Native side, I decided to use the [React Native Firebase](https://rnfirebase.io/) library. It's a very cool library which lets me use the native iOS and Android Firebase libraries in React Native. Couldn't have built it without it.

I wanted to shave some more time off by using other helper libraries in React Native. To help me with the Firebase integration into Redux, I used [React Redux Firebase](https://github.com/prescottprue/react-redux-firebase).

It was really helpful to have a lot of the Redux integration already handled for me, and the querying to Firebase is made a lot easier through this library.

For navigation, I used [React Navigation](https://github.com/react-navigation/react-navigation), and my routes were simple, so there was no trouble at all here.

In total I spent maybe 2 months of part time work to get 90% of it done. The last 10% took very long due to my work schedule, and with the help of other developers we were able to finish the last lingering bugs.

## What I learned so far

Since I built it, I've had a lot more experience in developing applications and using Firebase.

I think Firebase for this use case, was a perfect choice. The data is not that structured, and doesn't require heavy querying. The anonymous login sets me up perfectly for the future when I do add a proper auth system. Anonymous accounts can be merged into real accounts, so my users data won't disappear.

The built-in analytics also help me get basic analytics data into my dashboard, which is nice. I'm not too concerned with user counts right now, anyway.

I did learn that some of my initial ideas need tweaking. I think I can organize the tasks in an even easier set up, but adding the fuzzy search feature for tasks helped a lot in finding the task template you want.

One of the biggest things I overlooked, was the target platform for the app. It's nice to have an estimator handy in your phone, but I really would like to have it on my laptop too. I might build a desktop version in the future.

## Marketing

Marketing is something I'm still thinking about. For now I'm going to try and blog about it more, invite other freelance developers to use the app, join forums, and try to get the word out.

I'm more concentrated on listening to users as they try it out, than I am anything else.

## Conclusion

I'll be writing more about Devstimate for sure, and other things I work on. If you're interested in knowing a little more about Devstimate, check out my [case study](https://droplet.embusinessproducts.com/case-studies/devstimate/).

Also, don't forget to check it out for yourself, on iOS or [Android](https://play.google.com/store/apps/details?id=com.embp.devstimate).

If you find this sort of topic interesting please come by again. Also, feel free to reach out if there's any questions about the tech I used, or about anything about building products.


How I architected my own software product -- Devstimate

7 Signs You Are Building Bad Software for Your Business

Unix Shell Scripting for Front End Developers


A [render prop](https://reactjs.org/docs/render-props.html) is a function you provide to a custom component, for the purpose of controlling how that component renders content.

The react props object provides any kind of data you might want a component to receive from an outer component, or from a state management library such as Redux. A component can be very flexible because it can make use of anything outside of itself to modify itself internally.

You can also pass functions as a prop aside from data. You typically use these functions as callback functions to the parent component, that you can trigger once something in your child component has changed.

The ability to pass functions provided an interesting pattern developers began to use, called render props. Render props are cool because you can affect what is rendered by your child component, from your parent component.

## How Render Props Work

1. In your parent component, pass a function as a prop, as you typically do with a callback function. I will call it "myRenderProp" in my example :

```jsx
render () {
    return <MyComponent myRenderProp={this._myRenderPropFunction}/>
}
```

1. Call the render prop inside the render function of your custom/child component:

```jsx
//Inside of "MyComponent"
render () {
    return this.props.myRenderProp();
}
```

With this setup, the function `_myRenderPropFunction` in the parent, will be triggered on each render. This gives you a lot of flexibility, because your child component just renders the output of the function you passed into it, and the parent component now has control over the rendered output.

This is useful when you can't anticipate what will be rendered by your component and you need it to be as flexible as possible. This especially useful when building a custom component library, where you may want to give the developer the flexibility on deciding what to render within your library component, without modifying your library's code to fit their needs.

## Passing Arguments

We can pass arguments to the render prop, just like we do when we call callbacks in our components. The arguments can be internal state data, that your parent component has no access to otherwise. It could be used to pass ids, or items, or any type of data, that lets you know what is going on inside your component when your render prop is called. The parent component can use this info to help it determine what needs to be rendered at that point.

Child component:

```jsx
//Inside of "MyComponent"
render () {
    return this.props.myRenderProp(some, internal, params)
}
```

Parent component:

```jsx
_myRenderPropFunction = (some, internal, params) => {
  console.log(some, internal, params);
};
```

It is a very simple set up, but the benefits should be easy to see. The children items in your custom component are now "variable", and can be anything you want to pass into it, at runtime.

## Conclusion

Render props are all about flexiblity for your projects and libraries?

This sort of setup helps you solve a lot of complex rendering issues. If you feel like your child component needs to render different elements based on its use, then render props are a great way to go!


Render props in React -- How to make your components flexible


## Introduction

This is a brief overview of what [React Native](https://facebook.github.io/react-native/) is, at a high level. I wanted to put myself in the shoes of clients who want to be educated about some of the technology out there, without going cross-eyed. And I also wanted to speak for developers who are very new to the field and want to know about this technology without going deep into the rabbit hole yet. I hope to explain why React Native is so popular, and why you should probably use it.

## Native Applications

Mobile apps are part of our every day lives, with new ones coming to app stores daily. Apple and Google have given us tools to develop apps and publish them to the app stores. Each platform has different requirements in how to develop for that platform. iOS for example, requires that you program in a programming language called Swift, or Objective C. Android requires that you program in Kotlin or Java. This is what we call "native" programming, and building "native" apps. These apps perform very well, because they compile down to bytecode and are ran by the device processor very efficiently.

Native programming creates a big problem when you want to develop an app that is published to both the app store and the Google Play store. The app programmed in native languages, only works for its respective store and device. We cannot, for example, publish an app we built with iOS tools to the Google Play store. We also cannot install an iOS app into an Android phone, and vice-versa.

This means a developer that would like to target both stores in turn has to build the app twice, once for iOS and once for Android. This is highly inefficient, not to mention costly.

## Hybrid Applications

Enter the hybrid applications. This issue with incompatibility made some smart developers to come up with interesting ways to get around this. One such work-around (to put it at its simplest terms) was to create native apps that just display a web view, a sort of simplified web browser component, where the developer could load a web application with the look and feel of an app.

This web app would be bundled with the native application and since the application was really a web app, most of the code could be reused for both iOS and Android platforms. Not only that, but now web developers could use their existing skills to program mobile applications. This was great! The apps had access to native components as needed as well, if there were platform specific features they needed to target.

This worked suprisingly well, and was a great solution for most apps. It is still widely used today. The need for native development was still needed though, because the performance of these "hybrid" apps, was nowhere near that afforded by native apps. The struggle continued.

## React Native

Now we come to React Native. The intention with React Native is to bring the best of both web and native worlds together, with improved performance. With React Native, the embedded web view was ditched, and developers had full native access. The user interface would live mainly in a layer separate from the full native layer, where it could "bridge" over to the native layer if it needed to.

This user interface layer is an environment similar to a web browser environment, where a web developer could feel right at home here, programming in Javascript (the web's programming language) and a markup language similar to HTML called JSX.

This Javascript layer's code can be shared between iOS and Android, and if developers need to use platform specific features, or if they need that fast native performance, they can easily bridge over to the native layer and make use of anything they need.

This is the power of React Native. The developer chooses what they want to make native, and what can be shared between platforms. You no longer need to hire two developers to program two separate apps. Now you can hire one developer to program most apps and only tap into native code if absolutely necessary.

## Conclusion

I hope this has given you some very basic understanding on what React Native is. I hope to write some more articles that will slowly introduce you to more React Native concepts and topics that you might find interesting ?


A React Native introduction


Working without a structure hinders your wokflow. You know you are working with a bad structure if you have to think too hard to find something. Another sign of a bad structure is if your IDE search is not finding files as effectively as it could. A good React Native project structure set up right from the start can help you massively in your projects.

I'd like to share my structure below, as well as some of the thinking I had behind it.

## Trying to Organize With a Purpose

I've learned to think better about how I am organizing items. It's good to think about not only how to organize things, but who it will benefit. Also, I have realized that how I categorize is not necessarily the same way a teammate categorizes. What I name files doesn't always help _me_ find them in search. I've learned that to make my daily coding tasks easier to work with I need to think more sensibly.

### It's OK to flatten out some hierarchies

It was hard for me to stop making files and folders everywhere ?. Here are some of the things I needed to realize for myself:

- I don't need a top-level components folder, with separate sub-folders for dumb/smart components. I also don't need a separate styles folder for those components. This is over-architected.
- The redux store folders are spread out and are sometimes confusing to find in the `app` folder. A clearly defined folder that holds this logic and all supporting code, may help.
- If I run a search to find a component, I'd like for my component names and the matching style file to be clearly labelled. I also want to know exactly what components are connected to the Redux store and which are not, without a complicated structure.
- I want an easy place where I can find my global styling that applies throughout the app.
- I typically use [React Navigation](https://github.com/react-navigation/react-navigation) which could be a little heavy on the configuration side. I'd like to keep this as separate from my app as possible, so that navigation related code is easy to find and manage.

With these main ideas in mind, I decided to go for a React Native project structure that looks something like the below. I have also added some comments next to most to explain the purpose:

- **app**
  - **components** = Holds dumb components
    - _ComponentName.jsx_
    - _ComponentNameStyle.js_
  - **containers** = Holds smart components, those typically connected to the Redux store
    - _ContainerName.jsx_
    - _ContainerNameStyle.js_
  - **constants** = Holds files that have app constants
  - **navigators** = Holds all my react-navigation navigator configurations
  - **redux** = Holds all Redux related configs, actions, reducers, sagas, selectors, etc...
    - **actions**
    - **reducers**
    - **sagas**
    - **selectors**
    - _loose-config-files.js_
  - **theme** = Holds styling elements common throughout the app
    - _colors.js_
    - _fonts.js_
    - _common-styles.js_
  - **utils** = Holds functions that serve as utilities for my app
  - **libs** = Holds 3rd party libraries that are not included as an npm dependency
  - _App.js_
  - _loose-config-files.json_
  - _loose-data-files.json_
- \***\*mocks\*\*** = The Jest mocks
- \***\*tests\*\*** = The Jest tests
- **storybook** = Storybook stories, if you want to use [Storybook](https://github.com/storybooks/storybook)
- **android** = Android project folder
- **ios** = ios project folder
- **node_modules** = The auto-generated NPM dependencies
- _index.js_
- _package.json_
- _README.md_
- _.dotfiles_

##### One Note on the components/containers folders

These folders hold my dumb components and those connected to Redux. I have chosen not to add any sub-folders in my React Native project structure, and just let them all live on the first level. This just makes it easier to navigate into through the file system. If I choose good names for the filenames, things should be pretty easy to understand.

I also chose to keep the style files in here, because typically if I open a component I want to open the style file as well. The style and component files will stay together because the style has the same name as the component except with "Style" appended, so this makes things very easy to find. Also, if I search from the IDE, I can easily tell what file is the component and what is the style file.

### File naming for better search

Some filenames are easy to find because they are so unique and you just remember them. But tricky ones can be file names that don't have a pattern you can search for.

An example of this can be a button component called `CallToAction.jsx` and one called `ClickForPopover.jsx`. These names will not be helpful at all if you weren't sure of the button's name and wanted to get a search result list of all the buttons you have in your project.

I like to use a naming convention that includes the type of component followed by the component's name. With this in mind, a better name for the two buttons above could be `ButtonCallToAction.jsx` and `ButtonClickForPopover.jsx`. If this naming convention for buttons is enforced, you can find a button in list of all the buttons by just searching for "Button".

We could also benefit other component types: `ModalSummerPromo.jsx`, `ModalAddress.jsx`, `PopUpError.jsx`, `PopUpSuccess.jsx` -- you get the point.

This naming convention is not necessary for all cases, but for some of those components with many variations it works pretty well.

If you want to be extra organized, you can also categorize by the variations you want to distinguish by. For example, buttons that only occurs in the footer could be distinguished from buttons that have a similar function elsewhere:

`FooterButtonContact.jsx`, `FooterButtonSocial.jsx`, `HeaderButtonContact.jsx`, `HeaderButtonSocial.jsx`

It depends on your needs though, the size of your app, or your app's purpose too. Some of this naming convention can become overkill. Just stick with the mindset that whatever you set up is supposed to help you and not hinder you.

### Conclusion

I hope my React Native project structure helps you out in your projects, or at least gets you thinking about how you can improve your own structure. Nothing is set in stone, and what works for one team may not work for another.


My Current React Native Project Structure


A work breakdown structure is overlooked often...

**You, 5 hours earlier...**

_I've been given a new feature to add -- can't wait to jump into the code!_

_Planning you say? Oh, no, it's fine, I've done this a thousand times, and I already have it mapped out in my head. Plus, I did look at the client's task description a couple days ago after all. It's so simple. It's time to get things done and impress my client about how fast I finished. I got this!_

_Unexpected suprises? No problem -- I'll just deal with them as they come along -- I'm a coding ninja after all. I can code with one eye shut, and half my left brain pointed at Youtube :) :)_

**You, 5 hours later...**

_All done, and with unit tests_ 🔥🔥

_I must be like, in the top 3% of coders. Nobody has my work ethic. I'm just plain awesome, and I smell good_ 😎

_My client is going to freak out when he sees how fast I finished!_

_Wait, before I do, I should just check the task description to make sure all is ready. Oh, wait, I missed a small edge case..._

**Here we go...**

_Wait, I totally missed this one sentence at the end. This task has 3 separate use cases, and I only programmed for one. And actually, some of what I wrote won't work for the other cases._

_Wait, did I just do 3 hours of work for no reason? These 2 other use cases are really complex, what happens when the user does this? Wait, this is going to take 3 times longer than I thought. Actually, I'm not even sure how long, I don't have enough information to really know what I'm getting into. I need to ask someone about this, and this. How do I even begin to work through this? There's a lot of API calls going on here. I'm feeling...overwhelmed..._

🤮🤮🤮

**Cry me a river**

Welp, you tried, and you failed miserably. Now you are left with a pathetic feeling of regret and disgust in yourself. Yes, cry, because you should have known better than to forget your training and rush off into the dark expanse of programming without a conquer strategy, grass-hoppa.

![One Does Not Simply Program](/images/one-does-not-simply-program.jpg)

## Patience is worth its weight in gold

Let me start by saying I have lost count of the amount of times I've been in your situation. I read the task, and jump into the code all eagerly, foaming at the mouth, that is until my fantasy is suddenly interrupted by the inevitable effects of impatience. Impatience is costly. It will quickly eat away at your time as you undo and redo work, rethink and replan.

A little thought into exactly what you need to do and how, upfront, will go a very long way. With patience and planning, you will not only better understand what you need to do, but how the feature works as a whole, as well as how your work needs to be architected. Most importantly, you will complete nearly as fast, but with a much much higher quality of work right off the bat, and with less bugs and back-and-forth with the client.

## Work Breakdown Structure FTW

I want to write about how to make use of a structure for breaking down your tasks, which will help you better understand them, organize your tasks in a logical order, bring up questions about the work, and keep yourself from becoming overwhelmed with way too much complexity.

_So, is this way of planning a "thing"?_

Yeah, it is. Out there, in the world outside, they call it a [work breakdown structure](https://en.wikipedia.org/wiki/Work_breakdown_structure). There's software out for this, but for the context I'm writing about (day to day software development tasks) it's probably overkill. I will be sharing how I do it, with a simple hierarchical list which you can write on paper or on your favorite note taking app.

## Let's work with an example

Before I explain how I plan, let's first introduce a real-world example for a project I had. Let's take a look at what this example task requires from a product perspective, and how we can begin to understand and break this task down into easy chunks to work with. After that, we can think about how to plan for it.

### The task

> Program search filtering controls based on provided UI components, and have controls modify the search results on the page. Only items matching the filter controls should display to the end-user.
>
> Controls include:
>
> - Filter by date range
> - Filter by document age
> - Filter by industry
> - Filter by author

**Yeah I know, planning stinks**

I know how you feel, planning is a chore. It feels like you are wasting time over-planning instead of actually getting any work done. The problem is, you _think_ you know the task and your mind map tells you everything you need to know. But when you force yourself to look at each step closely and think about exactly how you should accomplish a task, you will begin to unravel problems in ways you had not yet thought about. These are little suprises that don't come till later and are waiting to make your day horrible.

The product description usually touches on how it should work as how a user interacts with it, and doesn't touch on all the moving parts behind the scenes. So now that you see this planning can be useful, the first thing you must do is stop, take a deep breath and clear your mind. You are going to dial back on your need to code up a storm, and take it slow.

Now, get up -- yes you. Go to the kitchen and make yourself a nice cup of tea or coffee. If you have one already, then good you can stop reading right now and move ahead on this post, you highly caffeinated dev you.

### Notes and to-dos

So, let's talk about writing notes!

##### Channel your younger college self

Remember in college when we all cared a lot and took notes? Yeah, let's bring that back. This is the first component for tackling a task. Before we can fix or build we need to know how it works and why it works that way.

Now, it's important for me (for my own sanity) to make notes that are clear and concise. I also am aware that any notes I take are personal -- meaning, nobody else needs to understand them but me. It is my own personal plan for tackling a task.

I also know, that I can't trust myself in remembering what I wrote an hour ago let alone 3 days ago, so I can't assume I will remember what I was talking about in my notes. I have to write descriptively not only explaining the what, but also the where, how, and why. Clear and concise does not == short and vague. If short explanations don't always work, write long and make sure you have written in a way that reminds you of the context, and describes things in detail so you will remember what you wrote at a later time. This is key, and without it your notes could be too vague to do their purpose.

##### Get your to-do lists on

Once I dump my thoughts on paper or whatever note app I'm using, what I do is make a butt-ugly bullet point list, for to-do items I need to list out. You got a fancy to-do list you like to use? That's wonderful. I just want to write things down and not get bogged down by to-do list features and other nonesense.

I use bullet points to help in readability (I can read things easier like this), and if I want to do certain steps in order I use numbered lists to keep organized. As I complete an item I put an X at the beginning of the line. I told you, it's ugly. It's just fine for me. Use what you want to use :)

## Step 1: Take notes of how things work now, before you make the changes

OK, let's go back to our example. Our little search filter task seems simple enough, but how does it all work right now? The very first step looks obvious, take the app for a test run.

From running our fictitious app, we can see that right now we have search results and there is no filtering functionality at all.

OK, now we know how it works -- wait, no we don't. We still have no clue how this works under the hood. How is the code architected to control filtering and display these search results?

These are notes that can be very useful, as many features out in the wild can be very complex. Sometimes you just understand them for like, an hour, and then you need to remind yourself again. Therefore, without any notes you will need to run the app again to get a handle of how it comes together. If you haven't experienced this in your work, trust me, you will eventually -- because some work is THAT complicated.

After digging into the code, and running through it, we have found some things. Here are the notes:

**How it works now**

- The app is built in React, and uses Redux to store its state
- The app uses Redux Saga for handling asynchronous operations
- Page loads, apps immediately displays any previous search results that were persisted
- User inputs search term, hits submit
- Submit calls search Redux action
- Action invokes Redux saga that makes the search API call
- API call is made, providing search term
  - `Example: http://www.thesearchapi.com?term=fashion`
- Search results are returned unordered and saved into the Redux store
  - The search results formatting is:

```json
{
  "results": [
    {
      "name": "Latest Fashions",
      "body": "article body goes here",
      "date": 1532001248,
      "age": 2016,
      "industry": "fashion",
      "author": "Luke Duncan"
    }
  ]
}
```

- The search results data does not provide the value options for filters
- The data is stored as-is into the Redux store
- Prior to rendering, the results data must be transformed by the search results component into something the results components can render
- The results render unordered
- The search results are persisted
- There is no code implementation for filters at all
- The app does not have any filter controls available to use

This is great. We learned a lot about the app by taking some time to see the flow of things. We learned how the app is architected to get and process the info, and we learned the data is persisted. That's an important point to know about the app because that tells us we may need to persist the filters selection. This exercise also allowed us to make a quick note on how the search results data looks like. This could be a good reference point in case we need to check against it while coding. We are starting to get a better picture of how things work, and we can now possibly form **better** questions to our client/team that we would have otherwise done before.

## Step 2: Write down questions that need to be answered before proceeding

From the bit of code review we did, some questions come to mind. Here are my notes:

**What to ask**

- How are the filter values populated? Is there a separate API to use?
- What is the format for sending the filters to the search call?
- Should the filter selections be persisted?
- Do the results need sorting?
- Is there a set of controls I should use?
- Do the controls need particular styling? Do we have designs?

After talking to the back-end guys and project lead, I got some answers. Let's write the answers right under each question:

**What to ask**

- How are the filter values populated? Is there a separate API to use?
  - Yes there is a separate API: `http://www.thesearchapi.com/filters`
  - Filters are returned in JSON format:

```json
{
    "date": ["array", "of", "timestamps"]
    "document": ["array", "of", "titles"]
    "industry": ["array", "of industries"]
    "author": ["array", "of", "names"]
}
```

- What is the format for sending the filters to the search call?
  - `Example: http://www.thesearchapi.com?term=keywords&filters=filtername%3Afiltervalue%2Cfiltername%3Afiltervalue`
- Should the filter selections be persisted?
  - Yes, the app should remember the last filter selections between sessions
- Do the results need sorting?
  - Results should be sorted by relevance first (result score), then title, alphabetically
- Is there a set of controls I should use?
  - Yes UX has created a UI kit, with pre-made UI elements which include the controls
- Do the controls need particular styling? Do we have designs?
  - Yes, UX provides a default styling in their UI kit, but must be modified for this project
  - Designs can be found at `http://www.client.com/designs/search-designs`

Sweet, the answers helped and now I can look at the designs. I see that each filter control is different, and each is populated differently. I'll just make a note of that to document to myself, under my styling question, since that sorta make sense to me:

- Do the controls need particular styling? Do we have designs?
  - Yes, UX provides a default styling, but must be modified
  - Designs can be found at `http://www.client.com/designs/search-designs`
    - Date Range control uses a range slider, requires min,max,and value
    - Document Age control uses a histogram control, needs min, max, and selected range
    - Industry control uses a picker. It requires an array of possible industries
    - Author control uses a list of checkbox options. Requires an array of possible authors

This is perfect, I'm starting to form a plan in my mind about how to go about doing some of the work, but we have a lot of moving parts right now -- I need to organize my plan.

## Step 3: Break large problems down into steps

So, there's a few things going on in our task. Let's continue creating this mental map on paper, err on screen in our case. I think we KNOW enough about what is going on, and what we need to do at a high level.

Let's get this high-level plan written down so we see where we stand by creating our actual work breakdown list, writing down what we know we must do so far. Here's the initial list:

**Tasks**

- Lay out components into screen
- Style components per designs
- On page load, make a call to filters API
- Populate controls with filter data
- Send selected filters along with search request
- Render search results
- Persist filter selections
- Modify page load logic to grab filter selections if they exist

Not bad for an overview of what needs to be done, overall tasks are separated which is nice. We can still dig deeper though. I want a more detailed plan.

## Step 4: Break high-level tasks down further, into sub-tasks

We should think deeper, and break down each task by sub-tasks. Let's start from the 1st and 2nd task, since they are related, and work our way down.

**Tasks**

- Lay out components into screen
  1. List controls vertically with default styling
     - 100% width into left page column
- Style components per designs
  1. Style Date Range control
     - track color: #0062ff
     - thumb color: #bcd6ff
     - set mouse cursor to pointer
  2. Style Histogram (for document age)
     - bar color: #0062ff
     - range selection color: #fa00ff
  3. Style Picker control (for industry)
     - tag color: #0062ff
     - x button color: #0e142d
  4. Style Checkbox list (for authors)
     - checkbox color: #0062ff

_This is very detailed. It seems so unnecessary_

Well, it is detailed, but you are essentially writing down what you already are keeping track of in your mind anyway. This just gives you a more tangible map that you can refer to, add to, revisit later, and cross out tasks as you move forward. Because of this, it becomes really hard to forget your plan, your concerns about your plan, or to get confused as to what you should do next, because it is written in order from what you should do first to what you should do last. You are doing all that planning up-front, and don't need to think about it with as much effort again. It puts your thoughts on auto-pilot, kinda.

The goal is to note tasks at one or two levels deeper than the top-level tasks. The goal here is not to write every single tiny step you must do -- just what makes sense to you to write down, that is convenient to note, and that is something you might forget that you want to track.

Let's work with the rest of the tasks. We will use the info from our answered questions to get some of these broken down, and we'll write other important details too:

- On page load, make a call to filters API
  1. Write Redux action unit tests
  2. Write filters saga unit tests
  3. Write filters reducer unit tests
  4. Create `FILTERS_GET` action type
  5. Create action creator for `FILTERS_GET`
  6. Create filters reducer
  7. Create getFilters saga
     - `http://www.thesearchapi.com/filters`
     - Handle error response
     - Store data as-is into filters reducer
- Populate controls with filter data
  1. Write unit tests
  2. Populate date range
     - Transform data as needed
  3. Populate document age
     - Transform data as needed
  4. Populate industry picker
     - Transform data as needed
  5. Populate author checkbox list
     - Transform data as needed
- Send selected filters along with search request
  1. Write Redux action unit tests
  2. Write Redux reducer unit tests for filter selections
  3. Create a `FILTERS_SET` action type
  4. Create action creator for `FILTERS_SET`
  5. Create reducer for filters selection
     - Add null/empty value check logic
  6. Wire up submit button
     - Create submit handler
     - Get filter selections from controls
     - Dispatch filtersSet action
  7. Modify search saga to select the selectedFilters reducer data
  8. Transform selection data to the appropriate API format
     - `Example: http://www.thesearchapi.com?term=keywords&filters=filtername%3Afiltervalue%2Cfiltername%3Afiltervalue`
  9. Handle error response
- Render search results
  1. Get filtered results data from search results
  2. Sort data by score and title alphabetically
  3. Feed to search results components
- Persist filter selections
  - Modify Redux persist to include filterSelections reducer
- Modify page load logic to grab filter selections if they exist
  - Check if reducer has selections stored, if so set selections to controls

We have a decent list of tasks laid out.

Before moving forward, take a minute to compare the list we have created, and what we had to go by in the original task description. It's a huge difference!

We can now finally start working?

## Mark step as complete and move forward

As we start to complete items. Simple add an X at the beginning like I do, or just cross them out:

- Lay out components into screen
  1. X List controls vertically with default styling
     - ~~100% width into left page column~~

If new bugs are found after you have completed something, simply make not of it as an extra step:

- Lay out components into screen
  1. X List controls vertically with default styling
     - ~~100% width into left page column~~
     - Bug: 100% width affected the width of the right widget column

If questions pop up at this stage, I like to make a note of the question, as a sub item of the task:

- Lay out components into screen
  1. X List controls vertically with default styling
     - ~~100% width into left page column~~
     - Bug: 100% width affected the width of the right widget column
       - Question: Does the widget column need to share the width class?

Once your question is answered, you can convert it to a sub-task, or write the answer under it. I do both of these, depending on what makes most sense:

- Lay out components into screen
  1. X List controls vertically with default styling
     - ~~100% width into left page column~~
     - Bug: 100% width affected the width of the right widget column
       - Split classes that affect the width of both columns

Once the bug is squashed, just X it or strike it through:

- Lay out components into screen
  1. X List controls vertically with default styling
     - ~~100% width into left page column~~
     - X Bug: 100% width affected the width of the right widget column
       - X Split classes that affect the width of both columns

## Conclusion

That about does it for this post. I hope it is useful to you in your daily work as it is to me. I would not work any other way now ?


You are terrible at planning your software development tasks


I read many blogs about the infamous `git rebase` command, and it took me quite some time of reading and testing, and getting help from co-workers to finally get this through my head.

_Sooo, why is it so hard?_

Look, I don't know. Much more can be written about it. But, here's my try at explaining the basics and getting practical knowledge on it. Maybe, just maybe, this will be the post where you will finally say "I get it".

### Before "committing" to this endeavor

I'm assuming you know your way around git -- committing work, merging, creating pull requests and resolving conflicts. If you don't, this post is probably not for you yet. Once you got the basics, head back here and give this a read!

### What is the difference between git rebase and git merge?

Let's assume we have a branch called `master`, and you have a feature branch called `my-feature`. You branched off a commit in `master` with an id of 'C' into your own feature branch, and you did a little work, which you committed (that would be the 'X' and 'Y' commits):

![](/images/structure1.jpg)

First thing to note, 'C' is your branch's 'base', because it is the point you branched off `master`. This gives you a hint as to what a "re-base" might do for you.

Anyway, let's assume that now there are 3 new commits on `master` (with IDs 'D', 'E', and 'F'):

![](/images/structure2.jpg)

As I said, we branched off 'C', now there is new work you don't have in your feature branch, so you are a bit behind. You need to bring 'D', 'E', and 'F' into your branch. This is where merging OR rebasing is usually necessary.

**Merge**

When you merge, you basically will append a new commit to `my-feature`, that merges 'D', 'E', and 'F', from `master` into your work. This is a new commit added after your work, and it's represented as the 'Z' commit in the image below:

![](/images/merged.jpg)

_Umm OK, so what's the problem with that?_

It's fine. It just creates ugly merge commits.

**Rebase**

If you rebase, you clean things up by actually re-writing history, so that git will now move your branch's 'base' from 'C' as it was before, to 'F'.

There is no need for a merge commit ('Z') as we did with a merge. The history is re-written as if we had branched off 'F' all along. Here's how that looks like:

![](/images/rebased.jpg)

You basically accomplish the same as a merge, but you get rid of the merge commits.

_Oh OK, so it makes the commit history sorta cleaner, right?_

Exactly :) It also makes reviewing pull requests a little more straight-forward as it does not have merge commits.

_OK great, so what is so mysterious about this?_

I think it's because it has to do with the behavior of git, as you are rebasing, and after you rebase, that throws people's brains all out of wack. Let me break the process down and try to explain.

### Rebasing, in the command line

_Command line? That sounds scary!_

Actually, it's not. It's quite simple. In fact this is how I finally understood how to do it.

Let's go back to my cool little graphic (well I think it's cool :P) showing our repo state before merging/rebasing our feature branch:

![](/images/structure2.jpg)

This is the state we will start with, before rebasing.

##### Overview of Rebase Steps

Let's just go over every step before we actually do this. I don't want to lead you through this tunnel of steps without a handy mind-map of sorts:

1. We will apply our branch's series of commits ('X' and 'Y') into the latest work on `master` ('F'). This is done with the rebase command.
2. For each of our commits we are applying 'F' to, we will resolve any conflicts, just like a regular merge, except that since we have multiple commits on our branch, we will have to possibly solve conflicts at each stop -- once for 'X' and once for 'Y'. This is different from the typical merge command, as you only need to resolve conflicts one single time
3. We will push this rebased branch to our remote counterpart, which requires you to be aware of a couple things

Now with that said, let's get on with rebasing!

#### Begin Rebasing

1. You must be in your branch, so checkout your branch:

`git checkout my-feature`

1. Let's run the rebase command. You will target `master`:

git rebase master

You will get a output similar to:

```bash
First, rewinding head to replay your work on top of it...
Applying: added X change
Using index info to reconstruct a base tree...
M   index.js
Falling back to patching base and 3-way merge...
Auto-merging index.js
CONFLICT (content): Merge conflict in index.js
error: Failed to merge in the changes.
Patch failed at 0001 added X change
The copy of the patch that failed is found in: .git/rebase-apply/patch
```

When you have resolved this problem, run `git rebase --continue`.
If you prefer to skip this patch, run `git rebase --skip` instead.
To check out the original branch and stop rebasing, run `git rebase --abort`.

_Woah, what is all that? Now I'm lost for sure_

Before your blood pressure trends up-ward, let me help break this down for you:

`First, rewinding head to replay your work on top of it...`

Here git is simply telling you, it is going to do what we talked about earlier. It is going to "replay" your commits, on top of the commit from master you want to use as your new base.

`Applying: added X change`

Here, git is telling you what commit it is working on, by noting that commit's commit message. In my example repo, my commit message for the 'X' commit was "added X change". So here, we know git is currently working with my example 'X' commit.

```bash
Using index info to reconstruct a base tree...
M   index.js
Falling back to patching base and 3-way merge...
Auto-merging index.js
```

I don't know line for line the meaning of each message, but it's not practically important. Here git is basically telling us, it is going to attempt to merge the changes to `index.js` in this commit ('X') to our new 'base' which is 'F'

```bash
CONFLICT (content): Merge conflict in index.js
error: Failed to merge in the changes.
Patch failed at 0001 added X change
```

This is an important one, and it's sorta doesn't stand out much. But here git is telling you it failed to merge the changes, and it flagged `index.js` as conflicted, as it says 'CONFLICT' right next to it.

Before we continue, it's important to know in what state your repo is in right now. Without getting too technical, let's just say that your repo is in the middle of the rebase process and has paused until you tell it what to do. Your feature branch has not been modified, and neither has your master branch. You are in an interim, paused, state.

At the end of the output, git offers you some options, to move on with the rebasing:

1. Fix the conflict, then continue with the rebase, on to the next commit
2. Skip this change completely (this means the changes done in 'X' will not be applied at all)
3. Abort this scary mission -- this will bring our repo back to its original state, before you dared conceiving the thought of rebasing

Since we DO want this commit to be applied, let's be brave, and go with option 1. Fixing the conflict.

I won't go into the details of how to fix the conflict -- like I said earlier, I will assume you know how to do this. So, let's skip past those details, and let's assume you have now resolved the conflict as you usually do, and now you are ready to continue with the rebasing.

### Continue rebase after resolving conflicts

You can't continue on with the rebase just yet. You resolved a conflict, and now have a modified file you need to stage. To stage it, do what you typically do and add the files. I usually add all files at once, so something like this works for me:

`git add .`

With the modification added, now you can continue by telling git to continue:

`git rebase --continue`

Now, git will apply the next commit ('Y'), and you will get an output similar to the previously posted.

If we run into another conflict, we simply resolve it as we already did, hit `git add .`, and `git rebase --continue` again. Fun stuff

When the rebase is complete, git will simply exit, which I don't really like. I wish it would congratulate us or something, but it doesn't. It just exits, all unassumingly. At any rate, you have finished rebasing :)

Your branch will now have a new base of 'F':

![](/images/rebased.jpg)

#### Push your work

You are now ready to push your work!

`git push`

Now, if you have never pushed this branch to the remote counterpart, you are done!

But, if you already had pushed this branch before rebasing. You got another step. Here's the output you probably get now:

```bash
! [rejected]        my-feature -> my-feature (non-fast-forward)
error: failed to push some refs to 'https://somerepo/my-project.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
```

_Our push was rejected :( What gives!_

Well, we re-wrote the history on our branch locally with our rebase, now the remote history is completely different.

_OK, well at least git helps us with some hints. I will `git pull` then and..._

STOP! Let's not `git pull`. In fact, never `git pull` after rebasing, you will be in for a world of hurt should you do that.

_But, but, git says..._

I know, I know, git says. Git is trying to help you, but git is way off here. It doesn't realize you re-wrote your history with a rebase, and it wants to try and merge your remote un-rebased version of the branch, with your shiny new rebased branch. It will not be pretty to try and do that. Just ignore the hint. Here is what you do:

`git push -f`

`-f` forces the push. This means it doesn't care about what's in the remote right now. It will replace it with what you are pushing -- your rebased work.

_-f? I don't like that. I'm forcing the push? It feels wrong. Shouldn't it merge nicely without forcing it?_

It won't force nicely, your remote branch and the local one now look drastically different in the commit structure. Plus there is no point to try and merge them. We know the local is perfectly rebased. We just want the remote to look just like that. So in this case, forcing it up, is perfectly fine.

I should point out that, if you are pushing to a branch that others are also pushing to, you should avoid rebasing at all, that is unless you are absolutely sure that forcing your rebased branch will not wipe out anyone else's work. I don't recommend working with someone on the same branch anyway. I have never worked too much this way. It causes problems. It's best if everyone has their own warm fuzzy branch just for them.

Again, here is how our rebased branch would look like:

![](/images/rebased.jpg)

Good luck! Done.


Git rebase, how I finally got it


## I must be doing something completely wrong

While working on a chat application for a client, where at any given moment, new data (such as new messages, online/offline status changes on users, new conversations, etc...) could be received by Redux to update component props and affect the UI in many different ways -- I noticed some really odd behavior. The screen was constantly rendered without end, every few seconds. The re-rendering seemed to be tied with new data coming in due to some user activity. The odd part was that, data unrelated to the screen I was working on was causing re-renders. Data that I was using in the screen was not changing at all, yet something was triggering a React props update. I could not understand what was going on. Redux must be busted, I thought -- it is making my screen think new data came in when it clearly didn't.

After a lot of debugging and testing it slowly dawned on me that Redux was not the problem, and I was doing something fundamentally wrong without realizing it.

I want to write about something so dead-simple that it is easy to get wrong when working with Redux and React -- controlling prop changes.

## Old data is old, and new data is new

We all know how it works when we use Redux -- set some data to a reducer, and any component connected to Redux and referencing that piece of data will have its `shouldComponentUpdate` lifecycle method called if/when the reducer's value changes.

In terms of Redux, `shouldComponentUpdate` runs only if new props are updated in your component. In addition, your component may do some transformations to the props within the component, before rendering them. The props themselves may have data you already have, but React doesn't know it. Once props are sent to your component it is up to the component to determine whether to re-render/process or not. Since React can't determine of the props have actually changed, the component will be forced to process and re-render even if it wasn't needed.

The focus of this post is to reduce the load of work on our component, and try to determine whether to send new props from Redux to the component, or not, to begin with.

If we are using a pure component, `shouldComponentupdate` method will shallow compare the old props/old state vs new props/new state. If it finds something has changed it will return true, which tells React to re-render the component. If it did not find any change, it will return false, which tells React to not re-render the component. Whether a component re-renders or not depends on what this method returns.

If we are not using a pure component, whenever new props come in, it will re-render automatically. However, whether it re-renders or not still depends on a change of some kind, it is just more lenient as to what that change might be, which can get us into trouble.

Whether you are using a pure component or not, will probably not matter for this post. You will most likely see the same behavior I want to talk about, no matter what you use.

Let's assume we are not using a pure component, and any prop change will cause a re-render. Like I said, the attempt here is to mitigate the re-rendering issue at the start of the update flow from Redux to component.

### Problem: Referenced Objects

A simple example of setting some data to the store may look like the following:

```js
export function myReducer(state = { theData: {} }, action) {
  switch (action.type) {
    case SET_VALUE:
      return {
        ...state,
        theData: {
          ...state.theData,
          ...{ [action.payload.key]: action.payload.value },
        },
      };
  }
  return state;
}
```

`action.payload.key` will be set for our key object (`myKey` for example). `action.payload.value` will be the value of our key (`1` for example).

And, let's assume we reference this data in our component this way:

```js
const mapStateToProps = (state) => {
  const { myReducer } = state;

  return {
    myReducer: myReducer,
  };
};
```

So, what if we pass again the same value of `myKey` and `1` into this reducer, so that the same exact key is set with the same exact value for that key as before? Would our component think new data has come in and re-render? The answer is yes, it would. The reason for this is because even though the values remained the same, the object holding the values is different from the previous. The new object is fed into our React component, and React assumes it is new. The new data will in turn, cause a re-render.

### Solution Attempt: Re-use the same object where necessary

To solve our issue with new array references, we should first ask ourselves, do we need to set a new object each and every time? If not, you could update your reducer to use the previous object, if the new value created no real change:

```js
export function myReducer(state = { theData: {} }, action) {
  switch (action.type) {
    case SET_VALUE:
      const isEqual =
        state.theData[action.payload.key] === action.payload.value;

      return {
        ...state,
        theData: isEqual
          ? state.theData
          : {
              ...state.theData,
              ...{ [action.payload.key]: action.payload.value },
            },
      };
  }
  return state;
}
```

With this simple equality check, we don't have to provide a new object, we just use the same one which has not changed, and we will avoid invoking lifecycle methods in our component -- hmm, or will we?

### Problem: Top Level References

With our updates in place, if we ran this code in an application and updated our store a few times, you will find this did nothing to fix our issue. It is still rendering unnecessarily. Is Redux or React at fault? Definitely not :) This just brings us to our next "gotcha". Let's re-visit our state to props mapping:

```js
const mapStateToProps = (state) => {
  const { myReducer } = state;

  return {
    myReducer: myReducer,
  };
};
```

### Solution: Map More Specifically

Earlier, we mapped our reducer to our component. Our entire reducer object is mapped. Now, per Redux architecture best-practices, we should always return a new state object to avoid mutating our data. We can't really get away with returning a new reducer object, but what we can do is be sure we target exactly what we need in the reducer's hierarchy, instead of just referencing the top level object. Let's refactor our state to props mapping:

```js
const mapStateToProps = (state) => {
  const { myReducer } = state;

  return {
    theData: myReducer.theData,
  };
};
```

Now we're talking! We targetted our reducer's `theData` property directly, which may return the same object or not, depending on our simple check we added earlier. With this change, we will cut down on re-renders significantly.

Just imagine if we had a long list of reducers, referenced at the top level, and all returning new objects each and every time something triggered them. In large scale applications this optimization can really help your app stay smooth, and even more so if your component does a lot of data transformations (within `componentWillReceiveProps`, for example)! Each modification to the Redux store could cause transformations to run over and over, for multiple components. I cringe at the thought ?

### Problem: Complex Data

So we've solved a couple things, and our app is running nicely. But now, our app is scaling up, and we need to pass more complex data into our reducer, which becomes more difficult to check for equality. Let's update our reducer to store this new data:

```js
export function myReducer(state = { theData: {}, theComplexData: {} }, action) {
  switch (action.type) {
    case SET_VALUE:
      const isEqual =
        state.theData[action.payload.key] === action.payload.value;

      return {
        ...state,
        theData: isEqual
          ? state.theData
          : {
              ...state.theData,
              ...{ [action.payload.key]: action.payload.value },
            },
      };
    case SET_COMPLEX_CALUE:
      return { ...state, theComplexData: action.payload };
  }
  return state;
}
```

Let's assume the payload for this complex data is an array of numbers. How can we keep something like this from returning a new array if the values are all the same. For this, we should use a tool like Lodash's [isEqual](https://lodash.com/docs#isEqual) utility to do deep comparisons.

### Solution: Deep Comparison

Yes, I know you have probably heard. Deep comparisons are not recommended. Comparing objects in a component deeply can be processor intensive and can cause performance issues. And that's true, you should not deeply compare two objects unless it is absolutely necessary. However, the performance hit could be kept to a minimum if we do this check in the reducer and not on the component's `shouldComponentUpdate` method. Leaving it up to the component would cause this check to run too many times, not only due to prop updates, but maybe state updates within your component as well, while doing this in the reducer will only do the call when a new value is set into it, which tends to be a more controlled event. So yes, it's not recommended to deep compare, but if we absolutely have to, this is a good location to keep in mind for doing such work.

```js
export function myReducer(state = { theData: {}, theComplexData: {} }, action) {
  switch (action.type) {
    case SET_VALUE:
      const isEqual =
        state.theData[action.payload.key] === action.payload.value;

      return {
        ...state,
        theData: isEqual
          ? state.theData
          : {
              ...state.theData,
              ...{ [action.payload.key]: action.payload.value },
            },
      };
    case SET_COMPLEX_CALUE:
      return {
        ...state,
        theComplexData: _.isEqual(state.theComplexData, action.payload)
          ? state.theComplexData
          : action.payload,
      };
  }
  return state;
}
```

## Conclusion

Redux can be deceptively simple. We can get caught up in the wiring up of things and forget to check these areas that could affect our app. I learned the hard way, but I hope I could spare you from making the same mistakes :)


Redux and React Props Update Gotchas

How to Create an Open Source React Component


## Who needs promises!

Previously I wrote about a possible approach to [upgrading your SQLite database in React Native](https://droplet.embusinessproducts.com/react-native-sqlite-database-upgrade-strategy/). It was fun sharing my approach to it, but recently I have moved on to using [Redux Saga](https://redux-saga.js.org), and while my previous post did not make use of Redux at all, I thought it would be great to share how I use this upgrade logic with Redux Saga, for those of you who like to get fancy with your Redux integrations.

I've enjoyed working with Redux Saga so much that if I can help it, I will leave promises behind in Redux!

## Prerequesites

If you have not read my previous [post](https://droplet.embusinessproducts.com/react-native-sqlite-database-upgrade-strategy/), I suggest that you do, as it will give you a good overview of the upgrade logic I will apply here.

You should also know how to use Redux, else you might get really confused!

I will not go into the same details on this post as I did on the previous one when it comes to the upgrade logic. Here I am focusing on using what we did before with Redux Saga, and jumping right into implementation. I will make these assumptions before starting:

1. You have some basic Redux Saga experience
2. You have installed Redux Saga in your application (i.e. `yarn add redux-saga`)
3. You have already configured Redux and Redux Saga to run (i.e. `sagaMiddleware.run(sagas)`) in your app

Let's get started!

## Overall Database Saga Design

Our first step is to understand how the Redux Saga flow is intended to work:

1. App requests that the database is opened via a Redux action creator
2. Database open saga runs
3. Database is upgraded if needed via an upgrade saga
4. Database instance is saved in the Redux store
5. Any database related errors are saved in the Redux store
6. Database instances is closed, and instance is removed from the store when the app requests for the database to close (typically when the app itself is closed)

### Folder Structure

We will create this structure

- `app/constants/actionTypes.js` : Will store our action type constants
- `app/actions/databaseActions.js` : Will hold our Redux action creators
- `app/reducers/database.js`: Will hold our database Redux reducer
- `app/sagas/database.js` : Will hold our database sagas
- `app/db/db-upgrade.json` : Our upgrade config file, which we created in the previous blog post
- `app/selectors/index.js` : Will hold our database reducer selection utlity

**Note: The structure above only covers the items related to the database upgrade work I am focusing on in this post. You should also don't forget to have configured all other Redux and Redux Saga related files to the app, which is the typical setup I assume you already know** :)

## Groundwork: Add action types

Create an `/constants/actionTypes.js` file to store your Redux action types. Let's add these five:

```ts
export const DB_OPEN = "database/OPEN";
export const DB_CLOSE = "database/CLOSE";
export const DB_ERROR = "database/ERROR";
export const DB_SET_INSTANCE = "database/SET_INSTANCE";
export const DB_CLEAR_INSTANCE = "database/CLEAR_INSTANCE";
```

## Groundwork: Add Reducers

We will have a simple database reducer which will simply be in charge of storing the database instance, any errors we may get, and a flag to tell us if the database is ready. Place this in `app/reducers/database.js`

```ts
import {
  DB_CLEAR_INSTANCE,
  DB_ERROR,
  DB_SET_INSTANCE,
} from "../constants/actionTypes";

export function database(
  state = { database: null, error: null, isReady: false },
  action
) {
  let { type, payload } = action;

  switch (type) {
    case DB_SET_INSTANCE:
      return { ...state, database: payload, isReady: true };
    case DB_CLEAR_INSTANCE:
      return { ...state, database: null, isReady: false };
    case DB_ERROR:
      return { ...state, error: payload };
  }
  return state;
}
```

## Groundwork: Add database selector

Create an index.js file at `app/selectors` and add the code below:

```ts
export const getDatabaseState = (state) => state.database;
```

With the help of Redux Saga's `select` effect. We will be able to grab our database reducer and reference its stored fields. This will be useful in checking the database state and will let us use the database instance wherever we may need it in our sagas.

## Groundwork: Add the runSqlQuery function

This function will be in charge of making a single query to our `react-native-sqlite-storage` instance. This is not a saga, but will be used by our sagas to retreive data. Since we want to use the power of Redux Saga's effects to pause saga execution, we should return the promise result here. Pretty straight-forward logic, and I am able to use Redux Saga effects since this function will return a promise.

This function should be stored at `app/sagas/database.js` since it will be used by our sagas only.

```ts
export function runSqlQuery(db, query, params = []) {
  return db
    .executeSql(query, params)
    .then((results) => ({
      success: true,
      error: false,
      results: results[0],
    }))
    .catch((error) => ({
      success: false,
      error,
    }));
}
```

## Groundwork: Add the runSQLBatch function

`react-native-sqlite-storage`'s `sqlBatch` method enables me to run a batch of SQLite statements at once. Same setup as the `runSqlQuery` function except I can provide arrays of statements.

You may also store at `app/sagas/database`.

```ts
export function runSqlBatch(db, statements) {
  return db
    .sqlBatch(statements)
    .then(() => ({
      success: true,
      error: false,
    }))
    .catch((error) => ({
      success: false,
      error,
    }));
}
```

## Creating the sagas

Let's work in our sagas (`app/sagas/database.js`)

### Adding necessary imports

Here are the imports you will need:

```ts
import SQLite from "react-native-sqlite-storage";
import { put, call, fork, select, takeEvery } from "redux-saga/effects";
import { DB_CLOSE, DB_OPEN } from "../../constants/actionTypes";
import {
  clearDatabaseInstance,
  setDatabaseError,
  setDatabaseInstance,
} from "../../actions/database";
import { getDatabaseState } from "../../selectors/index";
import dbUpgrade from "../../data/db-upgrade.json";
```

### Add watchers to database.js

We will watch for 2 action types, one for opening the database and one for closing:

```ts
export function* watchDatabaseOpenRequest() {
  yield takeEvery(DB_OPEN, open);
}

export function* watchDatabaseCloseRequest() {
  yield takeEvery(DB_CLOSE, close);
}

export default function* root() {
  yield fork(watchDatabaseOpenRequest);
  yield fork(watchDatabaseCloseRequest);
}
```

### Add the open saga

Below is the open function, similar to the original open function in my previous post, except it is now converted to a saga, and I have separated the get version query as well as the query methods themselves. They will all now be separate sagas called using Redux Saga's `call` effect. Later I will add these sagas (`getVersion` and `dbUpgrade`)

Notice the `select` effect, here we use the selector we created at `app/selectors/index.js`. We get the database instance reference and see if it has been defined. If not defined we know that the database is closed and we should open it. Once we make the necessary upgrades, if any, we set the instance of the opened database by using Redux Saga's `put` effect to call the `setDatabaseInstance` action creator. Our reducer will be triggered here and the instance will be saved.

```ts
export function* open() {
  try {
    const { database } = yield select(getDatabaseState);

    if (!database) {
      const db = yield call(SQLite.openDatabase, {
        name: "my-existing-data.db",
        createFromLocation: "~data/my-existing-data.db",
      });

      const version = yield call(getVersion, db);

      if (version < dbUpgrade.version) {
        yield call(upgradeFrom, db, version);
      }

      yield put(setDatabaseInstance(db));
    } else {
      console.warn("Database already open, ignoring open request.");
    }
  } catch (error) {
    yield put(setDatabaseError(error));
  }
}
```

### Add the getVersion saga

This is the version logic from my previous post now as its own saga. You will notice the `runSqlQuery` function is used here via the `call` effect. Since we use the `call` effect, the function will not continue running until we get a result from `runSqlQuery`. Any errors will be set to our Redux store, in the database reducer, by using the `put` effect. The `put` effect allows us to call action creators.

```ts
export function* getVersion(db) {
  try {
    const { success, error, results } = yield call(
      runSqlQuery,
      db,
      `SELECT max(version) FROM ${DATABASE_VERSION}`
    );

    if (success) {
      return results.rows.item(0)["max(version)"];
    } else {
      yield put(setDatabaseError(error));
    }
  } catch (error) {
    yield put(setDatabaseError(error));
  }
}
```

### Add the upgrade saga

Here is the same upgrade logic as my previous post. I run through the entire logic on that post. Once the correct upgrade scripts are loaded, we call the `runSqlBatch` saga to run all our scripts, and as we did before, any database errors we encounter we simply `put` to our Redux store.

```ts
export function* upgradeFrom(db, previousVersion) {
  try {
    let statements = [];
    let version = dbUpgrade.version - (dbUpgrade.version - previousVersion) + 1;
    let length = Object.keys(dbUpgrade.upgrades).length;

    for (let i = 0; i < length; i += 1) {
      let upgrade = dbUpgrade.upgrades[`to_v${version}`];

      if (upgrade) {
        statements = [...statements, ...upgrade];
      } else {
        break;
      }

      version++;
    }

    statements = [
      ...statements,
      ...[["REPLACE into version (version) VALUES (?);", [dbUpgrade.version]]],
    ];

    if (__DEV__) {
      console.warn(
        `Database Upgrade Needed. Will upgrade from version ${previousVersion} to ${dbUpgrade.version} with statements:`,
        statements
      );
    }

    const { error } = yield call(runSqlBatch, db, statements);

    if (error) {
      yield put(setDatabaseError(error));
    }
  } catch (error) {
    yield put(setDatabaseError(error));
  }
}
```

### Add the close saga

The close saga will first select the database reducer and check if there is an instance saved into it. If so, it will call its close method, once that is done we clear the database instance from our Redux store by putting the `clearDatabaseInstance` action creator. And again, errors are put to the reducer as well with `setDatabaseError` action creator.

```ts
export function* close() {
  const { database } = yield select(getDatabaseState);

  if (database) {
    try {
      yield call(database.close);
      yield put(clearDatabaseInstance());
    } catch (error) {
      yield put(setDatabaseError(error));
    }
  }
}
```

### Conclusion

I hope this quick run-through of this setup in Redux Saga has helped you get an idea of how you can use Redux Saga to create more scaleable and complex interactions as well as an easy to set up upgrade logic for your SQLite database. Till next time, keep coding!


A React Native SQLite Database Upgrade Strategy with Redux Saga


## The Problem: I need to update users to my new database schema in React native

When you work with SQLite in React Native you will inevitably make updates to the database structure you did originally. You have added/removed tables, or fields, or updated field data types. The question is now what can you do to update existing users of your app to your new schema without wiping out their database data.

Before we set things up, it's important to understand some general things:

1. We should not provide a new database, or an updated database, as this will cause the users existing database to be discarded along with all its data.
2. We should connect to the user's existing database, and apply update scripts to it.
3. The app should understand that the user may not have updated the app in a while, and could be behind a few versions of the schema. This means your db upgrade code must know exactly what upgrade scripts are relevant to the user's database version and apply only those.
4. The app should understand that some database upgrades assume that the last upgrade is in place. This means your upgrade scripts must be applied in sequence from oldest to most recent.

With those items in mind, let's get started!

## The Solution

Note: I am using `react-native-sqlite-storage` in these examples, but it doesn't matter what you use. The concepts are all the same.

Also, I will be writing under the assumption that you already have a database set up in your project, and you are looking for a way to upgrade it. That being the case, I am sticking with something more along the lines of pseudo-code that you should modify for your own purposes. I think the overall logic/idea here is what I want to get across more than anything else.

**Let's assume we have a local database of version = 1, and we want to upgrade it with a set of scripts up to the latest version -- version 5.**

### Logic Overview

Our general logic is below:

1. Load up a database upgrade configuration file
2. Open the existing database
3. Get the database's current version
4. Get the config's target upgrade version
5. If the version is lower than your app's target upgrade version, run upgrade scripts from the version right after the old database version, up to the target upgrade version

### The Configuration File

This file will be in charge of storing the database version you'd like your app to upgrade to. It will also hold the upgrade scripts to run for each version of the app. Here is an example:

```json
{
  "version": 5,
  "upgrades": {
    "to_v2": [
      [
        "CREATE TABLE [IF NOT EXISTS] table_name1 column_1 data_type PRIMARY KEY, column_2 data_type NOT NULL, column_3 data_type DEFAULT 0;"
      ]
    ],
    "to_v3": [
      [
        "CREATE TABLE [IF NOT EXISTS] table_name2 column_1 data_type PRIMARY KEY, column_2 data_type NOT NULL, column_3 data_type DEFAULT 0;"
      ]
    ],
    "to_v4": [
      [
        "CREATE TABLE [IF NOT EXISTS] table_name3 column_1 data_type PRIMARY KEY, column_2 data_type NOT NULL, column_3 data_type DEFAULT 0;"
      ]
    ],
    "to_v5": [
      [
        "CREATE TABLE [IF NOT EXISTS] table_name4 column_1 data_type PRIMARY KEY, column_2 data_type NOT NULL, column_3 data_type DEFAULT 0;"
      ]
    ]
  }
}
```

#### What does the config file do?

The example above indicates your new intended version of the db is version 5, and the logic here will be that the scripts in the upgrades field will run from the version of the app's db up to the script that updates your db to version 5.

#### Folder structure

Let's assume we will work off a file called `database.js` located at /app/db. Let's place the config file we created earlier in /app/db as well and name it `db-upgrade.json`, so we will just work within the same folder.

#### Load up the config file

In `database.js` import the json file:

import dbUpgrade from "./db-upgrade.json";

### Open the Existing Database

We are assuming of course a database was already created in your own project and you'd like to upgrade it. As I said, I will be using `react-native-sqlite-storage`, but any library that allows you to use sqlite will work.

```ts
import dbUpgrade from "./db-upgrade.json";
import SQLite from "react-native-sqlite-storage";

export const open = () => {
  const db;
  SQLite.openDatabase({
    name: "my-existing-data.db",
    createFromLocation: "~data/my-existing-data.db",
  })
    .then((instance) => (db = instance))
    .catch((error) => console.error(error));
};
```

### Get the database's current version

Let's add a query that will give us the database version:

```ts
import dbUpgrade from "./db-upgrade.json";
import SQLite from "react-native-sqlite-storage";

export const open = () => {
  const db;
  SQLite.openDatabase({
    name: "my-existing-data.db",
    createFromLocation: "~data/my-existing-data.db",
  })
    .then((instance) => {
      db = instance;

      db.executeSql("SELECT max(version) FROM version")
        .then((results) => {
          let version = results[0];
          if (version < dbUpgrade.version) {
            //Call upgrade scripts
          }
        })
        .catch((error) => console.error(error));
    })
    .catch((error) => console.error(error));
};
```

Since for this example, we assumed the local db has a version of 1, the query `SELECT max(version) FROM version` in this case would give us a value of `1`

### Upgrade function

Let's create the function that will be in charge of the logic of running our SQLite scripts, based on the database's previous version:

```ts
export const upgradeFrom = (db, previousVersion) => {
  let statements = [];
  let version = dbUpgrade.version - (dbUpgrade.version - previousVersion) + 1;
  let length = Object.keys(dbUpgrade.upgrades).length;

  for (let i = 0; i < length; i += 1) {
    let upgrade = dbUpgrade.upgrades[`to_v${version}`];

    if (upgrade) {
      statements = [...statements, ...upgrade];
    } else {
      break;
    }

    version++;
  }

  statements = [
    ...statements,
    ...[["REPLACE into version (version) VALUES (?);", [dbUpgrade.version]]],
  ];

  return db
    .sqlBatch(statements)
    .then(() => console.log("Success!"))
    .catch((error) => console.log("Error:", error));
};
```

### Upgrade function logic

Let's breakdown the logic of the upgrade function. First thing we do is we determine the version

let version = dbUpgrade.version - (dbUpgrade.version - previousVersion) + 1;

We get the version stored in our `db-upgrade.json` file (`dbUpgrade.version`) and subtract `previousVersion` from that. `previousVersion` is the version we retrieved from our local database (the outdated database you want to upgrade):

dbUpgrade.version - previousVersion

This would give us `4`, since `db-upgrade.json` is set to `5`, and our local db returns `1`. This number tells us how far behind the database is. It is 4 versions behind. Before we can begin to run scripts, we need to know where do we start from. We don't want to run scripts the database already has ran. Hence, the next part of the expression:

dbUpgrade.version - (dbUpgrade.version - previousVersion)

Here we again use the `db-upgrade.json` version (`5`) to establish where we want to end, and we subtract by `4`, to establish where our local db's version is (`1`). If we ran the scripts now, we would have a problem, because like I said, we don't want to run the scripts our current database already has. We shouldn't start running at version `1`, but at version `2`. Therefore we:

dbUpgrade.version - (dbUpgrade.version - previousVersion) + 1

As you can see, we added 1 at the end. Now we will start at the right script :)

Our next block of codes runs our scripts. We basically loop through each script, and use our version value to access the right script, we store the script in the statements variable, and we increment the version number so that on the next iteration we can get the next script. Once we see we have no more scripts left to upgrade, we break the loop.

```ts
        ...
        let length = Object.keys(dbUpgrade.upgrades).length;

    for (let i = 0; i < length; i += 1) {
      let upgrade = dbUpgrade.upgrades[`to_v${version}`];

      if (upgrade) {
        statements = [...statements, ...upgrade];
      } else {
        break; //we found no more scripts, break
      }

      version++; //increment version from 2, to the end (5)
    }
```

We then add a db version upgrade script, to make sure our new scripts will set the local database version to 5. And at the same time we add the scripts we extracted from `db-upgrade.json` using the spread operator `...statements`:

statements = [...statements, ...[['REPLACE into version (version) VALUES (?);', [dbUpgrade.version]]]];

### Finishing up

Now that we understand how the upgrade function works, let's use it in our code. Here's the entire code with the added call:

```ts
import dbUpgrade from "./db-upgrade.json";
import SQLite from "react-native-sqlite-storage";

export const open = () => {
  const db;
  SQLite.openDatabase({
    name: "my-existing-data.db",
    createFromLocation: "~data/my-existing-data.db",
  })
    .then((instance) => {
      db = instance;

      db.executeSql("SELECT max(version) FROM version")
        .then((results) => {
          let version = results[0];
          if (version < dbUpgrade.version) {
            upgradeFrom(db, version);
          }
        })
        .catch((error) => console.error(error));
    })
    .catch((error) => console.error(error));
};
```

Your app database is now ready to be upgraded. Happy coding 🤓


A React Native SQLite Database Upgrade Strategy


Creating responsive apps is not something that widely discussed in React Native and most tutorials or documentation don't mention it. I remember assuming, in a moment of insanity, the sizing would "just work", and we would not need to think much of it.

This is not true, sadly. And it's good to be aware of some of the ways we can get our designs to look nice on all target screens.

This post is not intended to get too into the details, rather it is intended to just speak about general concepts and tools so that you have a broad overview of how you might go about setting up your projects

A combination of tools and concepts to understand, will give you the best results:

- **Density Independent Pixels:** React Native's pixel unit of measurement
- **Flexbox:** Make your layouts flexible by default
- **Dimensions:** Calculate sizes/position based on device dimensions
- **Percentages:** Dimensions Relative to its container
- **PixelRatio:** Handle sizing depending on pixel depth

### Density Independent Pixels

Before thinking about resizing elements. It's important to know that React Native uses a coordinate space  
made up of units that don't necessarily map 1:1 with pixels. This is because some screens have higher resolution than others (more pixels fit on the screen, which in turns provide more detail), while the actual screen size of the device may be the same dimensions as screen sizes of a lower resolution. Since a screen can have such a difference in how many pixels are drawn on it, it doesn't make much sense to have a coordinate space that uses pixels, it would be very difficult to place items on a screen with that large of a variation of units.

With density independent pixels (dp), React Native defines a coordinate space separate from the resolution of the device. This makes it much more simpler to place items. An item of 300(dp) in width, will generally cover the same amount of space no matter the screen size, even if the resolution of the devices varies. It is predictable, and easy to guess roughly where elements are placed and sized.

### Flexbox

While the assistance of density independent pixels helps you have a consistent size between screens, it doesn't really assist in how to fill up extra space on a component if you go from a phone screen size to a tablet screen size, for example. If you set a width of 300 on a phone, viewing the component on a tablet will show extra space because the tablet is wider. This is where you may want your component to stretch to whatever the device width is, using Flexbox, instead of using fixed numbers. Flexbox also gives you some very useful alignment features for child components, where you may space these items evenly no matter the screen width. One thing to note is that in React Native, the Flexbox implementation is not the same as on the web. There are limitations, but you still should have what you need to tackle most layout challenges.

### Dimensions

If Flexbox can't handle a certain layout, or if for some reason, you need more fine grained control of positioning, you can try placing items on screen depending on the screen width or height. To do this you will use the `Dimensions` object from React Native

```jsx
import {Dimensions, View, Text} from 'react-native';
const {width, height} = Dimensions.get('window');
...
render() {
    return <View>
               <View><Text style={{position: 'absolute', top: 0, left: width * .8 }}>Some text</Text></View>
           </View>
}
```

The above example would place your text field at 80% the width of your device. The text will always be at 80% of the screen width, no matter the size of the screen.

#### Fonts

Unfortunately, font sizes will not magically resize with a screen size change, although it should be noted that on Android you have some control on font size by editing your device's font size settings. For all other purposes you can use `Dimensions` to determine a proper font size, depending on the screen width.

```jsx
import {Dimensions, View, Text} from 'react-native';
const {width, height} = Dimensions.get('window');
...
render() {
    return <View style={{flex: 1}}>
               <Text style={{fontSize: width * 0.3 }}>Text 1</Text>
           </View>
}
```

### Percentages

You may use percentages to size items, which are helpful in some situations as well.

```jsx
render() {
    return <View style={{flex: 1}}>
             <View style={{width: '50%'}}><Text>Text 1</Text></View>
             <View style={{width: '50%'}}><Text>Text 2</Text></View>
           </View>
}
```

The above will size the two views to 50% of the parent view's width. In this case the parent view has a flex of 1 which will automatically stretch to fit the device width. The child views will always be 50% of the device's width.

### PixelRatio

PixelRatio is handy for sizing images and fonts. Yes, font sizing will not magically look great on all screen sizes either :( . Images which haven't been properly sized for your screen won't look great, so make sure to use PixelRatio for that too.

**Images**

```jsx
import { Component } from "react";
import { Image, PixelRatio } from "react-native";

export default class MyUserThumbnail extends Component {
  render() {
    const size = PixelRatio.getPixelSizeForLayoutSize(20);

    return (
      <View>
        <Image
          source={{ uri: "http://some-uri.com/uri", width: size, height: size }}
          style={{ width: 20, height: 20 }}
        />
        ;
      </View>
    );
  }
}
```

#### What did this even do?

To get images to look properly on high dpi devices, you actually have to multiply their size by the dpi value. The `getPixelSizeForLayoutSize` method simply does this and returns the multiplied values back. This ensures your images look crisp.

I hope this has helped you better understand your options when setting up your project for multiple screens.


Handling Different Screen Sizes in React Native


## Problem: Long Load Times

This is a pretty big topic, but I'd like to give a broad overview of some of the common things to think about with big data. In React Native, it's pretty common to develop apps that require heavy loads of data to render to the user. This can bring some big challenges quickly to our development plan, and it is something beginning developers can underestimate. Downloading a lot of data up-front can cause too long of an initial load time to the user. Trying to spread out the data load so it loads on-demand, may cause lower load times up-front, but it may require more loading spinners throughout your app--making your app seem generally slow and sluggish.

## Problem: Over-burdening the Device

Loading times is just one of many things to think about with large data. You also need to think about how too many network requests may affect the user's data rates on their phone service, and how it may affect their battery consumption. The more work you are putting the device through, the more power it requires. Another thing to consider is where will you store this data? Storing too much data in memory may use up too much of the device's RAM, leaving other apps with little memory to work with, or may use up all the user's RAM and crash the app. Boy, this is getting a little overwhelming :)

These sort of problems are very common in applications, and there are some techniques that can handle most large data challenges and keep your apps running smoothly. Before we decide on what approach to take though, we need to understand what we have to work with first. Below are some ways I get organized when determining what strategy to apply.

## Step 1

### Gather Information

It might be tempting to rush off and begin to solve things by doing them. I think most of us have this tendency, and I have learned first to stop, take a deep breath, and understand exactly what problem am I having before I try to solve it :)

Understanding the problem will also help you think about solutions, even some you may have not thought about. Here are some things I might ask myself when understanding data size challenges:

1. Make note of the specific areas in your app that are slow to load
2. Check each area with a networking tool, check load speeds, and confirm that the problem is in fact large data being downloaded and not some other issue with your app
3. Think about why those areas of your app are loading so much data, and if certain areas need to load some of that data at all.
4. Make note of how often data is being requested, which may help bring up additional flaws to the surface of general architecture

## Step 2

### Brainstorm your options

Once you have reviewed and understood what your app is currently doing with your data, it should help you organize yourself on what options you have for improvements. Depending on what I find, I generally would like to ask these questions:

- What bits of data are essential to the user up-front, right after launching the app?
- What bits of data are not essential to the user right after app launch?
- Is the entire bulk of this up-front data large in size?
- Does the entire bulk of this up-front data change often?
- Is the API good at what it does? Does it return data that is easy to manage?

#### What bits of data are essential to the user up-front, right after launching the app?

In this age of fast internet and ever-shortening patience, the user of your app wants to see your app's content immediately. Users expect to not have to wait too long for an app to launch and load just to see the first screen. This makes it important to think about what data is really necessary to download right from the start. At the same time, we don't want to have the user wait for your app to load things it doesn't need to display right now. So think about what data is absolutely crucial to load at the beginning.

#### What bits of data are not essential to the user up-front?

Take note of data that is not essential to the user when the app launches. Is it possible to load this later? Does the API allow you to load it later?

#### Is the entire bulk of the "up-front" data large in size?

Once you have a clearer idea of what data you absolutely need at the start, this is a great follow-up question to ask. Exactly what you consider to be large really depends on your use case, and since we are speaking about mobile networks which greatly vary in speed, you should know a little about your target users, and their typical network speeds. Will they be mostly using WIFI or their cell's data? How fast might their WIFI or cell data be? It is probably safe to say that, any downloading that is over a couple hundred kilobytes, or shows a loading spinner to the user for more than a few seconds can be considered to be large data. This indicates that loading this bulk data every single time you launch your app might not be something your users would be thrilled about, and you might need to think about further optimizing your strategy. Which leads us to our next question...

#### Does the entire bulk of the "up-front" data change often?

This is an important question, because if the data never changes, then you may only need to request it just once, and never request it again -- or you might be able to request it just once a month, or even just once a week, and it may not be too bad to wait longer than usual for a download since it is an occasional inconvenience.

If that's the case we can pretty much move on to our next question. I feel it would be a good enough solution for most apps. But if the data does change often, long loads as I said, may cause users to lose interest or be frustrated with your app. We need to think deeper about this issue. Some tactics come to mind, which I will discuss later. For now it is good enough to have come to the realization that there could be a need to do some additional planning here, and we cannot simply load our data at the start without affecting the user experience. Loading data at the start is still needed, but we need to see what we can do about giving the user the illusion that it has loaded fast, if not instantly. Just give it some thought for now, and let's continue.

#### Is the API good at what it does? Does it return data that is easy to manage?

Sometimes you might find yourself swimming against the current, trying way too hard to make the data you are getting from the API to load efficiently. Maybe it's time to stop and think -- is the API itself a problem?

What I consider to be an API that is easy to work with in terms of how to get data will generally have architecture similar to this:

- It is flexible enough to let you download a full result, or a partial result only returning the most recent changes for a set of data
- It allows you to paginate certain data results
- It splits data into what you can call an item's metadata, and an item's details
- It can be queried/filtered

Hopefully the above has helped you think about what you could investigate and develop a strategy. Having said that, let's think about some more concrete plan of attack for our React Native app.

## Solutions

I will get a bit more technical about things now that we are speaking about some concrete solutions. Just remember that these are simply ideas, and not hard truths. There are possibly other ways to go about handling data, and what I share is from my personal experience :)

### Optimizing Your Initial Load Time

#### Load Only Necessary Data at the Start

You should focus on the API endpoints that get you only what you really need at the start of your app. This will reduce the unnecessary loading time for the user as the rest of the data your app needs is not going to be displayed or used in any way at this time. This is a bit of a no-brainer, so I won't say much else about it. Let's keep going...

#### Load Partial Data

If the essential data is still fairly large, and if your API allows it, another tactic you can use is to load the entire bulk of data one time, and load only new data on subsequent requests. To do this, your API must allow you to make subsequent data requests that download only new data, that has been updated since your last request. There are probably many ways to do this, but this can be typically done by providing the API with the date stamp of your last result. Providing this timestamp on a subsequent request could cause the API to check for data updated since that timestamp, and would return only from that timestamp forward, to you. Your app can then simply merge this data with the one it already has in memory. This can significantly cut down on your load time and reduce the lag time for the user.

#### Create the Illusion of Speed with a Cache

With the two above tactics, you may still have some load time that is unwanted and that holds the app long enough to be a problem. When you must show something immediately to the user, one solution you can implement is to cache the data locally, on the initial download. Next time the user launches the app, the cached data can be presented immediately to the user with 0 load time. In the background, you can then make an update call which downloads the partial data that has changed since the last request. Once this data is processed and merged, you can update the view. The great thing with this approach is that it removes the need for a spinner. The user sees content load immediately and can begin to navigate the app. If some new content came in through the partial update, it generally is OK since you may see just a few areas blink and re-populate. The main advantage is that the user is not waiting around and is able to see something right away.

### Be Choosy About When to Load Data

#### Be lazy, wait until it's needed

This is a fairly straight-forward idea to understand. A good rule of thumb with data is basically to not load data you don't need until you need it. There are some screens the user will rarely visit and loading data for those before entering those screens is unnecessary. There are exceptions to this rule as probably with everything else I've mentioned. It's just a good general idea. But be creative and think about how else to optimize. Sometimes loading data early is a good thing. I'll talk about that next.

#### Be greedy, load ASAP

Let's flip this idea upside down now. Like I said, sometimes loading data you don't immediately need can be a good thing. I think the reason why it is ok is to reduce network calls. Sometimes spreading requests out too much can make your app feel slow because it is constantly loading things to display. So, wherever you feel you might load more without a huge affect on loading, go ahead and group calls together. It becomes a bit of an art of balancing things out here. See how you can make it perform its best.

### Store stuff locally

#### Redux Persist

This can be part of the caching strategy to load things up immediately. This is great when you want to continue the immediate effect of caching data between launches. The user can close the app and open it again, and your app can simply load back up your locally stored data. Redux Persist is great because it interfaces with a lot of storage engines and works with Redux. Just configure your storage engines and it will rehydrate your app automatically. You may also use it to store sensitive information (such as login), using the redux-persist-sensitive-storage storage engine.

#### SQLite

Another common way to store locally is using SQLite. This is specially great as it allows you to load only a slice of data, based on a query. react-native-sqlite-storage is a library I've used previously. It is a great library, but the documentation is a bit hard to follow. I may do a small post about how to use it in the future.

### Tactics for Efficient Processing

#### Memoize: Reselect for Redux

Sometimes the data we get is not in the exact format we need it for displaying to the user, or for performing some operation on. Typically we must re-process data even if the data has not changed. With [Reselect](https://github.com/reduxjs/reselect), these transformations are cached, and unless something significant changes, the cached transformation is passed over to your components. This can save a lot of unnecessary code churning and make your app run at its best.

### Leverage your API

The API you are working with can help tremendously in consuming just the right amount of data at just the right amount of time. Be sure to check with the API's creators or documentation and understand what you have available to you. I will run through the usual use cases.

#### Paginate

Most APIs have a way to retrieve large results in sets, or pages based on a size you can specify yourself. Since you typically don't show a whole lot of data all at once, you can paginate certain parts, through actual pages on the UI, or through infinite scrolling. This is an essential feature of an API that provides tons of data.

#### Use "metadata" endpoints

Many times, you don't need an item's full details right away. Maybe you just need to know the item's title, and a couple of general properties. Check if the API you are working with has endpoints that give you item metadata. Once the user has indicated they would like to see more details about an item, you can make a second API call for the item's full details. Usually the item's metadata will give you an item id, that you can use on the endpoint that gives you its full data.

#### Filter your search down

This is common in APIs that has some sort of search functionality. If your API allows for filters or queries of some kind, make sure you optimize them so that you get only the most relevant results.

#### Download partial results

This goes in line with what I mentioned in optimizing your initial load time. See if your API returns partial data, where only updated data is returned instead of full results where most of the results may not have changed at all. It can be a little tricky to merge new results in, based on your app's complexity. This may be made easier if your API's data elements give you a version number you can check against, or some other value. If not, work with the API creators to determine the best way to merge in partial data.

#### Call the API endpoint twice

This is a trick that can come in handy once in a while and works best on screens you don't access often. This helps when you have an endpoint that just gives you a piece of specific data and calling just when you need it is a bit too late -- as it won't populate anything right away and the user will get a blank screen, and when calling it on the screen may be too early -- as the data could have updated at the time the user has actually opened the screen.

What you can do is make the call prematurely (maybe the screen before the one the user could open to display its info), and then when the user opens the screen you can display this data right away. At the same time as the user has opened the screen you can make the API call again, and if something did indeed change with the new data response, it will refresh your pre-populated screen.

This may seem counter intuitive, but in cases like this, where you need to favor the perceived load speed over keeping network calls low, it works pretty well.

I hope this was informative and it has helped you brainstorm what to apply to your own projects. Good luck!


SEARCH RESULTS