What you do, though, is iterate on that functionality and build upon the tools provided to you or the tools you have built for yourself in the past. After all, if you’re doing work around the house and need to hammer some nails into the wall, you’re not going to head into your garage to carve the wood and forge the steel to make a new hammer every single time (unless you’re our very own builder and wood magician Will Schmierer). You’ll use the same hammer to do the same job until the hammer is no longer useful or you find a new tool with which to replace it.

Why then would you not develop a site in the same way? Granted, most projects are going to require distinct sets of functionality unique to the projects themselves but there are plenty of ways you can reuse code to save time so you can truly focus on providing the best possible work with the best possible turnaround. Some of these reusable code snippets might not be necessary for every project, and that’s okay. Maybe you only need to use them a few times a year, but whenever the need arises you find yourself searching online or through your old code to find something you know you’ve written at least once before.

In this post, I’m going to share some things that have made their way into wd_s because we, as developers, find ourselves using similar functionality over and over again. Maybe you’ll find one, some, or all of these snippets useful. Whatever the outcome, I hope that I can help to trigger some thoughts on when and where you can reuse functionality in your own processes to more efficiently complete your projects.

1. Social Network Links

Social networks, despite all the good and bad they put out into the world, are almost essential to have a digital life in this day and age. As such, there is rarely a website out there without links to the various social media accounts linked to the business or person attached to the site. In a WordPress install, there are several ways you could implement links to a set of social networks.

You could create a widget to manage the URLs, but what if you have many sidebars throughout your site and don’t want to deal with the tedium of manually replicating the same widget over and over again?

You could add URL fields to the Customizer and pull the data out into a template tag, but even then you’re limited by a finite number of fields in the Customizer. Perhaps, at launch, you only have Twitter and Facebook accounts, but six months down the road you spin up an Instagram account. Now, you’ve got to dive back into the code and go through the somewhat convoluted steps to add a new field to your Customizer settings.

You could even add the links to your social networks in a menu and then add a custom class to the menu items, like menu-icon-facebook, and then target that class (or set of classes, for all of your networks) in your CSS. Still, that requires an extra step and if you’re building a site for someone who may not be familiar with WordPress’ menu interface this could be confusing or frustrating.

So, what’s the solution? This is what I’ve found to be useful time and time again. First, it can be helpful to register a brand new menu location for your social networks:

View the code on Gist.

By registering a menu, you’re making it easy to reuse that menu anywhere you want throughout your site. You can add it as a widget via the built-in Custom Menu widget; you can create a custom template tag in your theme to display the menu attached to that particular menu location, and any number of countless things that can be done with a WordPress navigation menu. You’re already making life easier for yourself by relying on WordPress to do a bunch of work for you!

You don’t want to have to worry about doing any extra work when adding your menu items. You want to create the menu, add your links, and have your social icons displayed through some sort of magic. Well, I don’t have any actual magic for you but I do have a Sass snippet that will get the job done for you.

By targeting the menu and the href attribute values of the menu items, we can display the corresponding icon for each social network. Let’s take a look at that:

View the code on Gist.

First, you’re creating a $social-sites Sass list which holds the names of all of our social networks. Be mindful of this and don’t try to get cute with the names as they have to correspond directly to the URL you’re providing for your links.

Next, you’re targeting the links within your menu and looping through your $social-sites list to add an SVG as a background image. Your each loop is going to target your link’s href attribute and set the background image to match. This requires you to remember two things:

1. As noted above, be sure to use the actual domain of the social network so your href targeting will work as expected.
2. Remember to name your SVG files (or whatever other files you wish to use) to include the domain name. You can append or prepend a string (like icon-facebook.svg), but just be sure to make sure your background-image path matches your naming convention.

Now, wherever you use that menu throughout your site you should “automatically” see the icon displayed. You’ll want to do some other work to make sure the text also doesn’t display so that you’re seeing just the icon, or tweak the styles as you see fit if you do wish to display both the icon and the link text. You have the power!

2. Open Graph (OG) and Meta Tags

With social networks in mind, you’ll also want to make sure that any content shared from your site looks beautiful across every platform. There are plugins that will handle this for you, like Yoast SEO, but what if you don’t need a full SEO plugin or prefer to use a different solution for search engine optimization?

Fret not! OG and other essential meta tags can be a bit daunting at first, but with a recent update to wd_s we’ve tried to take some of the guesswork out of them. There are a lot of conditions that you could, and should, check for if you’re writing your own tags. You may want to serve up different sets of data for different post types or taxonomies, in which case you would need to modify the example snippet a bit to suit your needs.

