GitLab Create Editor Group, 27 Jan 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Non-conventional Vue components bootstraping discussion

Description

Staff engineers chat about potentially the non-conventional bootstrapping of the Vue components for the purposes of Create::Editor group. With Natalia Tepluhina, Vitaly Slobodin, and Phil Hughes

A

Hello: everyone uh we are here at the non-conventional view, components bootstrapping discussion uh with the staff engineers uh to discuss one, um as the title puts it. Unconventional use, like bootstrapping of the view, components that I would be really interested in knowing uh opinion about from from our staff engineers. So I will uh start with a very short uh with a very short introduction that will give all the basic background to the um to the process and to the actual actual issue we are trying to uh trying to solve. I will share my screen now.

A

A

So do you see the uh the slide now cool? Yes, so thank you. um So yes, it. uh The the main question is uh coming from a particular problem. We're trying to solve uh in create editor group and here's the thing we have the source editor, the editor that is driving all our code, editing experiences. It can be presented as the raw source editor in the javascript environment, in rails application and as a view component.

A

We also connect this source editor to different dot layers, so in web id it is viewix in snippets. It's apollo in a single file. Later it's straight to api connection, so we have different data layers. Source editor is connected to all of them at the moment. At the same time, we have the content editor.

A

That is a pure view component and the problem. The particular problem we're trying to solve now is how to make these things uh be connected, uh and how can we allow users switch between the two when users, in particular, when users edit a markdown file, because content data is about editing, markdown files? So the scenario is user comes to a markdown file, um edits it and then realizes? Okay, I'm I'm done with the with this uh weird uh weirdness in markdown.

A

I wanted to edit this as a proper document uh user switches to the content data and does uh editing in wizardweak mode as simple as that, and they they have to have the possibility to switch back to code. If that's um that's what they want.

A

So the the end goal is very clear. The question, though, is in this setup, where we have source editor connected to this, the different data layers. How can we make things glued together? So, as obviously the very first uh solution is connect both source, editor and container to the same data layers uh very, uh very clear pattern.

A

uh We all know this. It's established pattern, it's clear to any gitlab engineer, so anybody who will uh be working with this integration will know how to do this.

A

The challenge comes uh in exactly this scenario. We have three different data layers. This means that if we follow the conventional uh view uh path, we will have to create three different integrations. We will have to connect contemplator for in view in the web id. We will have to connect content edited view x in snippets. We will have to connect to apollo and in a single file later. That is not view yet, but of course it will be refactored.

A

We will connect straight to api, but once we refactor probably will be viewix or apollo anyway. At the moment, we have three data layers, so.

A

The another question is: if we extend the set of the editors, for example, we introduce an editor for editing, latex files.

A

This means that the more editors we add, the more integrations we have to to create, and so this conventional view view path might come with integration costs and scalability. It's not big. Let's, let's be honest, it's not big. It's only three data layers, we're talking about at the moment, but in order to have another um another possible path. The second option we are discussing is source. Editor is already has already established connections to all three data layers.

A

So what if we make content editor piggyback these connections and allow source editor orchestrate connection of the content? Communication of the content editor with all those three sources. Three data layers, I'm sorry with all through those three data layers through the already established connections, so the communication between source, editor and content editor will be um just with regular props and events.

A

Obviously, the uh question is: how do we do this and source editor allows us to create the extensions and all this communication between source, editor and content data is suggested to be done in the source. Editor extension.

A

The advantages of this approach is, we are already you. We will be using the established data connections uh that are tested every day at the moment, so uh there is a little uh very little chance for regressions. In this case, the uh the connection will be very well. Scoped means everything all the connections between uh source, editor and content, editor and potentially other editors will have will be managed by one source, editor extension, so this comes with scalability.

A

The big question is this: requires this new unconventional view component bootstrapping at the moment, I'm not sure. Maybe there are three options so how it is done at the moment like in in the in the um scenario that we are discussing so source header will be the view uh component.

A

