Using jquery (Intermediate), part 2nd: Creating your own Plug-ins

Brief introduction

In previous articles in this series using jquery, part 2nd: Intermediate Jquery:ui Projects, I introduced the use of Plug-ins in jquery code to improve the efficiency of Web applications. But it's important to know that these plug-ins are not created by themselves, they are written, tested, and perfected by developers who dedicate their free time to the JQuery community. We do this for free, out of love for our own code. This article focuses on how you can repay this great community, how to write your own plug-ins and upload them to JQuery's plugin page. This allows everyone to use the plug-ins you create to make the entire jQuery development community better. You also make your contribution this year.

As I write the plug-ins in this article, I find that the process of creating plug-ins and the framework used to create them is very straightforward. The hard part is thinking about things that others haven't done, and writing JavaScript code that can actually do something. Because the plug-in structure is simple and clear, for beginners it is easy to learn, for the master it is very flexible, so the number of plug-ins increased rapidly.

Of course, in studying the content of this article, I also found that each author has a different style of writing plug-ins, JQuery allows several different types of plug-ins to write style. In this article, I'll focus on the simplest style, and the style recommended by JQuery itself, and you'll see the difference or different options when the plugin pops up.

Description Plugin

The 1th step in creating a plugin is of course to think of a good idea. Like most ideas, other people always create opportunities for you. The plugin I developed in this article, for example, is not a novel concept, but it was not found in the JQuery plug-in community when I wrote the text. I know I personally will benefit a lot from this plugin.

My plugin is a numberformatter plugin. Processing server-side code (such as Java™ or PHP) and internationalized users should be familiar with digital formatting. It is well known that not everyone formats numbers in the same way. For example, not everyone uses "Li" to measure distances. In the United States, the number may be written as "1,250,500.75" (this number is copied from my tax form), but in other countries the wording may be completely different: Germany is "1.250.500,75", France is "1 250 500,75", Switzerland is "1 ' 250" 500.75 ", Japan is" 125,0500.75 ". The numbers are exactly the same, but you use different formats when presenting to Web application users.

So the question boils down to how do you show these numbers to people from different countries when you are writing an internationalized application? Of course, the solution is to use server-side formatting, which is very common. Java has a robust format library that makes the formatting of numbers very simple. When you use numbers to set up a page on a server, the server handles these numbers. However, many times the numbers may not be on the server, so you need a way to format the numbers on the client without having to talk to the server.

The typical use cases I describe here are as follows. There is an input field in your Web application that asks the user to enter their salary. In the United States, users may enter "$65000", "65,000", "65000" and "65,000.00" in various formats. All of these numbers are the same, but you need to control how these numbers are displayed on the screen to provide a better user experience. You can call the server after you enter a number, but it's too cumbersome to have many numeric fields with different formats. In addition, if you can handle the problem on the client and provide immediate feedback to the user, then you do not need to do so.

So I set up a vacancy and then I will try to fill this vacancy with the Javascript/jquery feature. My plug-in will provide a number format on the client and provide a way for others to internationalize the Web application without having to talk to the server. As an additional feature, my plug-in can also provide a reverse operation that enables developers to parse numbers and get numbers from formatted text strings. This can also be applied to numeric operations on the client computer. In addition, I will simulate the functionality in the Java Decimalformatter class to maintain commonality between the client code that performs the number formatting and the standard server-side methods.

The 1th result: I found a plugin requirement and then defined the vacancy I could fill for that requirement.

Plug-in rules

The JQuery team built a common and trusted environment for plug-in users by creating a number of common rules that they want the plugin authors to follow. Given that the JQuery team is a lot smarter than I am, I have no reason to violate these rules, right? For that reason, I list these rules here and try to comply with them at every step of the plug-in.

The file is named "Jquery.<your plug-in Name>.js"
This makes sense because you want the user to see the file as soon as they know it is a jQuery plug-in and which plugin it is.

Check complete. My plugin will be named "Jquery.numberformatter.js".

All new methods are attached to the Jquery.fn object, all new features are attached to the JQuery object
This may be a bit hard to understand at this stage, and I'll talk more about it in the next section because it's the most important rule in the actual coding process.

Check complete. My methods/functions will only be attached to these two objects.

"This" is used to refer to the JQuery object
This facilitates the authoring of plug-in authors, which allows all plug-in authors to know which object will be received from JQuery when referencing "this".

Check complete. I will use only "this" to refer to the JQuery object.

The end of all methods/functions defined in the plug-in must be preceded by a ";" (semicolon), otherwise it will not be conducive to the minimization of the code.
Because this is the best practice for minimizing JavaScript files, it's much worse than the minimum, and your plug-in may soon be discarded.

Check complete. All methods/functions will end with ";".

All methods must return the JQuery object except as specifically noted
The order chain (daisy-chaining) of the JQuery method is very famous, and if you write a plug-in that breaks the chain, it will definitely "break the chain".

Check complete. My format () method returns the JQuery object, although my parse () method does not return the jquery object, but I note in many places that the function breaks the chain. (After all, it is not possible to return a number object without breaking the chain).

You should always use the This.each () iteration to match the elements, which is a reliable and efficient way to iterate over objects.
For performance and stability reasons, they recommend that all methods use it to iterate over the matching elements.

Check complete. My method will only use the method to iterate through the matching elements.

Always use "jQuery" instead of "$" in your plug-in code
This is important to enable users who have conflicting "$" (those who use another JavaScript library) to use the var JQ = jquery.noconflict (); function to change their jQuery alias (pseudonym). However, when I looked at many plug-ins, I found that the rule was often not adhered to, which is unfortunate. If a developer needs to change the JQuery alias, it probably means that the plugin will be discarded.

Check complete. In my plugin, I will only use jQuery instead of its alias "$".

Well, these are the rules and recommendations that you must follow in your plug-in code. The real problem is that they are actually mandatory, because if you don't follow these plug-in rules, your plugin won't be widely used, and you'll get bad feedback. As a result, the plugin is no longer available to anyone, and the time you spend will be in vain. It is therefore important to comply with these rules. This will not only help you stand out from the crowd, guarantee the uniformity of your code, but also increase your plug-in's chances of success.