DEV Community: Gosha Arinich

Reasons I use a mock API in React Native apps

Gosha Arinich — Mon, 05 Feb 2018 00:00:00 +0000

I’m doing plenty of React Native applications these days.

Something common to all of them, from a developer experience point of view, is: they avoid calling out to a real API and use fake data instead. If/when needed.

This has been a pretty useful tactic for me. This post will not dive much into how that can be achieved (since there are several ways), and will instead focus on why.

Why

1. The back-end might not be implemented yet.

It’s not unusual for the back-end to be developed along with the mobile application, and to take longer to be implemented.

This definitely should not prevent you from working on the app.

As long as back-end’s endpoints are specified somehow, you can mock them out. The spec can be anything: be it a RAML schema, a text document with the description of endpoints and their response types, or something else.

2. You can develop while on a flight.

Or in other situations when you might not have an internet connection, or be on a shitty connection.

“But you can keep a copy of the back-end locally and use that!”

First off, you can’t always have it this way. Sometimes the back-end is a black box to you, and you don’t have the sources.

Second, back-ends might want exotic dependencies and very careful configuration. You shouldn’t have to do these to develop the mobile app, for the most part.

3. Your productivity can be unaffected if the server is down or broken.

It happens, and we should just deal with it.

Not having to rely on a real API means your productivity stays unaffected.

4. You get to control latency.

You can easily reduce the “latency” of the mock to 0 to develop quickly.

You can easily set the “latency” to a couple of seconds maybe to see how your application would behave in these conditions.

Not talking to a real, remote API means you can control latency.

5. You can simulate errors.

There are a variety of errors the request can end with.

Some are within your control (like sending invalid data), while others are not:

internal server error;
session expired.

You can’t normally trigger these by yourself at will if you’re talking to a real API server.

Having a mock API means you get control over these as well.

It means you can easily test that your application behaves properly in cases like “if I get a session expired error, log the user out, show the login screen, and alert them why that happened.”

Mocking comes at a cost, but it still can be useful

Since it requires you to maintain a set of fake data and update the mock when the API changes, you don’t get mocking for free.

That said, the productivity benefits can outweigh the cost of maintaining fake data.

How

There are multiple ways to mock the API. The simplest one is to tweak your API client:

// helper function
// used as: delayedPromise(1000, "hey")
// will return a promise that will resolve with "hey" in 1000ms.
function delayedPromise(ms, value) {
  return new Promise(resolve => {
    setTimeout(() => resolve(value), ms);
  });
}

const USE_REAL_API = true; // change to `false` when needed

function getPosts() {
  if (USE_REAL_API) {
    return fetch(...);
  } else {
    // new: fake data
    return delayedPromise(500, [
      { id: 1, title: 'How to' },
    ]);
  }
}

There are more ways & more to consider when implementing the mock of an API, of course. This post will not go as far as to address that, but I will probably write about that at some point.

I blog about all things React and React Native.
If you like what you see here, subscribe here to make sure you don't miss out on my next post.

How to handle validations involving several fields?

Gosha Arinich — Wed, 13 Sep 2017 00:00:00 +0000

It’s often enough to validate each field in isolation:

email should contain a @;
password should be more than four characters.

But every once in a while, you need to validate several fields together:

password confirmation should match password;
phone number’s length depends on the country code from a separate input.

It’s hard or impossible implement that with field-level validations without unnecessarily complicating the code. However, with a simple validation architecture from the other articles, it’s pretty trivial.

A function that validates the entire form is simple:

function validate(email, password) {
  // true means invalid, so our conditions got reversed
  return {
    email: email.length === 0,
    password: password.length === 0,
  };
}

I mean, what could be simpler? And yet, it’s very powerful. Validating several fields together is easily achievable:

function validate(email, password, passwordConfirm) {
  // true means invalid, so our conditions got reversed
  return {
    email: email.length === 0,
    password: password.length === 0,
    passwordConfirm: password !== passwordConfirm,
  };
}

Try entering different passwords now:

JS Bin on jsbin.com

Once again, controlled inputs saved our day 🐶

This post was originally published on goshakkk.name

I blog about forms in React specifically, and other React-related things.
If you like what you see here, subscribe here to make sure you don't miss out on my next post.

Making dynamic form inputs with React

Gosha Arinich — Thu, 17 Aug 2017 15:12:27 +0000

Forms seemed very simple so far. Indeed, when we only have a fixed set of fields, it's pretty easy to make them into code.