Of course, if you’re using a plugin like Yoast, which will also provide you with all of the fancy-schmancy meta tags you need to produce beautiful Twitter and Facebook cards, then we’ll want to avoid messing with them. At WDS, we don’t tend to run into many clients who want to use an SEO plugin other than Yoast, so the snippet you’ll see below includes a check for that specific plugin:

View the code on Gist.

If Yoast is active, bail so that we don’t wind up with duplicate meta tags causing headaches and collisions. If you make this a part of your framework, you’ll want to be sure to either add in the checks for any plugins you may use to manipulate OG tags or simply remember to remove the function if you know that you’re going to be using a plugin to handle these tags. This also future-proofs your theme, if you’re doing work for a client. Should they launch their site without Yoast and then decide to add it six months down the line, you’ve got them covered. Your custom meta tag solution won’t interfere with their activation of the plugin, thanks to the conditional at the top of the function.

3. Archive Page Titles

You’re always going to have archive pages of some sort in WordPress, but for some reason, the titles of these pages are always a point of contention. Out of the box, WordPress creates a category archive page with a heading like “Category: Category Name.” Have you ever wanted to keep the prefix on that title? I certainly haven’t, and I don’t think we’ve had a single project in my (so far) seven years at WebDevStudios where a client wanted us to keep the prefix either.

If you’re working on a project for a client of your own, perhaps you never discussed this ahead of time. Since the archive pages are created dynamically, it may just be a passing note that the pages will retain the same look and feel as the rest of the site without much more discussion. However, more often than not, you’ll realize that everybody has an opinion on this after the fact even if they never stated their preference before.

Luckily, it’s pretty simple to remove the prefix from titles of these archive pages. So, instead of displaying “Category: Category Name” as the page title, you will instead display “Category Name.” Maybe you do want to add something before (or after) the base page title. Good news: you can! This snippet simply removes the prefix, but you can modify it to do any number of things to suit your needs from project to project. If nothing else, this is a handy snippet to keep on hand so you don’t have to Google “remove prefix from WordPress archive pages” every time you need to do this.

View the code on Gist.

4. Numeric Pagination

This isn’t a huge one, as WordPress provides an out-of-the-box way to display pagination throughout a site via paginate_links. So, what can we add to something already built into WordPress? We can make it easier to use and reuse in your templates. As you can see at the Codex link above, paginate_links offers a whole slew of options of which you can take advantage. You can customize the previous and next link text and how many page numbers are displayed in your pagination amongst others.

The issue with just using the core template tag is that anytime you use it, you need to set your own values, if you want to override the defaults provided by WordPress. We can get around this by creating our own template tag and invoking paginate_links with our own array of customizable options.

View the code on Gist.

In this snippet, we’re creating a template tag to power our paginated links. The function accepts an array, which means we can still customize the output of the links as if we were using paginate_links by itself, but we have the bonus of being able to include our own set of default values so you never have to worry about filling those in whenever you want to use this function. Then, if you do happen to have a spot on your site where you want to override your own custom defaults, you simply need to call the new template tag with the array of custom values passed in. As our function is, more or less, a wrapper for paginate_links, it accepts the same parameters for customization as seen in the Codex.

5. Post Headers and Footers

Nine times out of ten, the blog posts for your project are going to require some additional information displayed outside of title and content. We’re talking categories, tags, a posted-on date, and an author name. Once again, WordPress offers a number of ways to grab all of that information out of the box, but why toil around looking for the best way to display these extra details when you can just have it from the get-go? After all, am I going to need get_categories, wp_list_categories, get_the_category_list, wp_get_post_categories…? Stop the insanity!

Instead, let’s do this once and we can always tweak it on a per-project basis if need be, rather than starting with a blank canvas every single time. Let’s start at the top where we’ll want to display some important information: author and post date. With the following snippet, not only are we just getting the information we need, we’re also outputting it with some handy-dandy markup to make it even more usable.

View the code on Gist.

So now, you’ve digested the post title, author, and posted date. You’re ready to sit back and enjoy the contents of the post before you reach the end and look for some additional, related content and ready your nimble fingers to leave a friendly comment on the post (because you would never leave anything other than a friendly comment somewhere on the internet).

This snippet, just like the others in this post, can be modified to fit your needs. For us, we’re only going to try and display categories and tags on posts but you can adjust this for other post types or even rework the template tag on a deeper level to include custom taxonomies. First, we check to see if we’re in a post before checking for and displaying categories and tags. Then, if comments are open and the post isn’t protected, we’ll display the comments link. Finally, we’re displaying the edit post link so you can quickly jump back into edit mode if you need to do so.

View the code on Gist.

Quick Wrap-Up

