Create an Auto Saving React Input Component
A better UX without too much heavy lifting

When dealing with long forms (think medical forms, profiles, etc), it’s a huge UX improvement to allow fields to auto save as a user fills them out.

Auto saving fields on blur sounds like a lot of extra work over a single submit button, eh?

Not to worry, we are going to build one in 10minutes using Semantic UI React component library.

If you want to skip this article entirely, here is the code sandbox:

The field will save on blur

Our Base Text Field

Okay, before we can think about auto saving, let’s just create our base Text Field component, or in other words, save hours by using the Input component by Semantic UI:

Semantic UI has a bunch of icons we can pass in by name, which will make displaying our saving / saved / error states a lot easier.

For context, here is the main application code:

Only two things noteworthy here :

We created a mock save function which is just a promise that resolves in 2 seconds with the new value Every prop except onSave is apart of the Semantic UI API for Input components, nothing custom there. We will make use of onSave later.

What Do we Need to Track?

When saving individual fields, there is more to keep track of. Here are the most important questions:

How do we do the actual saving? How do we indicate a field is saving? How do we indicate a successful / failed save?

How do we do the Actual Saving?

We probably want to save the field on blur. We can pass an async onSave function that is responsible for the details of “saving”, but our component isn’t really concerned with how data is saved, just the fact that it is saving.

While it may seem like a lot of code, everything is pretty simple:

We use useState to keep track of whether we are saving or not We maintain a reference to the last entered value so we can compare it to the current value. If they are the same, there is no need to save. To answer our “how do we indicate a field is saving?” question, Semantic UI already as a loading indicator that we can leverage. We show it when the field has either been passed a “loading” prop manually, or we are currently saving the field. The problem with auto saving fields is that user input can get overwritten after their data saves and the input field refreshes with the saved data. To avoid this, we simply disable the field when loading. This is where the magic happens. We attach an async handler to onBlur . In the handler we first check if the value has changed. If it has, we update our “saving” state to true, and attempt to save if we were passed an onSave function. Once the onSave promise resolves, we update the last saved value and reset our saving state.

How do we Indicate a Successful / Failed Save?

So we may be able to show when a field is saving or not, but it’s not enough. We want to show that a field has successfully saved (or failed to save).

So this is pretty much our full component! Here are the additions we made:

New state was introduced to keep track of when a field is saved, and when there is a save error For a better UX, we swap our icon for a green check mark when we successfully save, and a red warning when a save fails. Semantic UI gives us the flexibility to set our icon colors manually, so we change the color to correspond to the current save state. Now that we are dealing with more than field validation errors, we manually pass either our regular error prop (which is passed to our component from a parent), or our internally regulated saveError variable, if either exist. Another UX improvement is making sure we remove the success icon when a user makes a change to the input. That way they understand the current changes aren’t saved yet. When we hit an error calling onSave (which we assume throws a promise rejection if saving fails), we simply update our saveError state. You can be a lot more flexible here (like passing the actual message from the API), I kept it simple for this example.

Moral of the Story

Obviously there are a bunch of areas where this component can be improved, but as far as getting something up and running fast, this can probably be done in 10–20 minutes thanks to Semantic UI React.

You can use any other component library (Material UI, Ant, etc). The point is that using a component library will probably save you hours of development in cases like these. We were able to show icons, loading indicators, disabled & error states, and more just by passing simple props.

Message From the Author

Hey you… Yeah you. I know times are tough.

Bored? Stressed? Going nuts at home? Want to dive deeper into React stuff? Have buddies looking to learn something new about React & UI development?

I’ve got plenty of articles for you and your pals. Feel free to share and follow because… well… there isn’t much else for me to do besides check my Medium stats and binge La Casa de Papel.

A note from JavaScript In Plain English

We have launched three new publications! Show some love for our new publications by following them: AI in Plain English, UX in Plain English, Python in Plain English — thank you and keep learning!

We are also always interested in helping to promote quality content. If you have an article that you would like to submit to any of our publications, send us an email at submissions@plainenglish.io with your Medium username and we will get you added as a writer. Also let us know which publication/s you want to be added to.
['Kris Guzman']
['JavaScript', 'Web Development', 'React', 'Technology', 'Programming']