In WordPress themes – there is the “The Loop“, where it’s a “catch all” for all of the post content at a given query. This may be a page, a post or a series of posts. It all goes to “The Loop“, where inside that loop – are methods that make retrieving post data easy. Inside the loop, we can do something like “get_the_ID()” or “the_title()” – which will output the post id or its title.

We’re trying to achieve the same thing in Barebones. We have “TheLoop” component – which we’ll be adding in our “partials” directory. This component will be used everywhere – in single posts, pages or archive pages such as search etc.

Previously, we were just outputting the slug in TheLoop. The modified version is shown below.

import React from 'react';
import WithConsumer from '../context/WithConsumer';
import ThePost from './ThePost';
const TheLoop = ({ context }) => {
    const posts = () => context.posts;
    const pos = posts();
    let results = '';
    if(context.appError){
      results = <div className="app-error">{context.appError}</div>;
    }else{
      if(pos.length === 0){
        results = <div className="no-results">no results</div>;
      }else{
        results = pos.map(function(item,i){
             return <ThePost key={i} index={i}></ThePost>
           })
      }
    }
    return (results);
};
export default WithConsumer(TheLoop);

There’s really not a lot going on. We are simply isolating the “loop” logic in this component. So we don’t have to do the same elsewhere. But the key points to see is we’re getting the results from our Context. And depending on the count of the result, if there’s more than 0, we – return the “ThePost” component (more on this later).

If there’s no results – we simply return a div with the text “no results”.

If there’s an error – return the error message.

ThePost

ThePost component has all of the methods necessary to output the post data. This resembles WP’s “the_post()” in PHP. In here, we have access to the context.posts, filtered by the index. The index is a prop that we pass coming from TheLoop. So now, each item is a post:

const ThePost = ({index,context}) => {
    const posts = () => context.posts;
    const item = posts()[index];
    let linkPrefix = item.type === 'page' ? '/page/' : '/post/';
    let theContent = '';
    switch(context.route){
        case '/': //if homepage,
        case '/search/:term': //or if search
        case '/category/:catid': //or if search
            theContent = item.excerpt.rendered; //show excerpt only
        break;
        default: //for single, pages - show entire content
            theContent = item.content.rendered;
        break;
    }
    return (
        <div id={'post-id-'+item.id} className={'post-item'}>
            <h1><Link to={linkPrefix+item.slug}>{item.title.rendered}</Link></h1>
            <PostMeta index={index}></PostMeta>
            <div className="post-content" dangerouslySetInnerHTML={{__html:theContent}}></div>
        </div>);
};

We have to determine if its a “post” or a “page” (line 6). This will match with the post/page route in our index.js.

Then we have a switch statement, that checks the route. If its an archive page (like search, category) – let’s output only the content excerpt. Otherwise – if its a single, let’s output the entire thing.

The PostMeta component is also a new component that we haven’t built yet. Let’s add that in a little bit. For now, let’s grab the data.

Context.js

Now there are a few things we need to do to our Context component for the loop to work. Remember in our loop, we’ve setup up the links using “Link to”. We need to map these links to right REST url endpoint – so we can get the right data and put it in the right data store.

Remember, all of the data is inside this one file. May it be posts, comments – even methods that manipulate this data is in this component. So this file is extremely important.

Let’s start by adding the containers for our state. In the constructor, add the following:

constructor(props) {
    super(props);
    let restType = this.getRestType(props.router.match.path);
    let route = props.router.match.path;
    let slug = props.router.match.params.slug ? props.router.match.params.slug : '';
    this.state = {
      slug : slug,
      restType : restType,
      route : route,
      posts : []
    };
  }

Our state now has the necessary containers for the data we need. Primarily the “posts” array is what we aim to fill. Let’s add some actions in our lifecycle hook: componentDidMount:

componentDidMount(){
    this.getPosts(this.buildUrl());
}

Let’s build a couple of functions – one to build the REST url endpoint, and the other to fetch the posts:

buildUrl(){
    let url = '/wp-json/wp/v2/';
    switch(this.state.restType){
      case 'page':
        url += 'pages/?slug=' + this.state.slug
      break;
      case 'post':
      default:
        url += 'posts/?slug=' + this.state.slug ;
        break;
    }
    return url;
  }
 getPosts (url){
    let self = this;
    Axios.get(url).then((response)=>{
      self.setState({
        posts : response.data
    }).catch(function(error){
      console.log(error);
      self.appError = 'An unexpected error occurred';
    });
  }

That should set our post and page endpoints, bringing back data from the API. Make sure that TheLoop is in your Archive and Single components.

And if all is good, we should have something like below:

Remember that we have to change our permalinks in WordPress to match our route.

Add Paging

Paging is necessary especially for archive pages. You only want to see the latest X number of posts, then show the next X – and so on.

In Archive.js – simply add the pager component (that we still have to build), right underneath the loop:

 <TheLoop></TheLoop>
 <Pager></Pager>

Now let’s create a file in our partials folder – call it Pager.js.

import React, { useEffect } from 'react';
import WithConsumer from '../context/WithConsumer';
const Pager = function ({context}){
    let prevBtn =  React.createRef();
    let nextBtn =  React.createRef();
    let curPage = () => context.currentPage;
    let totalPages = () => context.totalPages;
    useEffect(() => {
        prevBtn.current.disabled = true;
        // eslint-disable-next-line react-hooks/exhaustive-deps
    },[]);
    function nextClicked(){
        context.nextClicked();
        if(parseInt(totalPages()) === parseInt(curPage() + 1) ){
            nextBtn.current.disabled = true;
        }
        prevBtn.current.disabled = false;
    }
    function previousClicked(){
        context.previousClicked();
        if(parseInt(curPage()-1) === 1 ){
            prevBtn.current.disabled = true;
        }
        nextBtn.current.disabled = false;
    }
    function pagerClass(){
        let cls = 'Pager';
        if(parseInt(totalPages()) <=1 ||
            context.appError){
            cls = 'Pager hidden';
        }
        return cls;
    }
    return (
        <div className={pagerClass()}>
        <button ref={prevBtn} onClick={previousClicked}>Previous</button>
        <button ref={nextBtn} onClick={nextClicked}>Next</button>
        <div className="PagerText">Page
            <span dangerouslySetInnerHTML={{__html: curPage()}}></span> of
            <span dangerouslySetInnerHTML={{__html: totalPages()}}></span></div>
        </div>
    )
}
export default WithConsumer(Pager);

Now the pager logic is a little more involved. Above simply outputs our “Next” and “Previous” buttons – depending on the number of pages. Fortunately, WordPress’s API makes this easy for us. We have 2 important header properties from each response called ” X-WP-Total” and ” X-WP-TotalPages”. From this we can determine the logic needed for our paging.

Going back to context, we need to modify our state, add some methods that modify that state, as well as modify our rest calls.

//ADD THIS TO this.state IN THE CONSTRUCTOR
currentPage : 1,
totalPages : 0,
nextClicked : this.nextClicked.bind(this),
previousClicked : this.previousClicked.bind(this), 

Above shows our new state. Note that currentPage always starts at 1. Totalpages – we update on every call, then we bind 2 methods to “this”.

Next, let’s add modify our buildUrl() method to have the page parameters from our state.

 case 'post':
      default:
        url += this.state.slug ? 'posts/?slug=' + this.state.slug : 'posts/?page=' + this.state.currentPage;
        break;    

Above simply appends the current page to the url endpoint. In our getPosts() method, we update our totalPages in state with each response:

Axios.get(url).then((response)=>{
      self.setState({
        posts : response.data,
        totalPages : response.headers['x-wp-totalpages']
      }

Now all we need to do is create two functions – which correspond to which button was clicked:

  nextClicked (){
    let newPage = this.state.currentPage + 1;
    this.setState({
      currentPage : newPage
    },function(){
      this.getPosts(this.buildUrl());
    })
  }
  previousClicked (){
    let newPage = this.state.currentPage - 1;
    this.setState({
      currentPage : newPage
    },function(){
      this.getPosts(this.buildUrl());
    })
  }

Both of these methods are called from our Pager component – which we access by doing context.XXXClicked(). Pretty neat right?

We also let the front end decide whether to show or hide the respective buttons. So if all goes well, we have something like below:

Okay that should be it for this round. A lot going on above. I suggest you download the code and run it yourself – along with following the steps. Note there are a lot of omitted code above. Only the important steps are outlined – the rest is up to you.

The post Let’s build a WordPress theme with React: Part 3 (The Loop) appeared first on Michael Soriano.

The Basic .col-xx-xx Classes

Bootstraps column classes are what makes up the individual columns of the grid. It’s main purpose is to align your components into – you guessed it, columns. They’re designed to have 3 sections:

The prefix part “col” – just organizes all the col classes together, sort of like a namespace. And if you’ve worked with other frameworks in the past, the 3rd section “12” just tells us to occupy 12 columns out of the maximum 12. Pretty basic right?
But what about the 2nd part? In our example, it’s the “lg”. This tells the browser to primarily use this for large screens only (default is 1170 pixels and above). Meaning, since we can use multiple classes on any element, we can now design for multiple sizes of the screen. Pretty powerful eh?
So how does it do that?
So if you investigate the css, and look for that particular class (.col-lg-12), you will see that it’s enclosed in a media query:

@media (min-width: 1200px) {
.col-lg-12 {
    width: 100%;
  }
}

As a matter of fact, ALL of the “lg” classes are inside this media query. So the rule only applies to a specific screen resolution. The rest of the sizes (md for 970px, sm for 768px and xs for less than 768px) contains the rules for its respective classes. Pretty forward thinking right?
Show me an example of its usefulness:
A common scenario is a two-column layout, with content on the left and sidebar on the right. With just a single class applied to both areas: red div has a class of col-lg-9 and green div has col-lg-3.
But most of the time – your sidebar’s content is not ready for a full page width in medium and small view ports. So you wish the sidebar doesn’t snap to the bottom right away right?

The solution: apply multiple .col classes into the same divs (one for each of the view port sizes). Take a look at the next example – where we apply a different column number ONLY on the extra small (.col-xs-12).

You see how the divs retained their 2 column layout all the way until the extra small view port is reached. Only then, did our sidebar snap to the bottom at full width. So you see how useful this is yet?

Classes “row” and “container”

Let’s jump out of the columns and look at the classes that wrap them. We have two important classes that do just that.
.row
Just as the word describes – a row is something that is on one horizontal layer. Similar to a “record” in a database, or a “row” in a table. In Bootstrap, if you want elements to be in one horizontal layer – use a class .row.

The dark grey divs both have a class “.row”. A row basically acts as a traditional div tag, but instead can be applied as a class. I’ve used class .row on a header or footer tag – and it works really well.
.container
Ideally, you add your HTML elements that need to be grouped together inside a class .container. The “max-width” properties for each break point (the media queries) are defined in this class. It is a very important class. One that is required to make things work the way they do.
According to Bootstrap’s docs, containers are:

Easily center a page’s contents by wrapping its contents in a .container. Containers set max-width at various media query breakpoints to match our grid system.

Containers also follow the default padding rule of 15 pixels on each side. So the contents are automatically flushed together with just the right amount of gutter space all the time.

How does Nesting work?

Nesting means adding more .col classes inside of existing .col classes. Most of the time, you would need to add a .row class first – before nesting your .col divs inside in order to see desired results.
So when do you need to nest?
All the time! If you inspect most HTML documents – it’s already a series of nested DOM elements so nesting your .col classes is already expected behavior. Although in Bootstrap, nesting will save you a lot of work calculating and deciding how wide a column has to be.

See both green divs have that have .col-lg-6 classes? These are nested inside the red div (the parent div). Also, notice that a nested .col-lg-6 class takes up 50% of the parent div’s width. In other words, all you really need to remember is the 12 grid rule – no matter how deep the nesting goes.
Note that I also applied the multiple classes technique (discussed above) to the child classes shown in the screenshot above. This is so that when resized, both div’s retain it’s 6 column width – until the last view port kicks in.

Pushing, Pulling and Offsetting

For even deeper customization of the grid elements, Bootstrap allows you to shift the columns around. Push and pull classes allow you to move the column # times to the left (also know as pull), or # times to the right (push).

So consider the markup below. Even though the green div is written right above the red div, the push and pull classes allows us to order them as if they were otherwise.

green pushed 4
red pulled 4

The code above makes it so the divs appear in the browser in a different order.

What makes it work?
If you inspect the push and pull classes, it utilizes the right and left property respectively – in percents. Since everything in Bootstrap is positioned relatively, using left and right will automatically just work.

@media (min-width: 992px)
   .col-md-pull-4 {
      right: 33.33333333333333%;
   }
   .col-md-push-4 {
      left: 33.33333333333333%;
   }
}

Offsets
Offsetting classes is similar to push and pull classes – except for the “offset” keyword in the class name. Also similar to push and pull, the number in the class tells the browser how many columns to offset the element.

The difference with offsetting is that it uses the margin left property. So if your element is right next to another element – it will simply push itself against it by the designated percentage. See the code below for a .col-md-offset-4 class:

@media (min-width: 992px)
 .col-md-offset-4 {
    margin-left: 33.33333333333333%;
 }

You see how this can be useful? You can simply apply this class to whichever you want to offset and still retain the responsive margins effectively. Pretty good right?

Visibility Classes

Although this has nothing to do with the grid, I thought it is worth a mention. We’ve all worked with a system that has a default class for a “display:none”. Well not only does Bootstrap have this (it’s called .hidden), but they’ve taken it an extra step. I like to call them the “visibility” classes.
These classes do just that – controls the visibility of elements – across multiple views. Now, when designing your web site, you just now have to pick which elements to show, hide in large, medium and small views – then simply apply the visibility classes. The table below (taken from Bootstrap’s website) explains what the classes do in specific view ports.

Conclusion

I believe we’ve looked at the core classes that will get you up and running with Bootstrap’s grid system. This alone, if used properly – will save you countless hours of development time. Don’t forget to read up on the rest of Bootstrap’s many features such as the built-in components, Javascript plugins and of course, the rest of the styles. Good luck and have fun coding!
Last of all, I would like to keep this an open discussion. If there’s anything that you would like to add, please leave a comment. I will be more than happy to answer questions or append to the article.

The post Exploring the Bootstrap 3.0 Grid System appeared first on Michael Soriano.