Forem: Michael Lefkowitz

How do YOU keep track of weekly 1:1s?

Michael Lefkowitz — Thu, 28 May 2020 20:41:09 +0000

I've been utilizing Confluence to keep track of weekly 1:1s with my team for a bit now and honestly neither party finds it intuitive to work with in the slightest.

Curious what methods, tools, techniques, software etc is out there that others are using to keep track of weekly 1:1s.

Create a root-level modal store in React Native

Michael Lefkowitz — Wed, 08 Jan 2020 19:45:21 +0000

Want to stay up-to-date? Check out React Native Now, the bi-weekly React Native newsletter

In the original design and flows of our React Native apps, we utilized the native Alert for a few different needs - but primarily they were error, confirmation, and success notifications.

These worked well in most cases for the past year for most every case we had ever needed them - the only issue we ever had was a lack of styling flexibility, so items in a list for instance would end up center aligned on iOS, which was less than ideal.

Success notifications were used most often - the alerts would usually appear following a successful API response after filling out a form, which historically had been built as single screens. When these success notifications were triggered, we would also kick our navigation back a screen or two so our users would be where we wanted them.

The problem

As our design team begun to share mocks of screens with us that had a fresh coat of paint on them, they also had a major change in many of our original flows. The idea is to move away from scrolling, single screen forms to a more mobile-friendly, multi screen flow. In addition, these new designs replaced our native alerts with full screens that was more consistent with our branding and enabled us to style them with greater flexibility.

While our engineering team liked the look of these new flows and success screens, replacing our native alerts with them proved to be more work than we expected - by making the alert into a separate screen, we now lost the ability to trigger a navigation "behind the scenes" while the user was interacting with our alert. And, since we were also moving from single screen to multi screen forms, we couldn't simply replace the current screen in the stack with a success screen.

The solution

Because of this "behind the scenes" magic we were introducing, we wanted to avoid having the modal as part of our navigation stack completely. To handle this, we created a modal store within Redux and a Modal component at the root of our app - which we'll walk through the basics of how to create in this tutorial. This same pattern could be applied to your choice of state management solution if Redux doesn't work for you.

To start, we'll initialize a new React Native project. Then, add React Navigation with a couple dummy screens and Redux. In our Redux store, we'll setup a modal reducer that has an id field. I used the React Native CLI to start, but you may be able to simplify things by utilizing Expo. To see what our project looks like so far, check it out here.

Great, now that we have a baseline project setup, let's discuss the main steps involved in building this out:

Create a connected-RootModal component at the root of our App
Create unique views within the parent Modal
Let the store drive the visibility of the RootModal (and specific view)
Add support for props

Alright, let's get started.

1. Create a connected-RootModal component at the root of our App

First step, we'll create a file called RootModal.js that will look like this:

import * as React from 'react';
import {Modal, Button, View} from 'react-native';
import {connect} from 'react-redux';

export class RootModal extends React.Component {
  render() {
    return (
      <Modal visible={true} animationType="fade" testID="modal">
        <View
          style={{
            flex: 1,
            padding: 20,
            justifyContent: 'space-between',
          }}>
          <View />
          <Button onPress={() => {}} title="Close" color="blue" />
        </View>
      </Modal>
    );
  }
}

const mapStateToProps = state => {
  return {
    id: state.modal.id,
  };
};

export default connect(mapStateToProps)(RootModal);

Here, we've created a very simple connected-component that displays a native Modal with a button at the bottom.

Then, we will import it into our App.js and drop it in.

import RootModal from './src/modals/RootModal';

export default class App extends React.Component {
  render() {
    return (
      <Provider store={store}>
        <Navigation />
        <RootModal />
      </Provider>
    );
  }
}

Now when we refresh our app, we should see something like this:

Exactly what we want, a root-level Modal that covers up the rest of our app. Click here to see what our project currently looks like.

2. Create unique views within the parent Modal

Next, we're going to create some unique views / components that the root modal can display. For simplicity sake in this tutorial, we aren't going to make anything too fancy - but it should be enough to spark your understanding of the concept.

Let's make two new files - Success.js and Error.js

import * as React from 'react';
import {Text, View} from 'react-native';

export default class Success extends React.Component {
  render() {
    return (
      <View
        style={{
          flex: 1,
          justifyContent: 'space-between',
        }}>
        <View />
        <Text style={{fontSize: 20, textAlign: 'center'}}>
          Congratulations. The thing you wanted to happen has happened.
        </Text>
        <View />
      </View>
    );
  }
}

import * as React from 'react';
import {Text, View} from 'react-native';

export default class Error extends React.Component {
  render() {
    return (
      <View
        style={{
          flex: 1,
          justifyContent: 'space-between',
        }}>
        <View />
        <Text style={{fontSize: 25, color: 'red', textAlign: 'center'}}>
          There has been an error.
        </Text>
        <View />
      </View>
    );
  }
}