Now that you’ve got a handful of useful snippets to speed up your next project, what other ways can you think of to smartly reuse code from project to project smartly, and what are you going to do with all of that newfound spare time? Let us know in the comments below!

The post Five Reusable Code Snippets to Reduce Development Time appeared first on WebDevStudios.

The purpose of this post is to try and provide a different approach to building a thing. In this case, that thing will be a modal UI component. Yes, another modal! There are many facets of JavaScript that I love and building UI components is one of them.

It’s important to note what I stated above. We will be looking at a different approach, not a new one. While the example I will be using is written in ES2015 there’s nothing new or groundbreaking about it. It just might take a different approach than what you might normally see.

On many of the projects we work on here at WDS, there is almost always a requirement to have at least one modal and in some cases even multiple modals on the same page. While this may seem simple to implement, there are a lot of questions and observations that should be taken into consideration.

• What is going to be the trigger for opening a modal?
• If there are multiple modals on one page, then we will need multiple, unique triggers.
• What will be the close trigger for each of the modals?
• What will be the contents of the modals?
• Will the content be created on the fly, or will it be markup that has already been rendered to the page but is just hidden?
• How can we nicely present the modal?
• Implementing a nice animation into a modal can be tricky!
• Do you need to apply a CSS class to another element on the page when the modal is open and the remove it when the modal is closed?

In a lot of cases, a typical approach would be to create a JavaScript module or file for the particular project you are working on and code a solution to meet the requirements for that project. Then two months later when a new project starts, you follow the same process and re-code something new to meet the requirements of the new project.

What I’m trying to point out here is that the modal we’ve ended up writing is not very reusable from project to project. Sure, you might be able to take bits and pieces of code and move them from project to project, but in the end, you are creating a unique solution for each new project.

Let’s explore a different approach! One that would allow for code reuse across projects.

Building Reusable Components

The concept that I’d like to drive home in this post is to start thinking about building reusable components that are powered by their API. I’ve really learned a lot about this concept by learning React and Redux. Feel free to check out the experimental WordPress theme I built using React and Redux.

You don’t need to be using any fancy frameworks in order to implement the idea of building reusable components. To be honest, the thought of having a UI component such as a modal that has default options you can override and callback functions you can tap into is super exciting!

For this post, we are going to focus on building a modal UI component in vanilla ES2015 that is reusable. This isn’t going to be a full-blown solution, but it will hopefully be enough to show the power behind building reusable components that expose an API for powering them.

Since we will be using ES2015, let’s start by scaffolding out a class that we will use for our component:

Next, just like in PHP, the constructor function is going to be run each time the Modal class is instantiated. Our Modal class will take two parameters. The openTrigger will be the HTML element that triggers opening the modal and the options parameter will be the options we pass in to override the defaults.

You will notice in the code above that we are using Object.assign(). This is an exciting new method in ES2015 that allows for merging two objects. I would encourage you to read and learn more about Object.assign(). Anyways, we are just merging the options object being passed in with the default options provided.

For this example, we are going to use a new ES2015 feature called template literals to create the markup needed for our modal. Notice how we are able to display variables right inside our template literal strings.

Next, we will need a render() method that will be responsible for putting together the template and attaching it to the DOM. As you can see, we are using a document fragment to build out the markup. A document fragment is a minimal document object that isn’t actually a part of the DOM. It’s a performant way of composing some markup in memory then attaching it to an element.

Now we need open and close methods. These two function will be somewhat similar, but let’s touch on a few key points.

First, both functions check to see if a callback function has been passed in via the Modal options. For the open() method the callback that is checked for is this.config.onBefore() and for the close method the callback checked for is this.config.onAfter(). If either has been set, it will be called.

Second, we are utilizing a setTimeout() function along with arrow functions to add and remove CSS classes that will help us animate in the modal. This perhaps isn’t the best solution here, but for the sake of this example, it works just fine. You could explore using transition or animation events as other possible solutions.

The last function is a simple bindEvents() function that’s sole purpose is to bind the open() function to the open trigger specified by the user.

Now that we have our modal class built out with the basic functionality we can now create a couple of different modals that will work independently of each other.

Here is code that will instantiate two different modals. Each will have a different openTrigger parameter as well as different options.

First, we are declaring two different button elements that will act as our modal triggers.

Then we ‘new-up’ each modal with their respective trigger button, as well as their custom options. Notice how I am writing an anonymous function that will be called in our open() and close() methods.

Check out this CodePen for a working demo.

I hope that this post shows the power of creating reusable components. It doesn’t have to be confined to just JavaScript, as well. No matter what you are coding, it’s always great to do it with the mindset of reusability.

Feel free to leave a comment below to further the discussion!

The post JavaScript: Reusable Components and API appeared first on WebDevStudios.