All the time we will uh I in the beginning, I noticed I I mentioned that it's it can be used as a raw source or source editor or as view component for simplicity, we assume that source editor will always be used as the view component, even in the single file editor, where we'll bootstrap the view application and put source editor as the component there within this source, editor component, we will create the dynamic component that will be orchestrated by this source, editor extension, so the content panel that the the content panel prop that you see here will be supplied by the source, editor extension, and that's uh that's the basic the background of the integration we will get to this particular source, editor extension and how the orchestration happens.

A

But before we proceed, do you have any questions so far.

A

A

No okay cool, then: um how is this uh source editor extension built in in general, so avoiding unnecessary details? What we do in this extension, we set up our component that we set up the component.

A

Using the props and we supply the event listeners that know the context of the source, editor extension, so this is technically the glue between source, editor and content editor.

A

But the way we set up set up this component is we do not bootstrap the new view application in order to avoid bootstrapping the view application within the view application. So what we do is we build the um component, props object so uh or not props. We just built the component component object, which contains which has all we need.

A

We supply the event listeners to this function, so we have the component uh properly set up for communication with our um and to to to uh to make it clear. This component view is the wrapper around content editor. So it's just the glue that um meets the the required events, but otherwise it's unchanged content editor.

A

So we pass on the event listeners and what we do in order to be able to um to set up this component. Is we do this trick with uh passing the data.

A

To this function, setting it to data and then setting the props to actually read the data. So this way we set up the reactivity from the uh source, editor extension down to the component, uh because we will have to pass the content updates after the component is being is, is set up, it's not one-time setup. So that's why we have to have this reactivity here uh and that's pretty much it. So. The the big question is.

A

What technical issues we might have with this, and what are the.

A

First of all, what do you think about about this possible um kind of workaround?

A

Is it worth it or we should just stick to the to the conventional view, methods.

B

um I'm not sure, but I already like this idea, because um I have like three items in my mind: the first one is about maintainability costs for maintainability of this approach. Second runtime I mean in terms of performance costs and switching between these two editors.

B

Instead, during your presentation, um I was thinking about why we can't introduce a special data layer between data sources and all content editors, because it doesn't matter for content editors, which data source or data layer we use so just introducing a new abstraction for them and let them use it.

C

Yeah, that was my idea as well. Why can't we have a shared data layer like sometimes it's done on the back end with graphql right, we can create a double layer that accumulates. Why can't we do the same on the front and having a shared data layer uh to add two constraints that vitaly already voiced testing one of the constraints here and secondly, second is unclear source of changes for the components. If you are setting data from outside the component, it kind of breaks the idea of component isolation and view third migration.

C

uh Whenever we go to view three, the reactivity that you said here on data, I am not sure that is going to work, as you expect same for event,.

B

C

We need to make sure it does, but um this is.

A

This is, this is a very good point and I was um I was thinking about this as well.

A

um um Let me let me uh get back to the shared layer uh in a bit but um to make things clear, so this solution uh uh allows us to first of all when it comes to maintainability, so maintainability is going to be scoped to this extension, because all the integration parts are going to remain exactly as they are today so uh for for the existing uh integrations, there is not nothing gonna be changed, except we are going to use. um Where is it um so? The source editor component is going to be the same.

A

It's just. We are gonna use this um source content. Editor extension, that's the only change uh for uh for for the for the existing view, components uh to to when it comes to maintainability, so maintainability will be uh all um scoped to this to this extension. So it's one place to orchestrate the things about the uh migration, to view three um right that that makes a lot of sense.

A

I'm not sure this. This will uh continue working, but probably we could. We could test this with the with you three um and that that makes a lot of sense, but when it comes to the shared data layer, um do we have any um so natalia you mentioned about graphql?

A

uh Do we do we have examples of such shared data layer? That would connect us to different like to proxy us to different data layers.

C

On a very basic.

A

C

On a very basic level: yes, it's like not a data layer for now, it's just a bridge that connects quick action for confidential, like whenever you set the issue, the.

B

C

With the sidebar follow layer.

B

C

Just create a local query and listener for it, and basically.

B

C

Up the sidebar data kind of flaky approach, because our messages whenever we change anything with quick actions are flaking, but only for this reason.

B

C

We still could think about the shared data layer, because from what I can see, it would solve the issue effectively for whatever approach you're taking you're just trying to like create a hack that would work with multiple data layers. But the issue is with data layers, not with a component composition here.