Now, we want to import them into our RootModal file and test out displaying them - so we'll replace that placeholder empty View we had.

import Error from './Error';
import Success from './Success';

const Modals = {
  Error: Error,
  Success: Success,
};

export class RootModal extends React.Component {
  render() {
    return (
      <Modal visible={true} animationType="fade" testID="modal">
        <View
          style={{
            flex: 1,
            padding: 20,
            justifyContent: 'space-between',
          }}>
          <Modals.Success />
          <Button onPress={() => {}} title="Close" color="blue" />
        </View>
      </Modal>
    );
  }
}

Let's take a look and see what this looks like now when using Modals.Success and Modals.Error

Perfect. Click here to see what our project currently looks like.

3. Let the store drive the visibility of the RootModal

Now for the fun part. What we want to do setup our store to set and unset a specific id. Our RootModal component will then look at that id and then determine which modal to display. If the id is empty, no modal will be shown.

First, we'll create a ModalActions.js and create two actions - one that will set an id and another that will clear it out.

const showModal = ({id}) => {
  return dispatch => {
    dispatch({
      type: 'MODAL__SET_ID',
      payload: id,
    });
  };
};

const hideModal = () => {
  return dispatch => {
    dispatch({
      type: 'MODAL__SET_ID',
      payload: '',
    });
  };
};

export const ModalActions = {
  showModal,
  hideModal,
};

Then, we'll update our ModalReducer to support these actions:

export const id = createReducer(ID_INITIAL_STATE, {
  ['MODAL__SET_ID'](state, {payload}) {
    return payload;
  },
});

Next, we need to update our RootModal. First we need to add mapDispatchToProps to our Redux-connection and import our new hideModal action. Then, we'll create a constant that assigns to a component based on the id in our store and update the native Modal component to be displayed only if that id is truthy. And finally, inject the custom view into the Modal. All together, it should look like this:

import * as React from 'react';
import {Modal, Button, View} from 'react-native';
import {connect} from 'react-redux';
import Error from './Error';
import Success from './Success';

// import our new actions
import {ModalActions} from '../store/modules/Modal/ModalActions';

const Modals = {
  Error: Error,
  Success: Success,
};

export class RootModal extends React.Component {
  render() {
    const {id, hideModal} = this.props;

    // assign a constant that is either one of our custom views or a noop function if the id is not set
    const ModalView = Modals[id] || function() {};

    return (
      // show the Modal if the id is set to a truthy value
      <Modal visible={Boolean(id)} animationType="fade" testID="modal">
        <View
          style={{
            flex: 1,
            padding: 20,
            justifyContent: 'space-between',
          }}>
          {/* inject the custom view */}
          <ModalView />
          <Button onPress={hideModal} title="Close" color="blue" />
        </View>
      </Modal>
    );
  }
}

const mapStateToProps = state => {
  return {
    id: state.modal.id,
  };
};

// add hideModal action to props
const mapDispatchToProps = {
  hideModal: ModalActions.hideModal,
};

const ConnectedRootModal = connect(
  mapStateToProps,
  mapDispatchToProps,
)(RootModal);

export default ConnectedRootModal;

Lastly, we'll update one of our screens to support our new showModal action and add a couple buttons to support displaying our RootModal.

<Button
  title="Open Success Modal"
  onPress={() => {
    this.props.showModal({id: 'Success'});
  }}
/>
<Button
  title="Open Error Modal"
  onPress={() => {
    this.props.showModal({id: 'Error'});
  }}
/>

All wrapped up - here's what this looks like (and here's our project at its current stage):

4. Add support for props

How can we make this pattern a little more flexible? For one, we should setup an additional reducer that takes in some custom props that will be passed through to our custom views. All we have to is create the action and reducer to support it and spread those props in on our RootModal.

To handle this, we'll first update our showModal and hideModal actions

// add to showModal
dispatch({
  type: 'MODAL__SET_MODAL_PROPS',
  payload: modalProps,
});

// add to hideModal
dispatch({
  type: 'MODAL__SET_MODAL_PROPS',
  payload: {},
});

Then, we'll add a modalProps reducer to our ModalReducers file

const MODAL_PROPS_INITIAL_STATE = {};

export const modalProps = createReducer(MODAL_PROPS_INITIAL_STATE, {
  ['MODAL__SET_MODAL_PROPS'](state, {payload}) {
    return payload;
  },
});

export const ModalReducer = combineReducers({
  id,
  modalProps,
});

Next, we'll modalProps to our mapStateToProps in the RootModal file and spread those props in:

<ModalView {...this.props.modalProps} />

And finally, when we are calling our showModal action, we'll be able to pass along any additional props that may be relevant, and update those unique views to support them.

// HomeScreen.js
<Button
  title="Open Error Modal"
  onPress={() => {
    this.props.showModal({
      id: 'Error',
      modalProps: {errorMessage: this.state.errorMessage},
    });
  }}
/>

// Error.js
<Text style={{fontSize: 20, color: 'green', textAlign: 'center'}}>
  {this.props.errorMessage}
