DEV Community: Vlad R

Protect your React Native application using Cloudflare Turnstile.

Vlad R — Tue, 21 Feb 2023 11:48:04 +0000

Quick overview:

Turnstile is Cloudflare’s smart CAPTCHA alternative. It can be embedded into any website without sending traffic through Cloudflare and works without showing visitors a CAPTCHA.

Turnstile has a great documentation. Here is the link.

Here is how it looks like:

How it works:

Turnstile is a front-end widget that creates a token which is cryptographically secured. However, the customer cannot check the validity of the token on their end. To ensure that a token is not forged by an attacker or has not been consumed yet, the customer needs to check the validity of a token using Cloudflare’s siteverify API. A Turnstile token is valid for 300 seconds. It refreshes automatically.

Widget types:

There are three types of Turnstile widget:

A non-intrusive interactive challenge (such as clicking a button), if the visitor is a suspected bot.
A non-interactive challenge.
An invisible challenge to the browser.

Pricing:

Turnstile is currently in open beta and available as a free tool, but there are still some limitations.

React Native integration:

Turnstile doesn’t offer an easy and official way to embed Turnstile into a React Native application. The only one way to render the widget in RN app is by using WebView component.

We also gonna use the invisible type of widget(set widget type in the CF dashboard). Which means our users won’t see any widget at all and we won’t have to try to style an iframe inside of an iframe in order to fit the widget into our design.



const Turnstile = () => {
  const dispatch = useDispatch();

  const handleMessage = (event) => {
    //  Now we can add this token to any request header.
    //  Where backend will verify the token using Cloudflare API.
    const token = event.nativeEvent.data;
    dispatch(setTurnstileToken(token));
  };

  return (
    <View>
      <WebView
        originWhitelist={['*']}
        onMessage={handleMessage}
        source={{
          baseUrl: '{your base url}',
          html: `
                <!DOCTYPE html>
                <html>
                  <head>
                   <script src="https://challenges.cloudflare.com/turnstile/v0/api.js?onload=_turnstileCb" async defer></script>
                  </head>
                  <body>
                     <div id="myWidget"></div>
                     <script>
                        // This function is called when the Turnstile script is loaded and ready to be used.
                        // The function name matches the "onload=..." parameter.
                        function _turnstileCb() {
                            turnstile.render('#myWidget', {
                              sitekey: '{your siteKey}',
                              callback: (token) => {
                                // Success callback, which sets the token into a separate store slice.
                                window.ReactNativeWebView.postMessage(token);
                              },
                            });

                        }
                     </script>
                  </body>
                </html>
            `,
        }}
      />
    </View>
  );
};

Don’t forget to change baseUrl and siteKey props.

Then import the component above to the App component.



const App = () => {
  return (
     ...
     <Turnstile />
  )
}

That’s about it. Easy. Hope sometimes soon we’ll be able to use other types of the widget.

Photo by José Ramos

Singleton design pattern. JS/TS Examples.

Vlad R — Sun, 21 Nov 2021 15:47:52 +0000

Implementation
Pros and Cons
Examples

So why do we need to know design patterns?

First of all it helps you to save your time. Programming is not a new thing, a lot of problems have been already solved before. Lots of patterns and approaches have been invented and most of them are time tested. If you don't want to reinvent the wheel, you might be interested to know more about those preexisting patterns and approaches.
So design patterns are typical solutions to commonly occurring problems in programming.

In this short article we are going to cover the singleton design pattern. This pattern is a type of creational design patterns and probably one of the simplest ones.

Implementation

The Singleton pattern is just a way of creating a single object that is shared amongst a bunch of different resources throughout your application without having to recreate that object or losing the information inside of it.

1. It ensures that there is only one instance of a given class
For example we may create a logger class which prints logs and keeps them inside the class. Following this patters you have to have a single instance of the logger which prevents losing/overwriting the logs list.

2. This pattern also provides a way to access the single instance globally
Going back to our logger class, it's pretty much obvious that we need it to be accessible from any file in our project. Because errors may appear anywhere and we want to log them.

Pros and Cons

Pros (Global variables vs Singleton):

Comparing to global variables, Singletons can not be modified(speaking of var in JS).
Unlike global variables it doesn't exist until instantiated.
Another advantage is that you are absolutely sure of the number of instances.
You can manage the state of that instance.

Cons of using this design pattern:

Someday when you have a lot of parts of your app rely on that Singleton obj it may became hard to change Singleton obj itself.
As we already know Singleton's methods could be called from different parts of your app simultaneously at the same time which may cause a data/variables within this object to be overwritten/read incorrectly.

FYI: there are more cons actually, but we're not going to cover all of them in this article.

Examples

JS Example:

class SingletonLogger {
  // prevent modifying the instance property,
  // for example set it to null to create a second instance.
  static #instance;
  // prevent modifying/overwriting logs array.
  #logs = [];

  // classes in JavaScript...
  //    may not have a private field named '#constructor'
  // so it's not possible to disable...
  //    calling constructor() {} in JS.
  // if you try new SingletonLogger()...
  //    with private constructor in TS it will throw an error
  constructor() {
    if (SingletonLogger.#instance) {
      throw new Error('Can not instantiate second singleton');
    }
    SingletonLogger.#instance = this;
  }

  // getInstance should be static...
  //    to be able to call SingletonLogger.getInstance()
  static getInstance() {
    if (!SingletonLogger.#instance) {
      SingletonLogger.#instance = new SingletonLogger();
    }
    return SingletonLogger.#instance;
  }

  log(error) {
    this.#logs.push(error);
    console.log(error);
  }

  // since #logs array is private, we need to create a getter
  get logsArray() {
    return this.#logs;
  }
}

// Usage:
const logger = SingletonLogger.getInstance();
try {
  throw new Error('first err');
} catch(err) {
  logger.log(err); // log: first err
}
console.log(logger.logsArray); // log: [first err]

const logger2 = SingletonLogger.getInstance();
try {
  throw new Error('second err');
} catch(err) {
  logger2.log(err); // log: second err
}
console.log(logger2.logsArray); // log: [first err, second err]

// const logger3 = new SingletonLogger();
// Error: Can not instantiate second singleton

TS example:

class SingletonLogger {
    private static instance: SingletonLogger;
    private logs: Array<Error> = [];

    private constructor() { }

    public static getInstance(): SingletonLogger {
        if (!SingletonLogger.instance) {
            SingletonLogger.instance = new SingletonLogger();
        }
        return SingletonLogger.instance;
    }

    log(error: Error) {
        this.logs.push(error);
        console.log(error);
    }

    get logsArray() {
        return this.logs;
    }
}

// Usage:
// const singleton = new SingletonLogger(); // ...
//    TS won't let you do this
// Constructor of class 'SingletonLogger' is private...
//    and only accessible within the class declaration.

const singleton = SingletonLogger.getInstance();
try {
    throw new Error('first err');
} catch(err) {
    singleton.log(err as Error); // log: first err 
}
console.log(singleton.logsArray); // log: [first err] 

const sameSingleton = SingletonLogger.getInstance();
try {
    throw new Error('second err');
} catch(err) {
    sameSingleton.log(err as Error); // log: second err 
}
console.log(sameSingleton.logsArray); // log: [first err, second err]

Conclusion

To be honest I haven't found any use cases in Front End development where singleton design pattern would be really helpful. Of course you can create the same logger as we did above or use the cache as a singleton object. But I personally think you will rarely have to use it.
Anyways, this design pattern is a part of Gang of Four design patterns and knowing all these patterns will take you to the next level as a dev.

Thanks for reading! Any feedback is appreciated!😊

Photo by Lucas Campoi

Cypress testing. 5 tips you may find useful.

Vlad R — Wed, 21 Jul 2021 14:50:05 +0000

Environment variables

Today mostly while building a web app we all try to use at least two environments. It helps us to ensure that all new changes deployed from previous environments are working as intended before they will be pushed to production. And you probably have different databases, api endpoints and variables for each environment. So,

When it comes to cypress, you can also have a separate config file for each environment.

File structure and file names are optional:

/src/cypress/config
                  /test.json
                  /staging.json
                  /production.json

Let's take a look at staging.json:

{
  "baseUrl": "http://localhost:3000",
  "env": {
    "env": "staging",
    "apiUrl": "https://staging-api.com/api/v1",
  }
}

And production.json:

{
  "baseUrl": "http://localhost:3000",
  "env": {
    "env": "production",
    "apiUrl": "https://api.com/api/v1",
  }
}

(!)Make sure you store your env variables inside env object

Then update cypress scripts in package.json to make sure you run cypress with needed config for each env:

"scripts": {
 "cypress:run:staging": "cypress run --env configFile=staging",
 "test:e2e:staging:run": "start-server-and-test 'npm run start' http://localhost:3000 'npm run cypress:run:staging'",

 "cypress:run:production": "cypress run --env configFile=production",
 "test:e2e:production:run": "start-server-and-test 'npm run start' http://localhost:3000 'npm run cypress:run:production'",
}

// same approach could be used for "cypress open" command.

"start-server-and-test" module runs your app and right after that triggers cypress tests.

Then update src/cypress/plugins/index.js with the following code:

const fs = require('fs')
const path = require('path')

function getConfigurationByFile(fileName) {
  const pathToConfigFile = path.resolve(__dirname, `../config/${fileName}.json`);
  let rawData;
  try {
    rawData = fs.readFileSync(pathToConfigFile);
  } catch (e) {
    console.error(e);
  }
  return JSON.parse(rawData);
}

module.exports = (on, config) => {
  // `on` is used to hook into various events Cypress emits
  // `config` is the resolved Cypress config

  // this value comes from *cypress run --env configFile=staging*
  const configFile = getConfigurationByFile(config.env.configFile || 'test');

  return { ...config, ...configFile };
};

Great! So now when we have our cypress up and running with needed env config, we can use values from that configs in our tests..

If you've done everything correct, then you are able to extract the variables by doing the following:

const { apiUrl, env } = Cypress.env();
// to extract baseUrl variable you should use Cypress.config()
// const { baseUrl } = Cypress.config();

Change fixture's values on the fly based on env

Basically fixtures is being used when you need to mock an API response, which is not recommended though
But when you have a few environments sooner or later you will face an issue when the same requests return the same data for each env except a few values(e.g. id). And you might not want to duplicate the whole fixture.

In this case all you need to do is to extract a fixture and your env variable; then update needed value on the fly within a test case:

describe('it should test smth', function() {
  beforeEach(() => {
    // user is a env variable
    const { user: userEnv } = Cypress.env();

    cy.fixture('user.json').then(user => {
      user.id = userEnv.id; // updating user id
      // use updated fixture here (e.g. `cy.intercept`)
    });
  });
});

(!)If you use beforeEach, make sure you wrap it in describe, so it won't affect other tests.

Here is the link to fixture docs

Mock API response globally

To stub network request globally, you should open src/cypress/support/index.js file and add the following code:

beforeEach(() => {
  cy.intercept({ url: `${apiUrl}/profile*`, middleware: true }, req => {
    req.reply({
      fixture: 'getProfile.json',
    });
});

Here is the link to itercept docs

Custom commands

Custom commands in Cypress prevent you from having to add boilerplate code to your tests.
Take a look at this file:

 // you can turn this piece of code
 it('should fill in discount form', function() {
    cy.get('input[name="email"]').type('test@test.com');
    cy.get('input[name="phone"]').type('1231231212');
    cy.get('div[role="checkbox"]').click({ force: true });
    cy.findByText(/Save/i).click({ force: true });
    // ...rest of the test
  });

// into a single line
it('should fill in discount form', function() {
 cy.fillDiscountForm();
 // ...rest of the test
});

To create cy.fillDiscountForm() command you should go over to the file at src/cypress/support/commands.js and create a custom command there:

Cypress.Commands.add('fillDiscountForm', function() {
  cy.get('input[name="email"]').type('test@test.com');
  cy.get('input[name="phone"]').type('1231231212');
  cy.get('div[role="checkbox"]').click({ force: true });
  cy.findByText(/Save/i).click({ force: true });
});

That's it! Now you can use cy.fillDiscountForm() in any test.

Here is the link to custom commands

Waiting on a request

Before your app displays any data, it will probably get it from the server. What if you have poor internet connection and all your tests are failing due to unfinished API requests, and lack of the data to display? In this case, and probably every time you make an API call, you should wait (cy.wait) for the API call to finish before doing any assertions.

it('should fill in discount form', function() {
  cy.intercept(`${apiUrl}/settings`).as('getSettings');
  cy.visit(`/settings-page`);
  // once a request to get settings responds, 'cy.wait' will resolve
  cy.wait('@getSettings');
  // rest of the test
  // cy.contains(/edit settings/i).click({ force: true });
});

All we need to do is to register the intercept before visiting the settings page. Once we visit the settings page, it will trigger GET ${apiUrl}/settings request, and cypress will wait till it finishes and only after that will continue the testing.

Furthermore, if the API call fails for some reason, then Cypress will display an error and it will be much easier to debug.

Here is the link to wait docs

Cover image by Tianyi Ma