During the registration process we are asking users to provide more than just an email address and a password. We are asking for their first and last name, their company. However, to this point we are throwing that information away. It would be good to store that information somewhere.
In this post we will create a very contrived ToDo App in React leveraging AWS Amplify and AWS AppSync. This post assumes a basic understanding of AWS Amplify (link to the docs below). You can get away without knowing very much about AWS AppSync, but the end result may not mean very much to you.
In this post it is time to start leveraging our authenticated user. Upon successful login (or register) we will bring the user inside the application. We will also give them a mechanism to leave the application (logout). One of the key ways to help a user understand where they are in our application is through the menu. We will do some menu refactoring to make this easier.
In this post we will wire up our forgot password page. There is a key difference with the forgot password workflow - it does need, nor should it, have anything to do with out application state.
In this post we will continue to integrate our application with the Redux store by wiring our registration process to the store.
All the way back in post 1 (Dev setup) in this blog series I talked about types and I said I was not going to use prop-types. I've had a change or heart, when working on the previous post (State Login) I ran into an issue that would have been easily found had I been using prop-types. So, as an agile, pragmatic developer I always reserve the right to change me mind and I will be using prop-types going forward.
In the last post we added Redux to our application, we created some authentication actions and an auth reducer. In this post we will wire up Redux complete our Login workflow. We will follow a common pattern in React by using container components.
I have spent some time debating how to best handle state in a "modern" way in our application. I keep coming back to using Redux. In this post we will make the case for using Redux and wire it into our application.
Back in Part 7 we blew away our initial testing strategy and decided to move forward with react-testing-library (and jest-dom). In part 10 we wrote tests to confirm our auth library works as expected where we leveraged Jest directly as we were not testing any parts of React. In this post we will start to create tests for the React components we built in the previous post where we created the login, register and forgot password pages in our application.
In this post we will finally start bringing our application to life. We will create a handful of the pages that our application will use. I want to create (update) the user registration, login and forgot password pages. You may recall that those are all of the pages that can be accessed without logging in to our application.
A key part of what we will create in this post will leverage a library called Formik. I am a big fan of Formik, it reduces a tremendous amount of the boilerplate required by forms. Using libraries like Formik is a cornerstone to my development philosophy - don't be precious about code, if there is a good library available that will save time, use it. Formik can be integrated with another library called Yup which provides field level validation.