</Text>

Our project now looks like this, and here's a preview of how everything looks all wrapped up:

Final thoughts

Hopefully this tutorial has given you enough context to help use this concept as a starting point for however you may need to utilize a custom store-backed root-level modal. In our apps, our RootModal is a little more "dumb" than this example - and we leave all actions, including closing, to the Redux-connected inner views. Also, we eventually ran into an issue related to this long-standing bug when building out this pattern - which led us to replace our use of a native Modal with the react-native-root-modal library. Hopefully you don't need that extra step, but it is worth mentioning.

How to create custom forms with validation and scroll to invalid logic in React Native (Part three: Improvements)

Michael Lefkowitz — Mon, 07 Oct 2019 15:23:21 +0000

Want to stay up-to-date? Check out React Native Now, the bi-weekly React Native newsletter

In the last part of this series, I’ll go over some ways we can further improve our custom validation forms and share some final thoughts on handling forms in React Native.

Fragments

When we first started building our custom forms, Fragments had not yet landed in React Native - so we needed to handle inputs within nested views by applying the scroll to invalid logic to the wrapping View itself, something we touched on in part two. While this workaround solved our issues completely, it was not always the most elegant solution, especially if our input had additional elements above it within the nested view - which then required us to set an offset amount to the location of the element on the screen.

Fortunately, the Fragment element is now available to alleviate this issue.

Looking back at our demo app, if we wanted to add a input to capture the birth year of our user, and nest it within the same View as our other birthday inputs - it would look something like this:

<View
  onLayout={({ nativeEvent }) => {
    this.setInputPosition({
      ids: ["birthday_month", "birthday_day"],
      value: nativeEvent.layout.y
    });
  }}
>
  <Text>Birthday?</Text>
  <View style={styles.split}>
    // month and day inputs here
    <TextInput />
    <TextInput />
  </View>
  <View
    onLayout={({ nativeEvent }) => {
      this.setInputPosition({
        ids: ["birthday_year"],
        value: nativeEvent.layout.y
      });
    }}
  >
    <TextInput
      style={styles.input}
      placeholder="Year"
      onChangeText={value => {
        this.onInputChange({ id: "birthday_year", value });
      }}
    />
    {this.renderError("birthday_year")}
  </View>
</View>

As we’ve mentioned, the issue here is that our helper methods would detect the input position of the birthday_year View within the context of the parent birthday_month, birthday_year View. Now, with the help of Fragment, we can swap out the parent View with an element whose sole purpose is to wrap other elements, without providing any styling - which is exactly what we need in this situation.

<Fragment>
  <Text>Birthday?</Text>
  <View
    onLayout={({ nativeEvent }) => {
      this.setInputPosition({
        ids: ["birthday_month", "birthday_day"],
        value: nativeEvent.layout.y
      });
    }}
    style={styles.split}
  >
    // month and day inputs here
    <TextInput />
    <TextInput />
  </View>
  <View
    onLayout={({ nativeEvent }) => {
      this.setInputPosition({
        ids: ["birthday_year"],
        value: nativeEvent.layout.y
      });
    }}
  >
    <TextInput
      style={styles.input}
      placeholder="Year"
      onChangeText={value => {
        this.onInputChange({ id: "birthday_year", value });
      }}
    />
    {this.renderError("birthday_year")}
  </View>
</Fragment>

If you’re still following along with the demo app, it looks like this at the moment.

Touched

Another improvement I would highly recommend is to add the concept of “touched” to your inputs. Currently, if a user starts to enter 1989 in the birth year input, they’ll see a validation error as soon as they’ve entered in the very first character, because 1 falls out of the acceptable range we’ve setup between 1900 and 2019. While this is technically correct, it is a poor user experience to see validation errors when you haven’t yet finished typing.

To handle this issue, we’re going to introduce the concept of “touched” - so our validation will only trigger after the first time a user interacts with an input and then moves on to the next input. To do this properly without making a mess of our form, we’ll first create a FormInput component to house a lot of this logic in a repeatable way.

import React, { Component, Fragment } from "react";
import { StyleSheet, Text, TextInput, View } from "react-native";

export default class FormInput extends Component {
  constructor(props) {
    super(props);
    this.state = {};
  }

  renderError() {
    const { errorLabel } = this.props;
    if (errorLabel) {
      return (
        <View>
          <Text style={styles.error}>{errorLabel}</Text>
        </View>
      );
    }
    return null;
  }

  render() {
    const { label } = this.props;
    return (
      <Fragment>
        <Text>{label}</Text>
        <TextInput style={styles.input} {...this.props} />
        {this.renderError()}
      </Fragment>
    );
  }
}

const styles = StyleSheet.create({
  input: {
    borderWidth: 1,
    borderColor: "black",
    padding: 10,
    marginBottom: 15,
    alignSelf: "stretch"
  },
  error: {
    position: "absolute",
    bottom: 0,
    color: "red",
    fontSize: 12
  }
});

