We developed the POST request using Axios, and we're returning it with dispatch so that we can dispatch to our reducers once we receive a response. We have commented out because we first want to call it and see if we're even getting the fields in here.

Let's go ahead and hook up our signup.js to redux so we can access these actions. Let's go to signup.js up and let's say:

signup.js

import { connect } from 'react-redux';
import * as actions from '../../actions'; 

Then let's go to the bottom here and actually connect our actions. If you remember we have a mapStateToProps function that we have to include. Now we're not using it in this file. At least we aren't yet, most likely we won't be later on either. So we're just going to pass in:

signup.js

export default connect(null, actions)(Signup)

So now we have our actions on our props, so in our onSubmit, we can simply:

signup.js

onSubmit = (fields) => {
    this.props.signUp()
}

Let's go to our auth.js file takes, and we see that it takes fields and a callback. Okay. So let's go to sign up., and say:

signup.js

onSubmit = (fields) => {
    this.props.signUp(fields, () => {
        console.log('navigate to dashboard');
    })
}

Now this isn't going to run because we're not using the callback so let's just go ahead and let's just go into auth.js and say:

auth.js

export function signUp(fields, success) {
    console.log(fields);
    success()
    return function(dispatch) {

    }
}

So we should see two console.log's. We should see the fields and we should see this console log.

Let's go to our application and try it out. Let's go ahead and hit create account, and we get an error. That's a redux-thunk thing, but you'll see we get our email, password, full name, and unit, and we get the navigate to dashboard. So that's working great. Now we just need to make it actually do something. The first thing we need to do is go into bootstrap, so we don't get these errors right here.

So let's go into bootstrap.js. Let's go to up here somewhere and let's just say:

bootstrap.js

import reduxThunk from 'redux-thunk';

const createStoreWithMiddleWare = applyMiddleware(reduxThunk) 

Let's go to our application, and it should print out the same stuff except for the errors. It's working great. So now that it's all working. Let's actually make the post request to our server to attempt to create this account. So close out of bootstrap. I'm going to go into auth.js, and I'm going to uncomment our Axios call.

We're hitting the ROOT_URL which we're importing from config, which is a file we created in the source directory which contains our ROOT_URL. So localist3090/signup.

If for some reason you're running it on a different port. Just make sure that port matches whatever it is running on on your server which we pulled from my github: should say server listening on port and then the port.

Make sure your ROOT_URL in the config.js in our application here contains the correct port in almost. I'm pretty sure for every single one of you can say 3090. The only way you be different is if you changed it. Okay so let's just say:

auth.js

export function signUp(fields, success) {
    console.log(fields);
    success()
    return function(dispatch) {
        axios.post(`${ROOT_URL}/signUp`, fields)
        .then(response => {
            console.log(response);
        })
        .catch(err => {
            if(err) { console.log(err) }
        })
    }
}

Let's run this now. If you run right now, it's going to call the callback first. So, we want to move that callback and put it in here:

auth.js

export function signUp(fields, success) {
    console.log(fields);

    return function(dispatch) {
        axios.post(`${ROOT_URL}/signUp`, fields)
        .then(response => {
            console.log(response);
            success()
        })
        .catch(err => {
            if(err) { console.log(err) }
        })
    }
}

So the only way we're going to get this callback is if we get a successful response back. If we get an error it's not going to call the success and it won't go in here and say navigate to dashboard. So if you try and create an account and it doesn't work, the email is already in use or something, this ultimately won't be run, and we won't get to the dashboard.

Alright, let's go ahead and test it out. Let's reload the app just to be sure it's refreshed, and let's put in a name. I'm going to put in a unit. I already have an account in my local database with this email so I'm going to change it to max@test.com, and the password: I'm just going to put password. I'm going to hit create account, and it says that we have an error:

Now this was my bad, except for I'm kind of glad I forgot this, so I can show you how to fix this error because you're likely to get it in the future in a different project that you create on your own. So basically what's going on here, is it's performing a post request in auth.js, except for the URL isn't using http.

So let's go into our config.js, and let's change this localhost to say:

config.js

export const ROOT_URL = 'http://localhost:3090';

Now it's a link and it's going to work. Let's go to our application in the browser and let's enter in some data here. I'm going to change email again, and Password: Password. If you run that now it prints out the data like we have it doing, and it says XHR finished loading: OPTIONS "http://localhost:3090/signup".

Now we get a response back which includes some local data. Now, this is the response we're getting back. We're getting a token, and we're getting a user object. Now for the password, we're not getting back our password because a server encrypted that. So now we can basically store this user object into our application in our state.

Now, the reason we want to store this user object, is because later on we're going to want to use this ID for users that want to create requests. Let me explain. I'm going to head over the design. You'll see we have newsletter's, that's not what I mean, but in requests. It's assigned to a specific user, a specific tenant, or a specific person.

So by having a unique ID on each one of these users, we can basically say: "hey this was created by this user." and then we can do anything with that relation. Okay, that will belong to that user, and the reason that's important is because when we sign in we don't want to see everybody else's requests as a normal user.

If we sign in we don't want a standard user to see everybody else's requests. That's personal information and has nothing to do with their apartment. It could be just annoying to do that that tenant, that customer right. So we only want to display their requests.

Now the admin obviously wants to see all these, and that's where that's where this comes in. That's where the admin comes in. The admin's can be set to true, and then we're going to display all the requests, but a standard user with false to set to admin. We're only going to display the requests created by the user with this ID, their ID right.

So that should be good. We got the unit number, we got the name, and we got the email, and that's how we set up that. So let's go to our application here, and we're logging the response, we're seeing success.

We need to do a couple of things now. We need to save the user into redux, into our state, in your store. We want to be able to see it in here somewhere. We want to say state.auth.user, and then have their user data.

So we need to do that, and we'll do that by dispatching an action in here to our reducers which we will handle in the next video. We also need to navigate the user after this success to a different page.

So let's go to our signup.js and in our onSubmit, that's where we want to do it. So this is a really quick thing. So let's just throw it in right now. Let's go right here and say:

signup.js

onSubmit = (fields) => {
    this.props.signUp(fields, () => {
        console.log('navigate to dashboard');
        this.props.history.push('/dashboard');
    })
}

Now this isn't going to push us anywhere because we don't have a route in our bootstrap to dashboard, but it will at least show us in the top here. Let's enter some data here. This is going to be another new unique emai. It's not going to work, and if you actually try that again using the same email: let's put a full name in and let's try that. You're going to get on error.

]

Now this is likely going to look a little bit different by the time you are going through it. This error saying something like e-mail already taken or something, or it will say 422 unproccessable entity. Again that's an error regardless. We're getting it from the server.

Alright, so let's go ahead and create a unique e-mail and this password is passwords. Now I'm going to hit create account, and it navigates us to /dashboard, so we don't have a route. That means we don't have a component here, but we still have our header which we need to change and data in.

So this is going on pretty long, but we have it working. We have sign up working, and we have it pushing the dashboard. So in the next video let's make sure that we are saving this user data into our store. So let's go to our terminal and say git status, git add ., git commit -m "handled sign up post request", and git push origin.

Now I'm not going to be pushing up to Heroku until we're almost done with the application because now that we're actually dealing with the back end, and all that: we don't want people to be able to manage to do that.

Now, we obviously don't have it hooked up to a production database or back-end, but it's just going to give us an error if we try and handle it on heroku because it's going to try and handle local host except for it's not going to know where local host is. So just wanted to clarify that. Right so in the next video.

Resources

• Source Code