Case for CKEDITOR.config

[Reinmar]

Right after we removed that feature we found a pretty interesting use case for a global config :D.

The case is bundling with Rollup. This requires a file which implements an entry point for such a bundle. It must import all necessary files, including features and creators (which are not referenced anywhere else). Only then Rollup will include them.

The basic implementation can therefore look like this:

import CKEDITOR from './ckeditor.js';
import FeatureA from './feature-a/a.js';
import CreatorB from './creator-b/b.js';

const defaultConfig = () => {
    return {
        creator: CreatorB,
        features: [ FeatureA, ... ]
    };
};

export default createEditor( elements, config ) {
    return CKEDITOR.create( elements, Object.assign( defaultConfig(), config ) );
}

However, it would be great if it could simply export the CKEDITOR object. If we had a global config we could do:

import CKEDITOR from './ckeditor.js';
import FeatureA from './feature-a/a.js';
import CreatorB from './creator-b/b.js';

CKEDITOR.config.set( {
    creator: CreatorB,
    features: [ FeatureA, ... ]
} );

export default CKEDITOR;

Much, much nicer.

[Reinmar]

There's another topic, which is related to this one and will need to be addressed: ckeditor/ckeditor5-design#140

In short – editor will need to be subclassable and the idea of creators didn't work. Creators have no sense of existence, because they try to inject some logic into editors, by extending them. And the cleanest way to do this is by inheritance, not by a separate class which is initialised too late to do serious stuff and should not override some existing implementations, what greatly limits it.

So, if we'll go with subclassable editors, and we simply don't see any other way at the moment, we'll be able to solve the issue with Rollup in a totally different way:

import StandardEditor from './editor/standardeditor.js';
import FeatureA from './feature-a/a.js';

export default class BuildStandardEditor extends StandardEditor {
    constructor( ... args ) {
        super( ...args );

        this.config.features.push( FeatureA );
    }
}

Alternatively, we could keep the same logic on static Editor.create method which could be quite useful (note: I think that elements should be moved to config):

class Editor {
    ...

    // @returns {Promise}
    static create( config ) {
        return new this( config ).init();
    }
}

// For Rollup:

import StandardEditor from './editor/standardeditor.js';
import FeatureA from './feature-a/a.js';

export default class BuildStandardEditor extends StandardEditor {
    static create( config ) {
        // That's modifying the config object, so cloning would be necessary perhaps.
        config.plugins = [ ...config.plugins, FeatureA ];

        return super( config );
    }
}

[Reinmar]

In case it wasn't clear – my previous comment points out that the global config isn't necessary if we change the architecture.

[fredck]

global config isn't necessary if we change the architecture

What is the big deal with it anyway? Is it worth this whole refactoring effort for something which was quite simple?

[Reinmar]

We need to change the architecture anyway. So if we can avoid adding a code that we don't explicitly need, then we should do that. And currently there's very little value that a global config could give us. If a clear use cases for it will appear, then we certainly implement it.

[Reinmar]

We implemented the static EditorClass.build property for this purpose: https://ckeditor5.github.io/docs/nightly/ckeditor5/latest/builds/guides/development/installing-plugins.html#difference-between-both-methods. Turned out to be a bit more than just a global config.