Now that we’ve abstracted our general form inputs into a reusable component, we’ll be able to add some functionality to them in a cleaner and more reusable way. This is how our form currently looks using this new component.

The first thing we’ll want to do is setup local state in our FormInput to house the touched state.

this.state = {
  touched: false
};

Next, we’ll want to update the error handler to only render if the input has been touched.

  renderError() {
    const {errorLabel} = this.props;
    if (errorLabel && this.state.touched) {
      return (
        <View>
          <Text style={styles.error}>{errorLabel}</Text>
        </View>
      );
    }
    return null;
  }

And finally, we’ll want to use the built-in onBlur prop on our TextInput to update our local state whenever a user taps away from the input.

  // make sure to bind this to the constructor
  onBlur() {
    this.setState({
      touched: true,
    });
  }

  // then add the prop
  <TextInput style={styles.input} {...this.props} onBlur={this.onBlur} />

Now that we have that setup, let’s see how our input now handles entering in a year.

Great. We now validate the input after the first blur - so any subsequent edits will highlight any issues that may be present.

Now, what if the user skips an input entirely and clicks submit? The input would be invalid since it’s required, but our error message would not display because the internal state of our input is still flagged as un-touched.

To handle this, we’re going to add the concept of a touched state to the parent form for each individual input, and handle most of the logic in our validation helpers.

First, we’ll update our error rendering to look for the touched prop OR the touched flag in state.

const { errorLabel, touched } = this.props;
if (errorLabel && (touched || this.state.touched)) {
  // render error
}

Next, we’ll update each use of our FormInput component to accept a touched prop.

<FormInput
  touched={inputs.first_name.touched}
  // existing props
/>

And finally, we’ll need to update two methods in our validation helpers. The first one is getInputValidationState. We want to add touched as a parameter and have it return that value OR the value set to state of the individual input.

function getInputValidationState({ input, value, touched }) {
  return {
    ...input,
    value,
    errorLabel: input.optional
      ? null
      : validateInput({ type: input.type, value }),
    touched: touched || input.touched
  };
}

And then we’ll need to update getFormValidation - so that when we call getInputValidationState within it, we will force the touched flag to be true. It will look like this:

function getFormValidation() {
  const { inputs } = this.state;

  const updatedInputs = {};

  for (const [key, input] of Object.entries(inputs)) {
    updatedInputs[key] = getInputValidationState({
      input,
      value: input.value,
      touched: true
    });
  }

  this.setState({
    inputs: updatedInputs
  });

  return getFirstInvalidInput({ inputs: updatedInputs });
}

This way, when a user clicks submit - we’ll ensure that the touched flag is forced to truthy for every input - which will reflect in our input’s individual validation state if they are invalid thanks to the new prop.

That’s it - now your forms will validate, without being annoying to the end user. To see all the changes we’ve made in this section, go here.

All wrapped up, our form looks like this.

Libraries

If rolling your own form validation isn’t something you’re interested in, you may have luck using a library to assist you. Recently, the ecosystem for handling forms on React Native has begun to expand. There are quite a few options out there - none of which we’ve personally tested but they are worth mentioning nonetheless.

You may have luck with a solution such as Redux Form, React Final Form, or Formik. For a walkthrough on these three options - check out this video. You could also check out React Hook Form - this one is a bit newer but the demo looks fantastic.

You may also consider using a supplemental library such as react-native-scroll-into-view, which looks like it could simplify some of the trickier scroll-to-invalid that we’ve covered.

And finally, I’ve gone ahead and setup the demo repo to export the helper methods - so you can import react-native-form-helpers into your project for ease of use. Feel free to submit any feedback or PRs on it.

Final Thoughts

At first launch of our React Native apps, our design team was relatively non-existent, which led our engineers to lead decisions in our design and user experience. Since that time, both our design and engineering teams have grown and we’ve begun to move away from the scroll-to-invalid pattern in our forms, replacing them with multi-screen flows. While the validation logic lives on - we believe the pains of filling forms on a mobile device are better alleviated by providing a small subset of questions that will fit within one screen at a time.

There are certainly pros and cons to both sides of this argument and your app may very well benefit from having longer forms on your side. It’s certainly worth having a conversation around and deciding on what’s best for the end user with consideration to the engineering resources available on your team.

Thanks for following along on this three part tutorial. Feel free to share any feedback or questions below.

Fantasy Football Team Names for Developers (and other geeks)

Michael Lefkowitz — Thu, 05 Sep 2019 21:31:49 +0000

After seeing Ben's post regarding a DEV Fantasy Football League, I started brainstorming nerdy team names for a developer league.

Here's what I've come up with so far - feel free to chime in with any more suggestions.

