Beyond the To-Do List

FOSDEM JS devroom, 2014

Transcript

1. Beyond the To-Do List
   

   View Slide

2. About Me
   ● Front end dev @ trivago
   ● @janvanthoor
   ● G & M, Assembler, SSE, C++, PHP, JS
   

   View Slide

3. Back to the basics
   ● No app frameworks, just JS
   ● Module pattern
   ● AMD
   ● Backbone
   

   View Slide

4. Background
   ● “High performance” Javascript
   ● ABC testing
   ● Browser support
   

   View Slide

5. AMD (Asynchronous Module Definition)
   “The Asynchronous Module Definition (AMD)
   API specifies a mechanism for defining
   modules such that the module and its
   dependencies can be asynchronously loaded."
   

   View Slide

6. AMD - define()
   ● Global function.
   ● Only one required parameter (factory).
   define([id], [dependencies], factory);
   

   View Slide

7. AMD - define() - [dependencies]
   ● Array literal of the required modules.
   ● Are passed to the factory function as
   parameters (in same order).
   define(‘ironMan’
   , [‘stark.tony’, ‘ego.massive’, ‘suit’]
   , function(Tony, Ego, Suit) {});
   

   View Slide

8. AMD - define() - factory
   ● Function that should be executed to
   instantiate the module or object.
   ● Only executed once.
   define(‘ironMan’
   , [‘stark.tony’, ‘ego.massive’, ‘suit’]
   , function(Tony, Ego, Suit) {
   return Tony.apply(Ego).don(Suit);
   });
   

   View Slide

9. AMD - require()
   ● Global function.
   ● dependencies: array literal of modules to
   instantiate
   require([‘ironMan’, ‘blackWidow’]
   , function(Tony, Natasha) {
   // CENSORED
   });
   

   View Slide

10. Module Pattern
    ● Common JS coding pattern.
    ● Encapsulates “privacy” using closures.
    ● Returns an object literal as public API.
    

    View Slide

11. Module Pattern: Code
    var DeepThought = function() {
    var _theAnswer = 42;
    return {
    tellUsTheAnswer: function() {
    return _theAnswer;
    }
    }
    };
    DeepThought.tellUsTheAnswer();
    

    View Slide

12. Definition: module
    ● Self-contained implementation of a website
    component.
    ● Initialization of event bindings.
    ● Instantiates and glues MV* components.
    

    View Slide

13. Module Communication
    ● Events (pub / sub via mediator)
    ○ Passive!
    ○ Past tense!
    ○ Verb + target (“found:theAnswer”, “added:bookmark”)
    ● Public APIs (accessible via dependency)
    ○ imperative actions (tellUsTheAnswer)
    

    View Slide

14. What is MV*
    ● Separation of concerns.
    ● Most modules implementations include:
    ○ Rendering / updating user interfaces.
    ○ Handling user input.
    ○ Server communication.
    ● MV* is too simplistic when applied to large-
    scale JS architecture, however, when
    applied to a module….
    

    View Slide

15. View Slide

16. Backbone
    ● “Magic library” for structuring web
    applications.
    ● Not a full-stack framework, more
    “convention than code”.
    ● Data is represented as a model.
    ● Views react to changes in models and
    user interaction.
    

    View Slide

17. Underscore
    ● Utility library for Javascript.
    ● Does not extend any built-in JS objects.
    ● Uses “_” as a global alias.
    ● Functions map to native implementations
    where possible.
    

    View Slide

18. AMD + Backbone
    ● Can use AMD to define MV* components
    (or just define views in module)
    ● The factory function should return the
    extended prototype of Backbone.*
    ● Instances are created with new keyword.
    

    View Slide

19. AMD + Backbone: Code
    define(“lovelyView”, function() {
    return Backbone.View.extend({
    events: {...}
    , onClick: function() {...}
    });
    });
    new (require(“lovelyView”));
    

    View Slide

20. Improvements
    ● Sandboxing: use one central dependency
    with message bus for module
    communication.
    ● Standardized module definition: all modules
    contain references to the app instance and
    other shared resouces.
    

    View Slide

21. ?’s
    @janvanthoor
    @milchjieper
    

    View Slide