In real apps, however, forms are often a bit more lively and dynamic. A common example is having a set of similar inputs that are backed by an array.

For example, say we have an incorporation form. Among other fields, a company has a variable number of shareholders.

Typically when dealing with array inputs, here are the things we can do with them:

add a new item
delete an existing item
change details of an item

How do we make a form that allows editing such an array?

Data model

It always helps to think about the data first.

It might seem simple at first.

['Shareholder 1', 'Shareholder 2']

but... in life there's always more, to everything.

Avoid primitive types.
While it might be tempting to make an array of strings to represent shareholders (or anything else that seems to only require one input), there are a couple of potential pitfalls:

Requirements change all the time. A shareholder might need an address and an amount of shares. Changing the code from array of strings to array of objects might be painful.
Using primitives, we're left with indexing the array by indices. This, however, won't play nice with features like re-ordering. Having an object means we can add a unique ID to each item easily if we need to.

A better default would be to always start with an array of objects.

{ name: '' }

It gives you a chance to give a meaningful name to the field, even if you only have one; as well as makes future additions of fields easier.

But what if I really need an array of primitives?
This storage format is convenient within the form, but it's important to note that you can send to, and receive from, the server the data in any format. Even an array of strings. You will just have to transform between an array of strings and an array of objects, and vice versa, when interacting with the server.

Operations on data

Recall that we need to do the following with the array:

add a new item
delete an existing item
change details of an item

Adding an item is easy.

For deleting an item, we're going to need to identify it somehow. An index will do for our case.

To change a field, besides an identifier, we need to know which field to change. There is more than one valid way to implement this use case:

have a generic function which accepts a field name; or
have several specialized functions, one for each field.

The former could serve well to reduce boilerplate if there are several fields. The latter could be more flexible, as it will allow to execute different logic depending on the field.

For the purpose of this post, I only have one field and will make a specialized function.

Don't mutate the array

While it could be tempting to push to the array or do something like this.state.shareholders[idx].name = newName, this is not a sound approach.

First, React will not know that something has changed if you do this. This is because React is only re-rendering when either the props or the state change. Mutating the state object, or any nested object, keeps the identity of the object, and React thinks nothing has changed.

We have to call setState with a new value to let React know it should re-render.

Second, mutations are prone to unexpected bugs. Using non-mutating methods for changing arrays is not that hard.

To add a new item, you can use the .concat method on array, and set the resulting array with setState:

this.setState({
  shareholders: this.state.shareholders.concat([{ name: '' }]),
});

To remove an item, using .filter is the easiest non-mutating alternative:

// assuming `idx` is defined and is an index of an item to remove
this.setState({
  shareholders: this.state.shareholders.filter((s, _idx) => _idx !== idx),
});

And finally, to change an existing item, we can make use of .map and Object.assign/object spread notation:

this.setState({
  shareholders: this.state.shareholders.map((s, _idx) => {
    if (_idx !== idx) return s;
    // this is gonna create a new object, that has the fields from
    // `s`, and `name` set to `newName`
    return { ...s, name: newName };
  }),
});

Piecing it all together

Rendering the input for each shareholder is trivial: we just loop over this.state.shareholders.

class IncorporationForm extends React.Component {
  constructor() {
    super();
    this.state = {
      name: '',
      shareholders: [{ name: '' }],
    };
  }

  // ...

  handleShareholderNameChange = (idx) => (evt) => {
    const newShareholders = this.state.shareholders.map((shareholder, sidx) => {
      if (idx !== sidx) return shareholder;
      return { ...shareholder, name: evt.target.value };
    });

    this.setState({ shareholders: newShareholders });
  }

  handleSubmit = (evt) => {
    const { name, shareholders } = this.state;
    alert(`Incorporated: ${name} with ${shareholders.length} shareholders`);
  }

  handleAddShareholder = () => {
    this.setState({
      shareholders: this.state.shareholders.concat([{ name: '' }])
    });
  }

  handleRemoveShareholder = (idx) => () => {
    this.setState({
      shareholders: this.state.shareholders.filter((s, sidx) => idx !== sidx)
    });
  }