Computer Zeke
Zeke Squad
MIT Smith
Black Gurleys Code
sudo win
Code Beasley
Automated Dak-ups
dd($westbrook);
DEVante Adams
DEVonta Freeman
Odudeyouregettingadell Beckham Jr.
Hooli-o Jones
Patrick MaHomeScreen
RTFM Sanders
Los Angeles RAM Limits
Los Angeles I Forgot My Chargers
Houston RichTexansFormat
Arizona Memorycardinals
Green Bay Hewlett Packers
Kansas City CTOs

The season starts tonight! Good luck to everyone out there playing in a league. 🤓🏈

How to create custom forms with validation and scroll to invalid logic in React Native (Part two: Scroll to invalid)

Michael Lefkowitz — Mon, 08 Jul 2019 15:02:37 +0000

Want to stay up-to-date? Check out React Native Now, the bi-weekly React Native newsletter

In the first part of this series, we walked through creating a simple form with some helper methods that enabled us to roll our own validation logic. In this part, we'll walk through how we can make our forms automatically scroll up to the first invalid element.

Locating the elements

The first step needed to accomplish this will be to ensure our local state's input objects are updated to store the Y value where each individual input lives. To store this, we will create a helper called setInputPosition that will add a yCoordinate key onto each of our inputs.

function setInputPosition({ ids, value }) {
  const { inputs } = this.state;

  const updatedInputs = {
    ...inputs
  };

  ids.forEach(id => {
    updatedInputs[id].yCoordinate = value;
  });

  this.setState({
    inputs: updatedInputs
  });
}

