Section 5: Implement jQuery Part 2 of 2

Overview: Today we will take our feedback jQuery and turn it into a more re-usable plugin

Our Problem

If you remember from the last section, we made a pretty handy little feedback dialog with jQuery. It did the job for what we needed it to, however, we may find ourselves wanting to re-use this on another project. We will have to do a lot of copy/pasting, and then a probably some code changes. It would be nice if we could just include our JS files, call a method or two, and be done with it... after all we have written this code already right?

So let's address the problems:

Problem
  • HTML for the modal is on the server
  • Text is not fully configurable, no styling options either
  • Requires specific HTML attributes (ID's must be exact)
  • A lot of
    $
    $ references (not the good kind)
Solution
  • Put the modal HTML in the feedback object
  • Pass in more settings
  • Allow attributes and selectors to be passed in.... but have defaults
  • Use plain JS whenever we can

So the solution is to make our code into a plugin that we can re-use all over, very easily. No problem, here is a very generic way to make a plugin:

Re-organize our code

So we have decided to make our feedback jQuery into a plugin that we can re-use all over. But we have the above noted issues to overcome. A lot of these problems can be solved by allowing the user to pass in more settings and configurationw to the object. But what if we don't want to force the user to pass in these settings? We need a way to have both, and
$.extend()
has the answer for us.


See the Pen dJMLLL by Mike P (@mikedemo) on CodePen.


So this is a bit confusing, but walking through the comments, it is not really all that much. All we are doing is:
  1. Adding a function to jQuery that will return our object
  2. Create our object and all of its properties
  3. Merge the object and its properties with an object we pass in as configuration
  4. Return the new object that is both our original plus the configuration


The result is that we can pass in a configuration object to override any of the object's "default" properties. So now we have the ability to use default settings, or rely on ones passed in, which is a huge step. So let's port our code over into this new format:

See the Pen RxamdK by Mike P (@mikedemo) on CodePen.

Pass in all the things!

So now that we have an object that is a bit more flexible in allowing us to pass in parameters or it will use its defaults, lets really expand on what we are passing in to address some of thes problems.

Selectors

To separate our plugin's code from using such specific selectors (EX:
$('#showFeedbackForm')
), lets allow those the selectors to be passed in, so that our code only ever references the property that they were assigned to. Here is an example of how we can do that, and then we can apply the same principle to our plugin:

See the Pen YYqoJe by Mike P (@mikedemo) on CodePen.


Styles, titles, and text

Just like we passed in the ID's to be used for selecting the elements, we can pass in things like tites, names, pretty much any text that we might want to have configurable, as well as CSS classes or styles we want to add to elements.

Inject HTML, or don't

A problem mentioned earlier was the modal HTML having to be copied and pasted over into the HTML anytime you want to use this plugin. Rather than assume the HTML will be there for us, our plugin should probably just inject the HTML itself by default. Since we can allow a setting to be passed in to tell us whether or not to inject the modal HTML or not, we are not forcing plugin users to use our modal if they don't want to, just providing a default that can be used.

Using a multi-line string, we can create the HTML for a modal and then append to to the body, something like this:

See the Pen inject modal HTML into body by Mike P (@mikedemo) on CodePen.

Minimize jQuery usage

Anytime we reference a
$
in our code, we are using jQuery to do something. Many times, this is not necessary as we have seen, and the plain old JS way is roughly as much code. To write the most efficient client side code we can, we need to limit (or ultimatly not use) jQuery references. A browser will execute plain JS significantly faster than it will execute jQuery, so we want to take advantage of that when we can. The goal is not to make your life hard, we will certainly use jQuery, but to save on performance when we can. Go for the low hanging fruit to start, such as instead of
$(this).val()
just do
this.value

Refactor Result

So our refactor result is below. It looks significantly differnt at first, but knowing how we constructed this, you know it is really the same code we once had, just refactored a bit to make it more generic and allow settings to allow us to re-use this code all over.


Our new HTML



Our new jQuery:



And a working demo:


See the Pen VyjwzW by Mike P (@mikedemo) on CodePen.