We just finished wiring up everything on the redux side of our application or at least the initial boilerplate.
Anyways at this point we have a single reducer called the author douceur and we have said that the author
douceur is really just responsible for deciding whether or not a user is currently logged in.
So why do we really care about that though.
Well look obviously there is an obvious answer here we only want the user to be able to use our application
if they're logged in.
But really specifically thinking about our application what aspects of it are going to change when the
user is or is not logged in.
Once we understand this a little bit better once we understand what the impact of having user logged
in or logged out is I think we'll have a better time or an easier time at least deciding what next area
we need to work on inside of our application.
So let's go back to our mock up and look at some of the different aspects of this thing.
So again the very easiest The first thing that I really see to my eye that really cares about whether
or not a user is logged in is the content inside of our Hetter.
And so really you know says log in sign up right here.
Really we essentially want to show something that says like log in with Google or something like that
or sign in with Google on the head or up here.
If a user is not logged in.
Once a user does sign in with Google how ever once we know they are in fact logged in then that header
is supposed to just kind of magically change.
I no longer want to show that signing with Google button on the top right.
Instead I want to show like a log out button and a button to add money to their account which we will
talk about in great detail later on.
And these credits thing which again we'll talk about in great detail later on.
So at first glance I think its very easy very clear to say that our Hetter component is going to change
in some fashion when ever the user is logged in or lot of doubt.
There's one other area that we need to be thinking about when the user is or is not signed in.
And that is some of the different routes that the user has access to.
So here's a diagram of some of the different routes we have inside of our application.
So at the very top the index G-S file that shows the component and the app component is going to show
the header the landing the dashboard and the survey new components.
Now the heavier it is always going to be visible no matter what yes the content inside the header is
going to change slightly depending on whether or not the user is logged in.
But we can confidently say that no matter what the user should always be able to see the head or some
of the other components however are going to just change their behavior slightly depending on whether
or not the users authenticated.
So the landing screen Well you know its ok if someone wants to see our landing screen if you want to
see the landing screen inside of our application if you want to see the markings screen that's totally
fine.
We will let you see that.
However other things like say the dashboard where users sees a list of all the surveys they've created
over time or the form to create a new survey.
Those are both things that we don't really want the user to have access to unless they absolutely positively
are logged into our application.
So I think that it is safe to say that if a user is or is not logged in we want to have some logic tied
to our dashboard and survey components.
And if a user is or is not logged in we want to have some content or excuse me some logic inside of
our head or to decide what content to show inside of there.
OK.
So with this in mind I think thats absolutely the next step.
Without a doubt that were going to want to accomplish is to make sure that we can start to get some
of these different components which we have not yet created.
We still need to do to be visible on the screen once we can actually show them.
Then we can start thinking about adding in some logic to say hey you should or you shouldn't be able
to see this thing or this individual component based on whether or not you are logged in.
So long story short we want to have the ability to show different routes or different sets of components
on the screen and then add some logic to toggle whether or not a user can see them.
So just thinking about navigation in general my mind immediately goes to react router.
So I think that in the next section we should start to wire of re-act router inside of our application.
Once we set up all these different components we'll then be able to add in some further logic to decide
whether or not a user can see each individual one.
OK.
So that's the game plan.
We're going to wiretap re-act router.
We're going to get some of these different components visible on the screen.
We'll then tackle the header and some of the individual components that depend on the user's authentication
state.
So let's take care of all this in the next section.