This helper will take an array of ids that sync up with the input objects living in our local state. The advantage of using an array here is that we could potentially have multiple inputs existing on the same row (like we've done already in our demo app with birthday month and year). Since both of these inputs will be sharing the same yCoordinate value, we can call this helper method one time and update both.

Now that we have our helper created, bind it to the constructor like many of the previous helper methods - since it will be interacting with our state.

To use it, we'll need to tap into the onLayout method that is exposed on many React Native components. The onLayout method will be invoked on mount and after any layout changes and receive an object that contains details about that elements position in relation to its parent View (more on that later).

So, let's test out calling this method on our form's first input - first_name.

onLayout={({ nativeEvent }) => {
    this.setInputPosition({
        ids: ["first_name"],
        value: nativeEvent.layout.y
    });
}}

Now, when the form is loaded, we can take a look at the local state in our debugger and we should see this:

inputs: {
    first_name: {
        type: 'generic',
        value: '',
        yCoordinate: 17
    }
}

Our yCoordinate was successfully saved to our state and our form is now aware of the exact position of our input within the ScrollView.

Next, we'll add the helper method onto the last_name input and our birthday_month / birthday_day inputs. For the birthday inputs though, we'll add the helper only once on the outer View that contains both of these elements and include both keys in the ids array. At this point, our form demo app looks like this.

If we reload the page and check our debugger again, we'll see our local state:

inputs: {
    first_name: {
        type: 'generic',
        value: '',
        yCoordinate: 17
    },
    last_name: {
        type: 'generic',
        value: '',
        yCoordinate: 17
    },
    birthday_day: {
        type: 'day',
        value: '',
        yCoordinate: 142
    },
    birthday_month: {
        type: 'month',
        value: '',
        yCoordinate: 142
    }
}

Wait, something looks off here... our birthday month and days should have the same values, but why do our first and last names share the same value? Shouldn't our last_name input have a higher yCoordinate value since it's lower on the screen?

If you take a look at line 75 in our demo app, you'll see the following:

<View style={styles.container}>
  <ScrollView>

    // first_name inputs are here

    <View> // <--- LINE 75 HERE
      <Text>Last Name</Text>
      <TextInput
        style={styles.input}
        onChangeText={value => {
          this.onInputChange({ id: "last_name", value });
        }}
        onLayout={({ nativeEvent }) => {
          this.setInputPosition({
            ids: ["last_name"],
            value: nativeEvent.layout.y
          });
        }}
      />
      {this.renderError("last_name")}
    </View>

    // birthday_month and birthday_year inputs are here

  </ScrollView>
</View>

Can you spot the issue? Remember, the onLayout method returns the location of the element in relation to its parent View. So our last_name input is effectively telling us the height of the Text element here, instead of the location of this input on our screen. This also means our first_name input is making the same mistake.

How can we solve this? One of two ways. We could move the Text and TextInput out of the wrapping View so every element is a direct descendant of our parent ScrollView. Or, we can move our onLayout logic into the wrapping View. Let's do the latter.

Now, when we reload and check our local state we should have a yCoordinate of 0 for first_name and 71 for last_name. That sounds more accurate.

Determining the first invalid element

All of our form elements currently fit on the screen, so let's add some additional input and spacing so our form actually scrolls a bit.

Feel free to get creative here and practice what we've worked on up to this point - including testing out new types of validation. If you want to skip ahead, you can copy the updates I made here and here.

Our form, in its current form.

At this point, we have a long form that's aware of each input's position, properly validates all inputs, and marks the invalid ones for our users to fix. Now we need to determine which invalid element is the first one - meaning the input that is both invalid and has the lowest yCoordinate value.

To determine this, let's write one more helper.

function getFirstInvalidInput({ inputs }) {
  let firstInvalidCoordinate = Infinity;

  for (const [key, input] of Object.entries(inputs)) {
    if (input.errorLabel && input.yCoordinate < firstInvalidCoordinate) {
      firstInvalidCoordinate = input.yCoordinate;
    }
  }

  if (firstInvalidCoordinate === Infinity) {
    firstInvalidCoordinate = null;
  }

  return firstInvalidCoordinate;
}

This method will take our entire input state after we've run it through our validation service and iterate through each invalid input, continually replacing the firstInvalidCoordinate value with a lower value if one is found.

We'll also want to update our getFormValidation method to return the result of this helper by adding the following as the last line:

return getFirstInvalidInput({ inputs: updatedInputs });

Now in our submit method in our form, if we console.log out the result of calling this.getFormValidation() we should see the lowest yCoordinate value - representing the first invalid element on the screen.

Scrolling to the first invalid input

All this work so far has been to prepare us for the real purpose of this tutorial, actually automatically scrolling our user's device to the first invalid element. This way, they know what they need to correct, and will be able to see any other invalid inputs as they scroll back down the screen.

To interact with our ScrollView programmatically - we'll need to create a reference to the element on our constructor and attach it via the ref attribute. More details on that can be found here.

class MyComponent extends React.Component {
  constructor(props) {
    super(props);
    this.scrollView = React.createRef();
  }
  render() {
    return <ScrollView ref={this.scrollView} />;
  }
}

Now that we have a reference to it, we can call the scrollTo method if our form is invalid with the exact coordinates we want to scroll to. We can also utilize the animated flag to make our scrolling look professional.

submit() {
const firstInvalidCoordinate = this.getFormValidation();

    if (firstInvalidCoordinate !== null) {
        this.scrollView.current.scrollTo({
            x: 0,
            y: firstInvalidCoordinate,
            animated: true
        });

        return;
    }

    // if we make it to this point, we can actually submit the form
}

Alright, let's see how it looks with everything hooked up:

Awesome! Our form has validation and is automatically scrolling to the first invalid input.

Check out our demo app at its current state if something isn't quite working right on your end.

Next steps

In the third and final part of this series, we'll go over some ways we can improve the validation experience for our users, attempt an alternate method at obtaining the our input's coordinates, and share some insights we've learned from our experiences building out forms in React Native.

How to create custom forms with validation and scroll to invalid logic in React Native (Part one: Validation)

Michael Lefkowitz — Tue, 07 May 2019 14:50:58 +0000

Want to stay up-to-date? Check out React Native Now, the bi-weekly React Native newsletter

When we started our first rewrite into React Native in late 2017, we knew our app was going to have quite a few forms that our providers would need to fill out - especially when first onboarding onto our platform.

On the web, we were pretty familiar with a variety of the web APIs and libraries out there that offer form validation and an ability to scroll to the first invalid input-something that we insisted on having due to the existence of a few long forms - but with React Native there wasn't much available at the time, which is how we ended up rolling our own.

Over these next few posts, we'll go over how we built our logic, some of the caveats to be aware of in this approach, and finally some of the improvements that can be made upon it.

If you want to jump ahead and see the demo app that this tutorial created, you can do so here.

Validation

The first step will be creating a service so we can validate our inputs against a defined dictionary of validation logic. For this, we first need to install Validate.js as a helper library. The nice thing about this library is that it's a pure Javascript solution, so there's no need to worry about any framework-specific constraints - so if you eventually want to port your validation over to the web or a different mobile framework, you can.

The first step in setting up Validate.js is to create a dictionary of all the different unique types of input fields you'll have and the validation rules for each. Reading though the documentation on this will definitely help - but here's an example of some of our rules to give you some context:

export const validationDictionary = {
  bool: {
    presence: {
      allowEmpty: false,
      message: "^This is required"
    }
  },

  day: {
    presence: {
      allowEmpty: false,
      message: "^This is required"
    },
    numericality: {
      greaterThan: 0,
      lessThanOrEqualTo: 31,
      message: "^Must be valid"
    }
  },

  email: {
    presence: {
      allowEmpty: false,
      message: "^This is required"
    },
    email: {
      message: "^Email address must be valid"
    }
  },
};

Now that we have our dictionary setup, let's look at what the local state on one of our forms will look like.

this.state = {
  inputs: {
    first_name: {
      type: "generic",
      value: ""
    },
    last_name: {
      type: "generic",
      value: ""
    },
    birthday_month: {
      type: "month",
      value: ""
    },
    birthday_day: {
      type: "day",
      value: ""
    }
  }
};

As you can see, we've nested all of our inputs within an inputs object on our state to keep it organized. Then, each individual input has its own object with two key pieces nested within it. First is the type, which is a string representation linked to the type of validation we want to perform on the input. Next is the value, which is where the input's value will be stored. Also note that the key of each input is uniquely tied to the input in reference.

Next, let's create some helper methods that we'll utilize to validate our inputs. For ease of explaining how these helper methods will work - imagine we're validating an input defined as day which permits integers from 1 to 31 and the user has just typed 32 into the input.

function validateInput({ type, value }) {
  const result = validatejs(
    {
      [type]: value
    },
    {
      [type]: validationDictionary[type]
    }
  );

  if (result) {
    return result[type][0];
  }

  return null;
}

First, we'll setup the main helper that's going to be validating our input called validateInput. This method will take two parameters, type ('day') and value (32). Within this method, we immediately call Validate.js with two parameters - the first is an object of our type and value, and the second is an object of the validation we want to check against from our dictionary (make sure your validationDictionary exists for this helper to reference). If that call produces a result - which in this case it would because our dictionary enforces numbers between 1 and 31, the error of "Must be valid" will be returned.

function getInputValidationState({ input, value }) {
  return {
    ...input,
    value,
    errorLabel: input.optional
      ? null
      : validateInput({ type: input.type, value })
  };
}

Next, we'll create a helper method called getInputValidationState. This method will be updating the state.inputs.day object by first spreading out all of the existing parameters, and then explicitly updating the errorLabel parameter (as long as the input hasn't been flagged as optional) by calling the validateInput method we just created.

