Make it compatible with @editorjs/list

[taurenshaman]

update Line 106 in the constructor:

        //this.data = data && Object.keys(data).length ? data : initialData;
        this.data = initialData;
        if(data && data.items && data.items.length > 0){
            this.data.style = data.style;
            const item0 = data.items[0];
            if(typeof item0 === "object")
                this.data.items = data.items;
            else { // compatible with @editorjs/list
                const items = [];
                data.items.forEach(di => {
                    items.push({
                        content: di,
                        items: []
                    });
                });
                this.data.items = items;
            }
        }

[dfrankow]

I'm not involved in development, but .. what is "compatible with"? You're suggesting a code change, but I don't understand the advantage of the code change.

[taurenshaman]

I'm not involved in development, but .. what is "compatible with"? You're suggesting a code change, but I don't understand the advantage of the code change.

The key is the difference between @editorjs/list and editor-js/nested-list. I have already used @editorjs/list in my website. So if I wanna support nested-list instead of @editorjs/list, I must make sure the editor can also display the old data (in @editorjs/list format) correctly. The code above will upate the old data in @editorjs/list format to editor-js/nested-list format.

[dfrankow]

Well that sounds pretty useful.

[cmeeren]

As described in https://github.com/editor-js/nested-list/issues/75#issuecomment-2259775020, I take issue with this approach, and would urge to keep in mind other usages of editor.js documents than just editor.js itself.

One clear advantage of a block-based format over plain (sanitized, white-listed) HTML, and indeed the reason we went for a block-based format, is that the data format is well-known and fairly limited, making it easier for other tools than editor.js itself to parse the content and format it for other contexts.

For example, our back-end converts editor.js documents for display in Excel cells (plain-text with simple "formatting" such as prepending bullet points with *), to extract the plain text only for search indexing, and render PDF files.

This parsing becomes much more difficult if, for any given type discriminator, different incompatible schema are used. While it is possible to work with, we then have to drop down from a nice, strongly-typed deserialization-based API to a much more verbose and bug-prone JSON-token based API.

My proposal would be to use another type value, such as list2, nested-list, or similar.