Code Monkey home page Code Monkey logo

d2-proto's Introduction

d2-proto

This is a prototype of some modules that might be considered for Dojo 2.0. This is a working repository of highly experimental code. It is not intended for production use, nor does it indicate or imply any final APIs or direction of Dojo 2.0. Things will change and move around! Use at your own risk.

Modules

The following modules are of interest in this repository:

  • d2-proto/parser - A "modern" version of the dojo/parser. It is intended to only support ES5 compliant user agents. A demonstration test can be found here.
  • d2-proto/lang - Some enhancements changes to the dojo/_base/lang that are designed to behave better in an ES5 world. It currently only contains the functions that I have needed to support the other modules in this repository.
  • d2-proto/properties - Functions to make it easier to work with ES5 properties.
  • d2-proto/compose - An Object compositing and prototyping utility based on ComposeJS, a potential alternative to dojo/_base/declare. It is ES5 property descriptor safe plus it add the ability to define ES5 properties via the compose.property() function.
  • d2-proto/Observable - A class that provides "Harmony-like" Object.observe functionality that is specifically designed to be offloaded to the native functionality that is planned for ES6. It should be possible to delegate most of the functionality to ES6 in the future.
  • d2-proto/dom - A DOM management library the includes put-selector from Kris Zyp plus some enhancements. Also includes the minimal parts of the dojo/selector/lite to get qSA "working" on
  • d2-proto/doc - A module that either returns the browser's document or a pseudo-DOM in which the dom module can operate against for server side DOM generation and manipulation.
  • d2-proto/debug - A "stub" of what might be required in a Dojo 2.0 debug API.
  • d2-proto/widget/Widget - A "dijit-style" base widget based on compose and put.
  • d2-proto/base - A module the requires other modules that provides a "base" similar to the "old" Dojo.

The put module is basically a re-factoring of put-selector and passes Kris' original unit tests, but does not contain some of the feature enhancements that are currently in dom.put().

I have brought in a few other modules from Dojo and refactored them, but this was to get around limitations of using those modules from Dojo and there haven't been any significant functional enhancements.

Requirements

d2-proto currently depends upon:

  • dojo 1.8+
  • dojo2-teststack - for unit testing (although it currently needs my branch for performance benchmark tests).

Also, until teststack is feature complete, there are some additional tests based off of D.O.H. in the tests folder, with the experimental teststack tests in test.

Some of the tests require the following:

Documentation

Experimental documentation is available here.

License

This is licensed under the "New" BSD License.

Contributing

Contributions are welcome in the form of pull requests, but must be covered under the Dojo Foundation CLA. See CONTRIBUTING.md for further information.

d2-proto's People

Contributors

kitsonk avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

d2-proto's Issues

Some proposed compose enhancements

In an attempt to adopt compose() in favor of declare() in ran into a number issues which would make the Dojo 1.x to 2.0 conversion a challenge. I do understand that compose() is not intended to be a 1-to-1 replacement for declare() but some enhancements would make the conversion much simpler.

No instanceof functionality available

The current implementation of compose is missing instanceof functionality which may not be a core requirement for the dojo toolkit itself but dijit (at least dijit tree) and many user applications rely on this functionality. IIHO it is a reasonable requirement to be able test if an object is an instance of some 'class' instead of having to test for the presence of specific object properties. For example:

function bingo() {
    this.hasBalls = function () {
    };
};

var myClass = compose(bingo);
var abc = new myClass();
if (abc.isInstanceOf(bingo) {
      ...
}

compared to:

var abc = new myClass();
if (abc.hasBalls !== undefined) {
      ...
}

      or alternatively

if (hasBalls in abc) {
      ...
}

Objects have no 'own' properties

Considering Dojo 2.0 is embracing the ES5 object capabilities I was hoping to see that instances of objects declared with compose() would have their own properties. Consider the following example:

var myObject = {
    bingo: function () {
        console.log("Bingo");
    },
    name: "bingoClass"
}

var MyClass  = compose(myObject);
var instance = new MyClass();

var properties = Object.getOwnPropertyNames(instance);  // returns an empty array...

This approach (passing every property only by means of the prototype) prevent users from manipulating object properties using most, if not all, of the ES5 object functions. The only way to force 'class' objects to have their own properties is to define every 'class', used in a composition, as a function and declare every property using this as in:

function myObject() {
    this.bingo = function () {
        console.log("Bingo");
    };
    this.name = "bingoClass";
}

var MyClass  = compose(myObject);
var instance = new MyClass();

var properties = Object.getOwnPropertyNames(instance);  // returns an array with 'bingo' and 'name'

This however may have some nasty side-effects as every function will be called with the same set of arguments during 'class' instantiation which brings me to the next issue.

All function are called with the same argument list

All functions used in a composition are called with the same set of arguments.
Consider the following example:

function Country(name, population) {
    this.population = population;
    this.country    = name;
}

function Airport(name) {
    this.airport = name;
}

function Capitol(name) {
    this.capitol = name;
}

function EventTarget(parent) {
          ...
}

var myClass = compose(Country, Airport, Capitol, EventTarget);
var uk = new myClass("UK", "100m");

Unless all functions used in a composition have the same signature AND all parameters in that signature have exactly the same meaning to all functions it is not going to work. One would have to define every function signature with only one argument which would be a JavaScript key:value pairs object as in:

var myclass = function(keywordArgs) {
    this.name = keywordArgs.name || "":
         ...
};

To make the behavior of 'classes' declared with compose predictable I would like to propose that only the very first function, that is arguments[0] is called with the arguments list specified with the new operator. All subsequent functions used in a composition() should be called without any arguments, thus making the first function the designated 'class' constructor.

function EventTarget(parent) {
    this.addEventListener = function (...) {
    };

    if (arguments.length !== 0) {
                ...
    }
}

var ctor = function(kwArgs) {
    // Notice the use of isInstanceOf()
    if (this.isInstanceOf(EventTarget)) {
        EventTarget.call(this, kwArgs.parent);
                    ...

        this.name = kwArgs.name || "";
    }
}

var myClass  = compose(ctor, EventTarget, ... );
var instance = new myClass( {name: "Bingo", parent: someObject} );

This approach, (making the very first function, at arguments[0], the designated 'class' constructor), would mimic some of the dojo.declare constuctor property functionality:

var declare(null, {
    constructor: function (keywordArgs) {
    },
            ...
});

The compose() function signature would look like:

compose-function :== "compose" "(" [constructor / Object] ["," (Function / Object)]* ")"
constructor :== Function

Please let me know what you think.

Decrease wordiness in declarative format

One of the issues customers are having with dojo declarative format is its verbosity as compared to jquery mobile for example. What are your thoughts on reducing the amount of typing on things like:

data-dojo-type ==> data-type

And working with jq community to align on a common set of data- names to use, so that we can start to use similar syntax across these libs?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.