should not be shared without permission. I. JavaScript “Basics” & “Best Practices” II. Anatomy of a jQuery Plugin III. jQuery Plugin Patterns IV. JavaScript Execution Patterns WHAT WE WILL COVER
should not be shared without permission. All JavaScript variables are camelCase Except for a class/constructor which are TitleCased jQuery objects prefixed with a $ Variables are declared at the start of the scope, on their own line, and with their own var keyword VARIABLE NAMING
should not be shared without permission. More portable Easily make the object available on the window window.Plugin = Plugin; Better organization Logic is outside of the jQuery plugin Better customization Per element options WHY?
should not be shared without permission. Need a loop to handle multiple .tabs elements on a page Cluttering the global namespace You don’t have to make it a jQuery plugin to fix this SHORTCOMINGS
should not be shared without permission. Keep plugin functionality outside of jQuery instantiation Don’t be scared of using a lot of methods Namespace events Easy to make functionality available to jQuery plugins and for vanilla JS use SO WHAT HAVE WE LEARNED?
should not be shared without permission. More modular Feature specific instead of page specific Easier to add existing features to pages without having to touch JS FEATURE BASED EXECUTION
should not be shared without permission. Break features into separate files Load each feature JS file with script loader Doesn’t load unused JS FEATURE BASED EXECUTION + SCRIPT LOADER
should not be shared without permission. Don’t just haphazardly fire a bunch of JS functions that may or may not be used Come up with a pattern for triggering JS on each page that makes sense for your site WHAT DID WE LEARN?