@karpovsystems What is the purpose of sending the config parameter through the blocks.insert method? How is sending the config parameter to the tool's constructor being currently implemented?

What is the purpose of sending the config parameter through the blocks.insert method?

In my case, it would determine whether the block was created by the user or programmatically.

How is sending the config parameter to the tool's constructor being currently implemented?

I'm not quite clear what you mean, but it's possible to send the config parameter via configuration object https://editorjs.io/provide-custom-configuration

class Test {
    constructor ({config}) {
        console.log(config.foo); // bar
    }
    render () {
        return document.createElement('div');
    }
}

const editor = new EditorJS({
    tools: {
        test: {
            class: Test,
            config: {foo: 'bar'} // passing config data
        }
    },
    data: {
        blocks: [{
            type: 'test'
        }]
    }
});

If you are facing the same issue try data instead of config

@karpovsystems Can you explain a proper use case?

@ranemihir check Header, Image, Embed, Quote, Link tools. All of them use the config parameter

@karpovsystems I know these tools require the config object and is being sent to their respective constructors. But in exactly what context will these tools require it through the blocks.insert method? Why send it through this particular method? is what I am asking.

Let's say you have a button, clicking on which should add Header and Image blocks.

Agree with @ranemihir.

The config property of the Tool constructor params it is the list of options supported by the Tool. They are specified once by the Editor Config. And they are the same through the all blocks of this Tool.

In the attached PR the config is used like an "additional data" and looks like they can be different between several blocks of this Tool.

So if there is only use case of determining whether the block was created by API or not, we can find more logical solution.

@karpovsystems Can you describe why exactly you need to know whether the block was created by API or by Editor core?

Also, there is a little issue:

1. We need to remove config param from the block.insert() method, because it was added there by a mistake.

Can you describe why exactly you need to know whether the block was created by API or by Editor core?

I worked on a spoiler tool. It appends two blocks: spoiler start & spoiler end. Blocks between start & end are spoiler content.
End block is created programmatically, and I needed some flag for detecting that. Since block.insert() didn't work, I put this flag to the data object and created this issue.

I don't mind removing config from block.insert().

@karpovsystems I can't think of a practical use case of the tool. This needs more discussion.

@karpovsystems I think spoiler feature as a container of blocks would be a great idea. For exemple you edit an html page and you want to edit the title of html page. This does not belong to the visble part of the page as it is its attributes generally stored in the head of html .For now I lay out this as an extra paragraph that can be easily wrongly mixed on block move with content of the page on edit.This is because blocks have not move constraints for now. Of course I can decide to have separate inline editor for each group of blocks to prevent this but this bring multiple editorjs complexity management! If you check the tools, the first invisible spoiler that serves as container is stub.