How to Use Bootstrap 4 to Add a Custom Nav Bar to a Blog Layout in Rails
With the application's blog layout implemented, in this guide we'll start to integrate the live data coming from the Rails system. Specifically in this lesson we'll implement the nav bar.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

Now that we have our initial blog layout live. Now we can start implementing our navigation. Right now these are all hard coded so let's start implementing our real nav. Open up Sublime Text and I closed everything out just so we could have a good start from scratch kind of approach. I'm gonna say blog dot HTML and this is going to bring up our blog layout. Right here we have everything that we need all of our components are already there. So we simply have to now go and start adjusting them so we have home we have new features all of these things we can get rid of all of them except for one. That's because we need to have this else to get rid of the act and it's because we want to be able to make sure we're using the right class and all of that kind of good stuff. So let's go down and see what partial we're calling this is just the shared nav and I'm going to create a new partial called blog underscore nav just so we can follow our same convention. So you hit save in the shared directory blog underscore nav dot html dot erb that you always making sure for our partials to underscore before and now I'm going to grab everything right here. Replace it with a partial So I'll say render shared and then blog underscore nav we don't have to pass any variables or anything like that to it. So I'm going to come right here. Delete all of that because I did not like comments and if you're ever curious why I don't like comments it's mainly because I have discovered that comments can stay in and even if you change your code you don't have to change your comments. So what I've discovered is many legacy applications I've taken over are filled with all kinds of comments and they were comments from well-meaning developers who at the time were probably writing relevant comments but now a few years later their comments are simply confusing because if you go and read them you'll see that they have nothing to do with the current state of the code and that can cause issues. So typically it's considered a better practice to name your classes and your variables and your methods in a way where they explain themselves instead of having to be commented. That's just a little side note it's I didn't want to just simply say I don't like comments and not explain why.

So now we have this let's go and let's take a look at our current nav bar and see all of these items. So right here you can see that we have all of these. Eventually, I may want to integrate some type of shared commonality among them so I'm not going to delete this now partial because eventually, we may be able to actually go back refactor the code and use the same nav. So we'll be able to pass in our classes and pass in our classes to each one of these items and that may work perfectly but right now I'm not going to worry about it though.

large

The way I like to develop is I like to first build in the functionality then come back and refactor it, that way I'm not held up trying to you know spending all my time with some little tiny feature in trying to get the code set up the right way. Instead, I'm focusing my time on actually building out the right kind of functionality. So let me come here and I'm going to select each one of these divs, delete these because we're not going to need these come all the way to the right and delete those. Now I can just select everything here paste it in. Now we're going to have everything that we need besides the class. Grab that class name. Now inside of here I can simply pass in a class so I can say comma class and pass and now blank and now everything should still work. But now they should all be live. So I hit refresh. You have about me contact blog portfolio and these are all functioning properly so that is looking fantastic. Next, we have our login link. Now this is going to be very cool because remember we have our log in helper and we customized our helper so that it could be called across all the files and we can pass in custom classes. So I'm going to call log in helper pull this out and put it inside of our blog nav right up here now I can simply pass in an argument and this one is going to be nav link and remember our log in helper is a view helper method that takes an argument of a class and it's optional. So it works fine without it. But if we want this our log in links to match all of these items we have to pass in the same class. I come back here hit refresh.

large

Now this is all working by click log out and then come back to blog. You can see it says register and log in and all of these are functional and working perfectly. So very nice work. We also will eventually implement something like this where I can call active hit refresh and you can see that cool little active class. Right now I'm not going to worry about it. We'll come back and do that across all of our layouts. But just you know that is something that we will implement but we're not going to hard code it and we're going to make it a view helper that calls and sees if it's on one of these pages and if it is it's going to make it active. So that is what we have so far our nav is working nicely. I think this is a good spot to stop so it's run git status. We created one new partial and then we added that partial to the main file to the main blog layout file

git add .
git commit -m "Implemented nav bar for blog layout"
git push origin design

So right now we still have a few issues. One is that this is all fake data so we need to tie this in so that we're actually calling real data and then we can get rid of our ugly old table and then pull all of this content and our footer and put it in the right slots on the page so that is what we'll do in the next guide.

Resources