function onInputChange({ id, value, cb = () => {} }) {
  const { inputs } = this.state;
  this.setState(
    {
      inputs: {
        ...inputs,
        [id]: getInputValidationState({
          input: inputs[id],
          value
        })
      }
    },
    cb
  );
}

Finally, we need a helper method that we'll link directly into the change event on our input (i.e the onChangeText prop on a TextInput). This method will not only update state.inputs.day.value, but also actually perform the validation and return all information in regards to it. To do this, we'll create an onInputChange helper that will take three parameters. First, an id that is a string representation of the input's unique key - day in this instance. Next, the value (32) of the input. And finally, an optional callback method. We will need to bind this method to our constructor so it has access to state, which will allow us to pull the entire object for that specific input off.

this.onInputChange = validationService.onInputChange.bind(this);

Now that we've got our helpers setup, let's go back to the setup of our form. The beauty of the service we just created is that it can validate any structure of data as long as your dictionary is setup to parse it (again, refer to the documentation for more assistance with complex rules). But for the sake of simplicity, I'll validate a few TextInput components using our onInputChange method.

  renderError(id) {
    const { inputs } = this.state;
    if (inputs[id].errorLabel) {
      return <Text style={styles.error}>{inputs[id].errorLabel}</Text>;
    }
    return null;
  }

  render() {
    return (
      <View style={styles.container}>
        <ScrollView>
          <View>
            <Text>First Name</Text>
            <TextInput
              style={styles.input}
              onChangeText={value => {
                this.onInputChange({ id: "first_name", value });
              }}
            />
            {this.renderError("first_name")}
          </View>

Here's a snippet of what our form looks like when it's all set up. Essentially, we've got four inputs that all have validation checks, and a helpful renderError method that looks to see if the errorLabel key on any of our individual inputs is truthy. If it is, we render the error.

Great, now that we have individual inputs validating -but what about if we wanted to validate the entire form all at once? Let's create a new helper method called getFormValidation to do that.

function getFormValidation() {
  const { inputs } = this.state;

  const updatedInputs = {};

  for (const [key, input] of Object.entries(inputs)) {
    updatedInputs[key] = getInputValidationState({
      input,
      value: input.value
    });
  }

  this.setState({
    inputs: updatedInputs
  });
}

For this helper method, we're going to iterate over the entire inputs object and run a validation check on each input. As we run this validation, we rebuild the inputs object and then set it to state. Make sure you bind this one to the constructor too, then throw a button on your form and test calling this method.

Now our form is setup with our base validation logic.

Next Steps

That's all for this first part. In part two, we'll go over setting up "scroll to invalid" logic so we can ensure that if we have a long form and our user forgets to enter in a field on the top input - we bring them right to that point on the form.

React Native, one year later: what we've learned

Michael Lefkowitz — Sat, 16 Feb 2019 15:06:35 +0000

Want to stay up-to-date? Check out React Native Now, the bi-weekly React Native newsletter

In late 2017, we began the ambitious task of rewriting one or our mobile apps from the ground up from Ionic 1/AngularJS to React Native. Six weeks later, we shipped it to the app stores. A few months after that, we started that process again and after another busy six weeks, shipped our other app out the door.

Reflecting back over the past year and some, here are some of the main takeaways we've learned:

Plan out your navigation in advance

If your app has fairly straightforward navigation - you may not need to worry about this, but our apps have many flows that allow our customers and providers to self-service through any issues that may arrive, along with plenty of ways to access those flows. This has resulted in a web of nested stacks within nested stacks within our parent tabs that all need to be aware of one another so we can navigate appropriately and ensure we've reset stacks we're exiting. For the most part, we're happy with how these have turned out - but had we given more time in the planning stages to map out our user flows and screens, we certainly could have reduced the number of navigation helpers we had to write.

When we started on our first app, react-navigation was still pre-v1 and the jury was still out on whether it would take the crown as best of breed solution compared to the native offerings. Overall, we've had a positive experience with it - and it has only improved since then.

The jumping off point for our web of navigation

The community is still young

Prior to our move into React Native, we started creating any new web apps in Vue and have been very happy with the experience thus far. So, when we got stuck during our rewrites, we were fairly familiar with the sense of finding or creating solutions to our own problems - as a Google search on either platform doesn't present the wealth of results as some other technologies may. With that in mind, we've had some fun open sourcing some of the work we've done and will continue to do so.

One of the projects in our backlog is to create our own text input mask - as we haven't had a ton of luck with the current offerings. One suffers from a lack of updates and is often broken by React Native major releases, while the other lacks in our needs for flexibility. We've had good success using Cleave.js on the web, and are planning to model our own library after it as best we can - unless something better comes along before we get to it.

Stay one version behind on upgrades

We typically try to time our upgrades to be on the final minor release of the previous major release (i.e. upgrading to 0.57.8 once 0.58.0 was released). This has allowed us to benefit from a ton of bugfixes and improvements, without being first to the gate in dealing with unexpected breaking changes.

Our typical upgrade workflow has been very successful and it looks like this:

Ensure our sandbox branch is up-to-date with master
On sandbox, update React Native, core files, and any related dependencies using a guide to follow along with any changes
Take this opportunity to update all other dependencies
Do a quick run through on iOS and Android to see if anything looks wonky (super easy to do thanks to our deployment process via App Center which pushes our builds to BrowserStack)
Merge sandbox into our master branch and run through our regression checklist
Once everything checks out, release the upgrade with no other changes to the app stores (100% on Google Play and phased on the App Store)
Monitor the release with Sentry

Try to use native elements, but don't mandate it

When we first rewrote our apps, we tried to use as many platform-specific native elements as we could. Our opinion was that users were comfortable with their platforms already, so the more native UI components we could present to them - the easier it would be for them to interact with our app. Also, and not to undersell this point, it certainly sped up our development time when we didn't have to think about deviating from that experience.

While we would still agree to those points on some level, we've now learned that there are plenty of valid reasons to deviate from that plan. This is especially true when you can replace native UI components with better ones.

Take iOS's UIDatePicker for instance.

Nowhere outside of iOS do you interact with a calendar like this

It has been an objectively horrible user experience in iOS for over ten years now, with no sign of changing soon. When we first launched our app, when a user needed to enter a date, we had a modal pop up with DatePickerIOS inside of it. If they scrolled to a date that wasn't permitted, they wouldn't know until the modal closed and they saw a validation message underneath the input. This was a poor experience.

On Android though, the default calendar looks like an actual calendar. We eventually realized that all users should have this experience, so we rolled our own date picker with the help of react-native-calendars and the results have been fantastic.

Much better

As a result, we're now much more flexible when designing UI elements as the benefits of designing for better brand consistency and user experience have far outweighed unwritten rules where all iOS apps must all look like iOS apps and vice-versa.

It makes hiring fantastic

We were recently able to double the size of our team with some extremely talented junior engineers thanks in part to our commitment to React Native. While there have been some bumps on the road, we've pushed the platform further than we'd originally expected to when we first rewrote these apps - including the use of animations, hardware sensors, and native modules - and still haven't hit a challenge that couldn't be solved without native mobile developers. This has enabled us to focus our hiring efforts on front end developers who we can ramp up quickly on the quirks between React and its mobile counterpart - but are also able to help us build out our web offerings.

It's been a great ride so far and we're excited to see what 2019 brings for the React Native community!

Handle React Native crashes with the componentDidCatch error boundary

Michael Lefkowitz — Mon, 03 Sep 2018 14:08:20 +0000

Want to stay up-to-date? Check out React Native Now, the bi-weekly React Native newsletter

React 16 allows you to catch JavaScript errors inside of your components, which is great if you're aware of a particular component that is prone to break for one reason or another. As an added measure of protection, you can also utilize error boundaries in our top level parent with a componentDidCatch so that your users can have a better experience if an unexpected error occurs in any of the children/screens.

In the below example, I utilize a native alert combined with the react-native-restart package to provide users with an easy way to reboot the app and recover from a crash.

componentDidCatch(error, info) {
    // to prevent this alert blocking your view of a red screen while developing
    if (__DEV__) {
        return;
    }

    // to prevent multiple alerts shown to your users
    if (this.errorShown) {
        return;
    }

    this.errorShown = true;

    Alert.alert(
        null,
        'An unexpected error has occurred. Please restart to continue.',
        [
            {
                text: buttonText,
                onPress: RNRestart.Restart,
            },
        ],
        { cancelable: false }
    );
}