A

Right um right, that makes.

B

Sense, yeah yeah. I have a really small question. um I think um I didn't get the main idea of a content, um editor extension, so it means there will be two instances.

B

Of content, editor and source editor on the page right.

A

On the page, uh when we switch to uh to the uh to the content- editor, yes like not really, because uh if you take a look at the uh so yeah they technically, it will be so we just use v show for the source, editor part and the component as long as content panel is null. We don't share, don't show the content editor. I can demonstrate it. Actually.

A

I have the working example right here, uh so we are on the snippet, so we are in the source, editor right, so I'm I'm gonna make some changes here. So I want to change, switch to content, editor, I'm switching to wiziwig, and I can.

A

um I can edit this and switch back to code it's there and I can just continue working with wiziwig if I want to and save changes. So that's that's the point, but when it comes to to the actual number of editors, it's uh according to vue devtools, it is only one editor at a time.

A

um Well, where are my view tools? Okay, I have to reload it's like either or at each point of time.

A

That's um that technically what what I was uh thinking when uh when we decide when we uh when we were discussing this, um this solution is first of all, editing. Markdown files in the repository is not um is not like main task. Moreover, editing markdown files, as the in the wysiwyg amount, is it's kind of like niche of a niche. So I wanted to make sure that we have as small footprint as possible for this scenario uh in general on the editing pages.

A

But I I totally uh see the complexity that this brings as well, um so yeah dot layer dotted layer share that layer.

B

Just a side note from what I see it looks like we're really missing a really good visual editor which can handle both modes um in the same time, something like a sk editor or something else. Well,.

A

uh You mean so use uh the content area that can handle the source editing as well. That's that's what you mean. Well, that's that's another way. uh Another way around really. uh The problem is that this means that we won't be able to deliver the uh unified code, editing experience to the users, because, if they get to the even in the multi file, snippet they get to to mark down file and switch to to code mode there.

A

That code, editor source editor, will look different from other source editors that we have on the page, because it will be completely different editor. So that's um that's! That's a bit a bit too far for us, I think, um to to approach it this way, um but yeah, so shared data layer, okay, that makes sense that makes sense.

A

This is uh okay uh in so just to sum it up.

A

You think that the best way would be to go with option number one. The conventional view approach but create the shared data layer to connect for for both editors whenever they need is this. Is this correct.

B

Yeah just follow the good old like uh mbm model and encapsulate or obstruct as much as we can and let the address address to just to display or render the content.

A

I thought I thought this is the in-cap selection and abstraction of as much as we can. It's just probably the abstraction to the wrong direction. I mean.

B

Just move everything to this shade data holder there and we can apply some caching or rendering techniques to improve the overall performance. So but yeah, that's just my opinion. Right.

A

Yeah, okay, that makes sense. uh That's that's not not gonna be fast, but uh that that's probably the most robust solution anyway. Okay, um anybody has any other comments. This is this is super um super interesting because technically we didn't even discuss this shared data layer.

A

So that's that's! It like uh natalya is uh he's in agreement with this phil. What do you think makes sense to me cool that was fast, okay, uh okay, thank you very much. It was super um super in uh interesting to to get your opinion on this, because now we have third option and probably the the option now and uh well, um we'll see how uh how fast we can get to that thing.

A

Thank you very much for jumping on this call. It was very good, but um just to make sure do you think we should uh do like broader discussion of this thing uh with the frontend channel or we just we should be fine. I will post the recording and I might I'll link uh post a link to the frontend channel for for everybody to watch, but do you think we need a broader discussion of this? No, I think I think it's clear.

C

I believe it's up to editor team mostly like, if you feel the need that it should be discussed further on the front end level. Please please just bring it there. If you think that okay, we need to discuss our start option first and then maybe print it again. This is like up to the team, mostly.

A

Yeah right, okay, very well um cool, then I will I'll uh proxy this to to the team, and uh we will. um We will see how fast we can get with the uh shared data layer uh if the team will decide that that's the way to go, but thank you very much for uh expressing your opinions. This is this is very valued and very much appreciated. Thank you for jumping on a short notice.

A

Thanks have a nice day.