[RFR] Starting migration to ES6

[jpetitcolas]

This PR aims to introduce ES6 features on ng-admin. For a first PR, we will restrict to Main/component/service/config folder.

Retro-compatibility should be preserved, still using getters and setters the functional way (field.validation({ required: true })).

Left tasks:

• Fix creation view
• Fix show view
• Add detail links on list views
• Fix list filters
• Use core-js polyfill
• Fix tests
• Review build process to concatenate polyfill with configuration
• Add back fields setter behavior, calling it several times should append fields instead of replacing all of them
• Add mocha tests to grunt

[jpetitcolas]

I finally get a display on dashboard view, using the new ES6 classes.

I'm wondering if we shouldn't break retro-compatibility with this major change. Indeed, to make it compliant with the old version, I had to remove getters and setters (to prevent name conflict issues) to put function like:

layout() {
    if (arguments.length) {
        this._layout = arguments[0];
        return this;
    }

    return this._layout;
}

Moreover, I am not happy with the way I render classes publicly accessible, using:

window.ngadmin = window.ngadmin || {};
window.ngadmin.Application = Application;

But I didn't find a cleaner solution.

Still in (lot of) WIP.

[jpetitcolas]

@fzaninotto, I spotted something weird with master blog example config:

comment.editionView()
    .fields(comment.creationView().fields())
    .fields([
        nga.field(null, 'template')
            .label('')
            .template('<post-link entry="entry"></post-link>')
    ]);

We call the fields method twice. Wouldn't it be more intuitive to consider fields as a more common setter, just replacing fields value when called instead of appending it?

I propose to replace it by:

comment.editionView().fields([
    comment.creationView().fields(),
    nga.field(null, 'template')
        .label('')
        .template('<post-link entry="entry"></post-link>')
]);

Do you agree? It would break a little bit BC, but not sure a lot of people use this syntax. Of course it will be mentioned in the changelog;

[fzaninotto]

You're right that fields() should behave like a setter and not an adder, except that your second example also shows something unexpected: adding an array of fields instead of a field. As I don't want to pass up a sure thing, until we find a better way to reuse existing fields, I suggest we stay as is for now.

[jpetitcolas]

We already pass both fields and array to fields method. For instance, the post.editionView configuration:

post.editionView()
    // ...
    .fields([
        post.creationView().fields(),
        nga.field('tags', 'reference_many')
            .targetEntity(tag)
            .targetField(nga.field('name'))
            // ...
    ]);

This is why we have to flatten the fields array at some places.

I propose to add a console.warning if using fields() setter when having already some fields, and switch to the new behavior at next version.

Warning: you are using fields setter while there is already some configured fields. In next version, calling several times this method will replace all fields, instead of just appending them. You should consider using fields(existingFieldsArray, newFieldA, newFieldB, ...) instead.

What do you think?

[jpetitcolas]

I updated PR description with left tasks.

[jpetitcolas]

No need as already embedded in ng-admin-configuration.js

[jpetitcolas]

Switching to RFR.

[jpetitcolas]

All tests are passing locally. Travis fails because of SauceLabs. I let you review it, and then I'll push my changes to re-trigger another build.

[fzaninotto]

no trace of ConfigurationFactory in the code below.

[fzaninotto]

Please check out https://github.com/marmelab/ng-admin/pull/327/files and the current master version of custom Fields to make sure you don't forget anything.

[fzaninotto]

don't forget fractionSize()

[fzaninotto]

Thanks a lot!