Converters to nothing

[pjasiun]

It should be possible to have a model element which does not have a corresponding view element. It may mean that there is no editing view for that element or that we want to skip in the data pipeline (getData will skip that element). Now such element will break position mapping for its children and siblings.

I think that such elements, since they are edge cases, should be explicit marked, to avoid bugs when someone forgets about creating converter and gets no error (see https://github.com/ckeditor/ckeditor5-engine/issues/595).

I think that the end-user API should be like this:

buildModelConverter().for( this.data.modelToView )
    .fromElement( 'helper' )
    .toNothing();

[scofalik]

Honestly, I have big doubts about this.

First of all, some parts of code already works on assumption that each model element is mapped to a view element. For sure move and remove change dispatching works like this (though this can still change). Probably other parts of code too. I know that at least for a few times I had some concerns considering mapping and I always assumed that model element is mapped.

Second, model elements are representing a piece of data. Why they should not be converted to view? If you want meta data, you can either use attributes or live positions. Live positions can be passed between clients so they would be okay in collaborative editing. Attributes are meant to work with collaborative editing and we already thought about use cases for them.

Thirdly, when I proposed meta elements in model year ago I got bashed by @fredck that I want to pollute the model :P

[Reinmar]

Thirdly, when I proposed meta elements in model year ago I got bashed by @fredck that I want to pollute the model :P

I'm curious about @pjasiun's case, but @fredck also mentioned non-meta data which, in some cases, may need to be converted to no elements (e.g. they will be only converted to attributes).

Honestly, I have big doubts about this.

I believe that @pjasiun also proposed "invisible elements" in the view. So you'd really convert things to something, but they wouldn't be rendered to DOM. Is that less scary? :D

[scofalik]

Is that less scary? :D.

It is.

[pjasiun]

I believe that @pjasiun also proposed "invisible elements" in the view. So you'd really convert things to something, but they wouldn't be rendered to DOM. Is that less scary? :D

It's less scary because you know how complex converters are and you do not know how complex renderer is ;) If you will have invisible elements in the view you will have the same problem to solve (the positions mapping), but between view and DOM instead of view and model. It might be simpler, but not necessarily.

I'm curious about @pjasiun's case

My case is that I want to omit some elements in the data pipeline. For instance, you want to get only part of the data ignoring headers. Thanks to this changes https://github.com/ckeditor/ckeditor5-engine/issues/604 you can transform model to view haveing some dump converters for headers, remove these headers in the view structure, and then convert view to data. But I do not think this is the best way to do it. I should be able to tell that these headers should not be converted to the view in the first place.

[scofalik]

I have a feeling that you are trying to abuse converting pipelines too much. I believe that it's fine to convert some stuff to view and remove what you do not need rather than introduce another complication to converters part of the code. It's useful that each model is converted to view.

As long as we are not solving something critical, I am for no.

[Reinmar]

There's nothing critical, ever. We can always align the model to the view 1:1. But that's not the point why they are separated. Before the list case the only difference between them was that model had attrs and view inline elements. Then we allowed 1->N conversion and mapping, but I had to be stubborn proposing this, because we could simply reflect the view list structure in the model and avoid any problems. But believe me – we'd avoid them for like 1 day. Until you need to code all the algorithms on the model.

I'm sure conversion is tricky already, but it's a well covered, centralised piece of code. You can either push logic there and in the specific converters, or spread it across far more places, which are far less structured, testable, composable, etc.

So – "criticalness" of this case or any other case shouldn't determine our choice regarding the conversion. We need to think about the whole picture and compare the risks of having an unnormalised model and performing such a conversion.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).