  render() {
    return (
      <form onSubmit={this.handleSubmit}>
        {/* ... */}
        <h4>Shareholders</h4>

        {this.state.shareholders.map((shareholder, idx) => (
          <div className="shareholder">
            <input
              type="text"
              placeholder={`Shareholder #${idx + 1} name`}
              value={shareholder.name}
              onChange={this.handleShareholderNameChange(idx)}
            />
            <button type="button" onClick={this.handleRemoveShareholder(idx)} className="small">-</button>
          </div>
        ))}
        <button type="button" onClick={this.handleAddShareholder} className="small">Add Shareholder</button>
        <button>Incorporate</button>
      </form>
    )
  }
}

JS Bin on jsbin.com

(dev.to doesn't allow to embed the jsbin so follow the link to see it in action)

The code is not perfect, and it doesn't have to be. There are many ways to make it prettier, but this is not a post on refactoring. The code is not the point. Thinking about forms in terms of data is.

I blog about forms in React specifically, and other React-related things.
If you like what you see here, subscribe here to make sure you don't miss out on my next post.

Analytics on easy mode with Redux-Saga

Gosha Arinich — Tue, 18 Jul 2017 00:00:00 +0000

This post was originally published on goshakkk.name

Tracking how your users actually use your application can be powerful.

And to do that, you could put the window.ga(...) calls all around: inside action creators or your components.

But does that approach strike you as beautiful, in any way?

class SignUpForm extends Component {
  handleSubmit = () => {
    // fire a redux action
    this.props.doSignUp(data).then(() => {
      window.ga('track', 'CompleteRegistration');
    });
  };
}

class AddTodoForm extends Component {
  handleSubmit = () => {
    // fire a redux action
    this.props.createTodo(data).then(() => {
      window.ga('track', 'CreateTodo');
    });
  };
}

You can see where it’s going.

Can you do better?

With Redux-saga, you can. You can place all analytics-related behavior (or most of it, anyway) in a separate file. Which would “listen for certain Redux actions, and automatically track to your analytics service.

But first, what’s Redux-saga about? In its simplest form, a saga, the unif of Redux-saga, is a function like this:

function* aSaga() {
  while (true) {
    const action = yield take('ACTION_NAME');
    // do something
  }
}

It waits for a certain action to happen, then does something — whetever you want. After that, it would wait for another action to occur, and the cycle would repeat.

You could make a lot more complicated sagas, but these are a great start!

(Now, if you are wondering what this function* and yield are — these have to do with ES6 generator functions. I have a blog post explaining them in more detail.)

A more practical example would be:

// analytics-sagas.js

function* registrationAnalytics() {
  while (true) {
    yield take('USER_SIGNED_UP');
    window.ga('track', 'CompleteRegistration');
  }
  }

function* todoAnalytics() {
  while (true) {
    yield take('ADD_TODO');
    window.ga('track', 'CreateTodo');
  }
  }

sagaMiddleware.run(registrationAnalytics);
sagaMiddleware.run(todoAnalytics);

export [
  registrationAnalytics,
  todoAnalytics,
];

// when creating redux store

import analyticsSagas from './analytics-sagas.js';

// ...

analyticsSagas.forEach(saga => sagaMiddleware.run(saga));

Look at this code.

The entire functionality of analytics is now contained in one single file.

And instead of making calls to analytics in our components, we can “feed from Redux actions as they happen.

Considerations

Since sagas can only respond to Redux actions, there still might be places in your app where you would inline analytics calls right inside components. However, even so, you’d be still better off than with inlining everything.

Other uses for sagas

The Lazy Registration pattern.

References

Understanding ES6 generators and their use cases

If you like what you see here, subscribe on my blog to make sure you don't miss out on my next posts about React and Redux.

Where does authentication fit in a React Native app?

Gosha Arinich — Wed, 17 May 2017 00:00:00 +0000

This post was originally published on goshakkk.name

In a web app, you could use cookies or store a token in a localStorage…

But how do you keep a user logged in in your React Native app?

But first… let’s zoom out a little and rehash what developers commonly mean when they say “auth in terms of a user-facing application:

a way for the user to sign in;
a way to ‘save’ the user’s session;
a way to let the server know who the user is.

Most often, authentication is done using tokens.

The concept of token authentication is not limited to React Native apps, however; native mobile and desktop apps, as well as many web apps, all make use of tokens.

In simple terms, token authentication means this:

Instead of passing username and password with each request to the server, we pass in some random-ish string along with each request, called a token. We obtain this token by making a “login request to the server with username and password.

A way for the user to sign in

The user has to prove us they are who they say they are, usually by entering their username and password. The UI that makes that happen is not the point, though, as it will vary by application.

The most certain thing at this stage is: we will use the entered username and password to ask the server to give us a token.

A way to save the user’s session

Life wouldn’t be fun if, every time you opened the Twitter app, you had to enter your credentials all over again.

Web apps have it easy: there are cookies, and then there’s also localStorage.

Say we have a token that we want to save. What do you do in a React Native app, though?

Two options:

1. Use AsyncStorage that’s bundled with React Native. Used like this:

// to set
AsyncStorage.setItem('@app:session', token);

// to get
AsyncStorage.getItem('@app:session').then(token => {
  // use token
});

It’s easy to use, but it has security implications: everything is stored in plain text, not encrypted. Therefore, on rooted/jailbroken devices, other apps may access the data of yours. Additionally, with physical access, it’s possible to extract the application data, including the tokens.

2. iOS comes with Keychain, a way to securely store credentials data. On Android, there’s also a way to store data securely.

You can, therefore, use the react-native-keychain React Native library to make use of these options.

// to set
Keychain.setGenericPassword('session', token);

// to get
Keychain.getGenericPassword.then(creds => creds.password).then(token => {
  // use token
});

A way to let the server know who the user is

This is usually achieved by passing the token using headers, for example.

Like in a browser environment, you can use fetch in React Native. And sending headers with fetch is pretty easy:

// assuming `token` is already fetched somehow

const headers = {
  Authentication: `Bearer ${token}`,
};

fetch(path, { method: 'GET', headers: headers }).then(...);

If you like what you see here, subscribe on my blog to make sure you don't miss out on my next posts about React Native and React.

Should a React form for editing update the underlying model?

Gosha Arinich — Tue, 21 Mar 2017 00:00:00 +0000

In an imaginary world where forms are only ever used to enter something from scratch, what you know about forms in React might be enough. In the real world, however, forms are often lively creatures – you can come back to them and change your data.

Up until now, our forms were pretty stand-alone and isolated.

Forms for entering new data start out like this:

constructor() {
  super();
  this.state = {
    email: '',
    password: '',
  };
}

and they are used something like this, perhaps:

<SignUpForm />

We can see they don’t receive any props, they keep the current values in the state, and they initialize the state with empty values. Which is perfect if all you need is to collect brand new data through the form.

But what if you had a different form… for editing a post, for example. It would somehow have to accept current title and body. Maybe like this:

<PostForm title={someTitle} body={someBody} />

Except now there are several possibilities as of how to go further with this:

Make the form itself fully controlled with regard to its parent. It means instead of keeping its own state, the form is always going to receive field values, as well as callbacks to change them. Just like with controlled/uncontrolled inputs, this will make an entire form controlled.

  <PostForm
    title={...}
    body={...}
    onChangeTitle={...}
    onChangeBody={...}
  />

This is not a usual case, however. Only a subtle fraction of forms out there needs to have something like that. It could be used when the changes to the form, as you make them, need to be immediately reflected in the rest of the app.

And it’s not without its drawbacks, either. Doing it this way means invalid unsaved data now has a way out of the form: if you are directly updating some global state with work-in-progress form values, your app may end up consuming partial or errneous data.

Initialize the form state via props. The form will still have its own state with input values. It will simply use the passed field values as a starting point.

Used as:

  <PostForm title={someTitle} body={someBody} />

The form is going to take initial props, which will be passed to its constructor, and set initial state based on them:

  class PostForm extends React.Component {
    constructor(props) {
      super(props);
      this.state = {
        title: props.title || '',
        body: props.body || '',
      };
    }
  }

In a way, this is similar to making the form “uncontrolled” with respect to its parent. It maintains its own state, and uses the passed props as default values of the fields.

New values should be communicated to the parent when the form is submitted:

  <PostForm
    title={someTitle}
    body={someBody}
    onSubmit={(newTitle, newBody) => { ... }}
  />

Unlike with individual inputs, having a form “uncontrolled” is a preferred method to make a form. A form is not a way to change a thing directly, rather, it’s a request to change one.

Think about paperwork to change the name. It doesn’t directly change your name as you fill it in; it doesn’t “bind” to your name. It is just initialized with some data (your current name), and you fill in the new name and take it to bureaucrats before it has any effect.

And the same is often true of forms on the web – they do something only when submitted.

This post was originally published on goshakkk.name

I blog about forms in React specifically, and other React-related things.
If you like what you see here, subscribe here to make sure you don't miss out on my next post.