Date post: | 14-Jan-2017 |
Category: |
Software |
Upload: | visual-engineering |
View: | 451 times |
Download: | 2 times |
Javascript Design Patterns. AMD & commonJS.
RequireJS
Marc Torrent Vernetta
Javascript Design Patterns
A reusable solution that can be applied to commonly occurring problems
in software design -in our case- in writing JavaScript Web application.
What is a Pattern?
Templates for how we solve problems - ones which can be used in quite
a few different situations situations
Addy Osmani
Three Main Benefits
1. Proven Solutions2. Easily Reused3. Expressive
NOT EXACT SOLUTIONS SUPPORT DEVELOPERS
A Good Pattern
1. Solves a particular problem2. Not an obvious solution3. A proven described concept4. Describe a relationship
Display some recurring phenomenon:
❖ Fitness of purpose❖ Usefulness❖ Applicability
Antipatterns
1. Polluting global namespace2. Strings to setTimeout and setInterval + eval()3. Modify the Object prototype (very bad!!)4. Javascript in an inline form5. Use of document.write
Knowledge for anti-patterns is critical for success !!!!
Antipatterns
1. Polluting global namespace2. Strings to setTimeout and setInterval + eval()3. Modify the Object prototype (very bad!!)4. Javascript in an inline form5. Use of document.write
Knowledge for anti-patterns is critical for success !!!!
Design Pattern Types
➢ Creational○ Factory Pattern○ Constructor Pattern○ Singleton Pattern○ Prototype Pattern
➢ Structural○ Module Pattern○ Adapter Pattern○ Decorator Pattern○ Façade Pattern○ Mixin Pattern○ Flyweight Pattern
➢ Behavioral○ Mediator Pattern○ Observer Pattern
- Classes
- Objects
Creational Patterns
Constructor Pattern
Constructor Pattern - Prototype
Prototype Pattern
Sub-Classing
Mixin Pattern
Structural Patterns
Module Pattern - Object Literal
Module Pattern - IIFE
Module Pattern - Revealing
Behavioral Patterns
Observer Pattern - I
SUBJECT STATE
OBSERVERS LIST
OBSERVER OBSERVER OBSERVER OBSERVER OBSERVER
N O T I F Y
CONCRETE SUBJECT
CONCRETEOBSERVER
UPDATEUPDATEUPDATEUPDATEUPDATE
Observer Pattern - II
Observer Pattern - III
Observer Pattern - IV
Observer Pattern - V
Observer Pattern - VI
Observer Pattern - VII
Publish/Subscribe Pattern - I
PUBLISHER(SUBJECT)
SUBSCRIBER
EVENT AGGREGATOR
SUBSCRIBER SUBSCRIBER
Publish/Subscribe Pattern II
Publish/Subscribe Pattern III
Publish/Subscribe Pattern IV
Mediator Pattern - I
SUBJECT
SUBSCRIBER
EVENT AGGREGATOR
SUBSCRIBER SUBSCRIBER
MEDIATOR
Mediator Pattern - II
Mediator Pattern - III
Mediator Pattern - IV
Mediator Pattern - V
Modern Modular JavaScript Design Patterns
Module A Module B Module C Module N…...
Application
- Modular Application- Loosely Coupled
- Dependency Control- Script Loader
➢ BROWSER:- Asynchronous
Module Definition (AMD)
- requireJS➢ SERVER:
- commonJS
Dependency Control
AMD Modules
➢ Defining modules with dependencies to other modules.➢ The module and dependencies can be asynchronously
loaded.➢ Both modules are asynchronous and highly flexible by
nature➢ Removes the tight coupling between code and module
identity
AMD Modules Advantages
● Provides a clear proposal for how to approach defining flexible modules.
● Significantly cleaner than the present global namespace and <script> tag solutions many of us rely on. There's a clean way to declare stand-alone modules and dependencies they may have.
● Module definitions are encapsulated, helping us to avoid pollution of the global namespace.
● Most AMD loaders support loading modules in the browser without a build process.
● Provides a "transport" approach for including multiple modules in a single file.
● It's possible to lazy load scripts if this is needed.
AMD Modules - define vs require
define(
module_id /*optional*/,
[dependencies] /*optional*/,
definition function /*function for instantiating the
module or object*/
);
require(
[dependencies] /*required*/,
complete function /*function for instantiating the
dependecies*/
);
AMD Modules - define vs require
define([“url_to_anonymous_module”, “named_module_id”],
function(ModuleA, ModuleB) {
function doCoolStuff(a) {
ModuleA.cool(a, ModuleB.getCool());
}
return {
cool: doCoolStuff
};
}
);
require([“myModule”], function(moduleC) {
var superCool = “super cool”;
moduleC.cool(superCool);
});
requireJS
➢ Library for working with AMD modules. Asynchronous script loader and dependency manager.
➢ Easy naming definition with a json configuration. Prepare non AMD modules for other AMD modules as its dependency management stays untouched.
➢ Optimization tool for bundling modules in one or many optimized, uglified and minimized module.
➢ With plugin extension for loading non JS scripts, like CSS, JSON, JSONP, etc…
➢ commonJS wrapper for styling AMD module loading with commonJS syntax and reducing verbosity.
requireJS and AMD
require([dependencies], function(depA, depB, ...){});
requirejs([dependencies], function(depA, depB, ...){});
define() function and module definition remains exactly the same
requirejs.config({
baseUrl: ‘path_to_where_scripts_are’,
paths: {
name_of_a_module: ‘relative_path_of_the_module’,
other_module_name: ‘relative_path_of_other_module’
},
shim: {
name_of_a_module: {
exports: ‘Foo’,
},
other_module_name: [“name_of_a_module”]
}
});
requireJS and HTML
<html>
<head></head>
<body>
<script data-main="js/app.js"
src="js/require.js"></script>
<script type=”text/javascript”>
requirejs([“app”], function(app) {
app.start();
});
</script>
</body>
</html>
commonJS modules
➢ Reusable piece of JavaScript which exports specific objects made available to any dependent code.
➢ Unlike AMD, there are typically no function wrappers around such modules.
➢ Two primary parts: a free variable named exports which contains the objects a module wishes to make available to other modules and a require function that modules can use to import the exports of other modules
➢ Only able to define objects which can be tedious to work with if we're trying to obtain constructors out of them
➢ Useful for Server side because it can use io, fs, system, etc..
commonJS in depth
var libA = require(‘package/libA’),
libB = require(‘package/libB’);
function foo(){
libA.log( ‘hello world!’ );
}
exports.foo = foo;
exports.bar = function bar() {
libB.myFunc();
};
var foobar = require(‘foobar’);
foobar.foo();
foobar.bar();
requireJS with commonJS style
define(function(require) {
var moduleA = require(‘moduleA’),
moduleB = require(‘moduleB’);
function doCoolStuff(a) {
moduleA.cool(a, moduleB.getCool());
}
return {
cool: doCoolStuff
};
}
);
Library App with RequireJS & AMD
Thanks for your attention!Leave your questions on the comments section