Creating a React — Firebase Context with Social media authentications.

Part 4

So, thanks for coming this far in my series about Firebase Authentication, if you want to recap what we’ve seen so far………

Part 1: https://adaonatalino.medium.com/creating-a-react-firebase-context-with-social-media-authentications-4e4101f6dcdb

Part 2: https://adaonatalino.medium.com/creating-a-react-firebase-context-with-social-media-authentications-e08c4abce350?source=your_stories_page-------------------------------------

Part 3: https://adaonatalino.medium.com/creating-a-react-firebase-context-with-social-media-authentications-96784f1110c2

The last thing we did was finishing the Context for the user, with all the functionalities we will need to finish this tutorial.

Now, let’s use these functionalities!

Bonus: how to create a private route in React.

Have you ever made a conditional render and Route based on whether the user was logged in or not? I’ve done it a couple of times, just checking if I had an user logged in a ternary operator to render the component and that works but, what if we had a component that checks for it itself, without any helper function or conditional render outside of it?

Well, React doesn’t have it built in (yeah, React doesn’t even have Routes and Links built in). But not even React-Router-Dom has it, but it’s fairly easy to implement.

As you can see, this is my App:

So I have the Router, the Context, the Switch and the Container (Bootstrap) wrapping everything inside, but inside of a div, we have a <PrivateRoute /> component, that takes a component property, along with all the other props and we pass a component that is private inside of it.

Easy right? But how does the component know if we need to render the Dashboard or not?

Let’s check it out:

The component is a simple functional component, that takes its properties, we know that one of them is component (that is the Dashboard), we are destructuring this props and giving it a Component name, we also get all the other props as rest (…rest) using the spread operator.

Next, we check for the current user inside of the component itself, and render the Dashboard if we have one, otherwise, we redirect the user to the login page.

Easy and clean, isn’t it? The good thing is, this is completely reusable, we just need to pass the component that is private as a prop, and use the PrivateRoute to check for the user.

So now we know about the private route, let’s go to Sign up:

The SignUp component is basically a controlled form. I used state to control the variables, but it’s completely fine to use ref as well. There’s no performance difference, just a conceptual one.

If you use state, what is controlled is the variable the useState will return and the variable is related to the input field. If we use refs, the DOM node will be controlled referencing to what the useRef function returns.

Again, the styled components are coming from Bootstrap.

The handleSubmit:

Basically, all we need to do is use that function we created (in the Context) from Firebase, await for its response and in a try — catch block (yes, we could use Promises as well).

The flow is:

signUp lives in the Context, it will get the response and change the user because of the onAuthStateChanged function, save the token and the current user.

And that’s it!

As you can imagine at this point, the Login component is basically the same, but instead of signUp function, we use the login:

And the handleSubmit function:

We are ready!

Next week will be the last instalment of this series and we will wrap everything up with the Social Authentication feature.

Hope you enjoy it and see you next week!

--

--