So, our button here looks great. If you click it, it opens a modal and you can create records, just like we've built out. However, if I log out and then navigate back to the Blog page, then you'll see that our button is still here and this is gonna cause all kinds of issues.

One, it's your site, so you don't want other people writing blog posts on it and then two, the system itself would actually throw an error because it wouldn't recognize the user and so it wouldn't let the records to be created anyway, so this little button here would just be confusing.

So what we're gonna do in this guide is we are going to tap into our state's logged in status, the state for the entire application, the parent component and we're gonna see how we can pass that state down using render props directly into the blog component.

Now, we've done certain parts of this already but we're going to extend the functionality. So far we've only done it to a few other components which I'll open up Visual Studio Code. Now if you go to the app component, you can see that inside of our auth route here, we passed in a render prop and so, you do have the ability to do this but we haven't really extended it to sending state.

So far we have just sent our functional type props but now we're actually gonna send a piece of state into our blog and we're gonna use the same pattern in order to do it. So, let's get started on that now. I'm going to give ourselves a little bit of room here and as you can see, we have our normal path and then we have a call to the component, just like all of our other route definitions.

I'm gonna get rid of our component call and we're gonna mimic the syntax that we have up here at the render prop, so let's get rid of that and give ourselves a couple of lines to work with. So, the render prop is just like a normal prop, you just pass in render name equals and then curly brackets.

The very first argument is going to be props and then from there, we pass in a functional component. Now, one little tricky piece of syntax here is that if you notice, our arrow function up here, it does not use curly brackets, it uses parentheses and I wanna take a little bit of a backward step and talk about that because this is a concept that I've seen confused quite a few developers, even experienced developers with JavaScript and so, I think it is worth our time to show the difference between what we have here and what we have here and just as a note.

What I have here on line 126 with our props, this is not correct, this would not work and I wanna show you why.

render={props => {

}}

Let me open up Google Chrome and I'm gonna open up the JavaScript console and it all has to deal with the difference between explicit and implicit returns. So, if I were to just create a few demo functions here with the fat arrow syntax, I could say const a equals, just a regular fat arrow function and then I'm gonna use the curly brackets and I'll say return 'a', it doesn't really matter 'cause it's just showing that we're returning something.

So, now if I call this function, you can see it returns a, that's what gets printed out.

Well, watch what happens if I say const b equals and then using the same fat arrow syntax and curly brackets, now if I don't say return and I just say 'b', and end our curly brackets, if I call the b function, notice how it doesn't return anything.

That is because with the way the fat arrow syntax works is if you use curly brackets, you need to state what you're returning. But in a little bit of a confusing twist, the fat arrow syntax, this fat arrow function, gives you the ability to skip having to type return but only if you place it all on one line.

So, let's do const c, so I'm gonna say const c equals a fat arrow function and now I'm just going to say 'c'. Just like this, all on one line and if I run this and then run c, the c function, you can see it returns c even though we didn't state return.

So, what's going on and why am I talking about this? Well, because this can lead to a very confusing bug because if you were just running through the code really quick and so far if you're writing a lot of JavaScript, especially with the fat arrow functions, you probably are used to writing your functions with this curly bracket syntax, that is the normal way to do it.

However, with JSX code, what would happen right here is nothing would get returned, so a render prop works the same way the render function works. If you go back to any of your class functions, if you scroll down and look at your render function, you can see you have render which is just a normal function definition and then inside of it, you have this return statement.

Well, without this return statement, nothing gets returned. However, if you use your parens and not curly brackets, you get to take advantage of what we just walked through. You get to take advantage of this third syntax like we used with this C function where you don't need to state return.

Now, one thing that is a little confusing if you're doing this in the console is if I created a function called const d and then tried to call it like we're doing with our JSX code where I try to put it on one line and I say d, you'll get a syntax error.

Don't worry about that, that's just a console-related issue. JSX does allow you to split up each one of those statements when you use parens. It knows that anything inside of here, it's all gonna get compiled down under one line anyway, so that's something with JSX just to make the code more readable and that allows that.

So, that is what we're doing and if you're curious about why I'm spending so much time talking about this, it's because I personally have run into this bug before. I have written code like this because I am a creature of habit and I'm so used to writing a fat arrow followed by the curly brackets and then nothing works and I get these really weird errors talking about render not returning anything and it can be confusing.

So, just make sure whenever you're using a render prop, and you're using the fat arrow syntax like this that you are using parens and not curly brackets. So, with all of that in mind and now you hopefully will remember that for the rest of your development career now that we can actually build out what we're looking to do.

So following the same pattern as with our auth component, we now can call our Blog component, so I'm gonna say Blog and I'm calling it just like a normal component call. I'm going to pass in the props, so what this does is it makes it possible for our Blog component to get all of the other props. We're not overwriting all of the props that are being sent to it, we're simply adding on our own custom ones like what I'm doing right now.

We want to pass in loggedInStatus and so, I'm gonna say loggedInStatus equals this.state.loggedInStatus. Okay, so now at the very end of this, just like a normal component, make sure that you close that off, hit Save, and now let's go take a look at what we have access to in our Blog component.

So, now inside of here, what our goal is is that this link right would not show up if a user is not logged in, so we can use the turnery operator, so I can say this.props.loggedInStatus and I can say if the props of loggedInStatus is equal to, let's see, yes, we want LOGGED_In, that's what we called it.

If that is the case, then I want to throw in all of this code right here. If not, then I just want to return null and that's all we need to do.

blog.js

{this.props.loggedInStatus === "LOGGED_IN" ? (
  <div className="new-blog-link">
    <a onClick={this.handleNewBlogClick}>
      <FontAwesomeIcon icon="plus-circle" />
    </a>
  </div>
) : null}

So, let's test this out and see if it's working. I'm gonna go to Google Chrome, open it up and there you go, our little button is gone.

You can hit Refresh just to make sure and then let's come to, let's actually go to the auth route now and let's log in and then we can navigate to our blog page here and you can see you now have access to that.

So, our authorization rule is working, you can hit Refresh, come to it like you're coming to it from scratch and you have the ability to make this a new blog assuming that you are logged in.

So, great job if you went through that. In the next guide, we're gonna clean up our app component a little bit, there a few refactors that I think it'd be good for us to do and so that's what we're gonna start in the next guide.

Resources

• Source code