Over the past year, I have been working very hard to learn JavaScript deeply. I have even purposefully taken the\u00a0approach to learn it outside of the WordPress ecosystem. Why? Because it promotes exploring and learning different techniques that you can then take and apply to WordPress!<\/p>\n
The purpose of this post is to try and provide a different approach to building a thing<\/em>. In this case, that thing<\/em>\u00a0will 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.<\/p>\n It’s important to note\u00a0what I stated above. We will be looking at a different approach, not a new one. While the example I will be using\u00a0is written in ES2015 there’s nothing new or groundbreaking about it.\u00a0It just might take a different approach than what you might normally see.<\/p>\n On many of the projects we work on here at WDS, there is almost always a requirement\u00a0to have at least one modal and in some\u00a0cases 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.<\/p>\n 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\u00a0for 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.<\/p>\n 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.<\/p>\n Let’s explore a different approach! One that would allow for code reuse across projects.<\/p>\n 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\u00a0API. I’ve really learned a lot about this concept by learning\u00a0React and Redux. Feel free to check out the\u00a0experimental WordPress theme I built using React and Redux<\/a>.<\/p>\n 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\u00a0a UI component such as a modal that has default options you can override and callback functions you can tap into is super exciting!<\/p>\n For this post, we are going to focus on building a modal UI component in vanilla ES2015 that is reusable.\u00a0This isn’t going to be a full-blown solution,\u00a0but it will hopefully be enough to show the power behind building reusable components that expose an API for powering them.<\/p>\n Since we will be using ES2015, let’s start by scaffolding out a class that we will use for our component:<\/p>\n\n 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 You will notice in the code above that we are using For this example, we are going to use a new ES2015 feature called template literals<\/a> to create the markup needed for our modal. Notice how we are able to display variables right inside our template literal strings.<\/p>\n\n Next, we will need a Now we need open and close methods. These two function will be somewhat similar, but let’s touch on a few key points.<\/p>\n\n First, both functions check to see if a callback function has been passed in via the Modal options. For the Second, we are utilizing a The last function is a simple 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.<\/p>\n Here is code that will instantiate two different modals. Each will have a different First, we are declaring two different button elements that will act as our modal triggers.<\/p>\n 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 Check out this CodePen for a working demo.<\/p>\n\n
Building Reusable Components<\/h3>\n
openTrigger<\/code> 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.<\/p>\n\nObject.assign()<\/code>. This is an exciting new method\u00a0in ES2015 that allows for merging two objects. I would encourage you to read and learn more about Object.assign()<\/a>.\u00a0Anyways, we are just\u00a0merging the options object being passed in with the default options provided.<\/p>\nrender()<\/code> method that will be\u00a0responsible for putting together the template and attaching it to the DOM. As you can see, we are using a document fragment<\/a> 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.<\/p>\n\nopen()<\/code> method the\u00a0callback that is checked for is this.config.onBefore()<\/code> and for the close method the callback checked for is this.config.onAfter().<\/code> If either has been set, it will be called.<\/p>\nsetTimeout()<\/code> 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<\/a> or animation<\/a>\u00a0events as other possible solutions.<\/p>\nbindEvents()<\/code> function that’s sole purpose is to bind the open()<\/code> function to the\u00a0open trigger specified by the user.<\/p>\n\nopenTrigger<\/code> parameter as well as different options.<\/p>\n\nopen()<\/code> and close()<\/code> methods.<\/p>\n