GitLab Source Code Group, 7 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Source Editor engineering deep dive

Description

The engineering session on architecture and implementations behind the Source Editor.

A

Okay, we are recording to the cloud apparently hello, everyone we are here for the uh Source editor engineering, deep dive. Today, um where we are go, it's go. It's a continuation of the first session, where we had the uh high level introduction into the uh Source editor. What source editor is what source letter is not uh and some um a vision of this product.

A

uh As of this feature, as we go uh go on with um maintaining it within source code groups context, this session is dedicated to the Deep engineering dive into how this thing is built, how to build new applications with Source header, how to uh to understand what is going on there and how technically applied on the um in the real time real life projects.

A

So I will start with uh with the presentation and for that I probably need to share my screen. I'm going to.

B

um All right, um let's see I, will try to share my screen like this one.

B

A

Very yes, do you see the yeah yeah.

C

Yeah yeah yeah, okay,.

B

Super stuff, um let me just rearrange the things a bit and okay. We.

A

Are we're here so, as I said, engineering deep dive going to be a lot of exciting things, uh but we'll make it even more entertaining by having a dialogue. So what is Source header? We have covered this in the first session right. We have this high level uh introduction that Source Center is the thin layer on top of the Monaco editor.

A

uh Why thing layer? This is by Design. We want to be as close to the Monaco API as possible. uh They once you reach out to the Monaco API documentation. We want. All of this still be valid for Source editor, so ciety builds some additional functionality on top of that, but this is devices. So all of the things in official Monaco documentation should be valid.

A

uh The core because of this, so that we do not mess up with the native Monaco API. The core of the source header should at any point of time, be stable. It should not be broken it preferably. We do not need to spend any time maintaining this core. It's there. It's working, no big deal all of the functionality. All of the new features to the source. Header come from the extensions, so the extensions are the things that are extend, uh Source header and provide us with the new shiny functionality.

A

uh This has been covered in the first session, but what this Source editor is technically, uh let's talk about this, so it's framework agnostic, JavaScript editor. What does framework agnostic mean? It works both in rails and as an example, uh you do see the code snippet now right, yeah, yes, okay, so uh we can use uh Source header in rails. Applications, as this part shows it is used for for the uh blob editing in the web editor. So that's that's how we configure The Source header. This file is pretty old.

A

That's why we have configured Monaco, editor and uh different things like this, but the idea is, we can use it in rails application and we can use it in View application. The View application example is uh Snippets in Snippets we use sourceater as the view component so yeah for for the convenience. We have the view component, which is shared view component uh to implement in view applications.

A

So this picture the the one thing that I admitted when we had the high level discussion on this diagram and this flow or chart flow or whatever, whatever you prefer to call it. So there is one more thing missing between Source header and the extensions instance, so instance is one instance of source editor on the page. Think about instance, as one visual UI element this representing one editor. So, uh for example, if we go to the to edit a snippet, we allow up to 10 blobs to be able to snippet.

A

This means that on that page, we will have 10 different instances. So one instance is one editor frame that you see on the screen when it comes to the web editor. There is just one instance: there uh Source error supports any number of instances. It's very extensible, so you can have any number of instances you want, and every single instance can have their own set of sets of extensions, we'll all be talking about the extensions and the instances of it uh a bit deeper.

A

The thing to understand here is the difference between Global editor, this Source editor at the bottom and the instance. So what is the difference right?

A

We have this screenshot of the snippet edit form with two blobs here, so Global editor versus instance. This is the relationship one to many, so there is only one Global editor on the page, but there are maybe there may be many instances from that Global editor. So what does it give us? It gives us shared edited settings, so we set the global um pass, the global options to the global editor and then all of those options, for example, uh minimap or uh soft trap, or anything like this.

A

Once we pass those uh options to the global editor, any instance we create from that Global editor will inherit all of those options, so this is to share common options. So, on the um on the Snippets, it's a bit different I have to sort of um mention this, because the view component is implemented a bit different. But if we're talking about JavaScript only and like the original architecture, it's one too many one Global letter in many instances there are.

A

There are use cases when you do not need the global options of the global editor in your particular instance. So one off case in this case we can use instance level options. When you create an instance from the global editor, you can say I do want to override those options in the global editor. With these options on the instance level and the options are pretty much interchangeable. So most of the options you pass to the global editor are the same.

A

You can pause on the instance level and you can override those, but if this is not enough for you for some reason, I haven't seen. Use cases like this. That should be okay to create a new Global editor for this set of instances or for this one particular instance, but this is sort of The Last Resort thing now instance, as we, uh the the definition of instance that we have in the source, editor corresponds.

A

If we go back to the official Monaco documentation, as I said, we want to use this, it is related, it is corresponding to the Standalone code, editor and Standalone div editor, depending on the type of the instance we're using so Standalone code. Editor.

A

All of the document documentation should be valid for our instance of regular editor and then Standalone diff editor is the div editor that we can that we can show to the users. The example of the uh diff editor powered by Source header is the Legacy web ID. When you go to commit tab or you go to reviewmergic West, that's where you see the diff editor powered by source source editor.

A

So this is. This is something keep in mind that our instance combines both deep editor and code editor in demonic world.

A

The uh the way we do this so, let's get to some code here so Global editor versus uh versus instance. uh The example is again the uh the way Source header is implemented in the web. Editor, our regular blob editor. So you see this snippet here on the on the right. So the main things here is that we create the root, editor or Global editor or whatever. It is just a constant right, new source header, we import The, Source header and then we just create.

A

This is just a regular class new source header, and then we create the instance with this Global editor create instance. As I said, this file is pretty old. So technically, this should be this dot instance, but I didn't care renaming this uh before for the purpose of this call, it's just. It's called very confusingly in this file, this dot editor, but this is technically instance. Now we create it with root editor dot, create instance. This is the uh the API, the part of the proprietary Source, editor API. This is not part of Monaco API.

A

This is proprietary, Source, editor API and create the instance. If we go to the implementation of this method, this is all it takes to create an instance of source editor.

D

A

D

You can you zoom in a little bit. uh It's just very small, of course,.

B

Yeah perfect, is it better? Is it better.

A

So, um oh actually, I can wait. A second I can.

B

I can do it. uh Yeah I'll just increase the font size completely and I'll. Just zoom.

A

In so uh thanks so create instance, takes some parameters and they're pretty straightforward. So L is the element on which you want to bootstrap The Source editor, uh just like The View application. This element will be replaced. So if you want to preserve some CSS classes, IDs or something like this, you have to keep them on some on the wrapper element, because the element you pass here as the hook for Source editor will be destroyed and a source area will replace it. Just the same way. View application is bootstrapped.

A

Blob path is the is the name of the blob. It's part of the of the blob. uh This part is used to deter to identify the syntax highlighting for this file type based on the extension. So with that being said, you do not necessarily need to have the path.

A

For example, if we're talking about CI um CI editor, it's always gitlab ci.yaml, but technically we do not need to pass the full uh path, we're interested, in extension, only so it's totally valid to pass it as asterisk Dot yaml, and that will be enough for the source Editor to detect that this is the yaml file and we need to apply syntax highlighting for the yaml file.

A

Blob content is our basic content to start Source editor with. Usually it is going to be the empty string if we want to show the empty editor, but if it's editing an existing blob in the repository we pass. The current content of The Blob into the source, editor Globe original content is used only for the diff editor.

A

When we want to create the diff editor with Source header, we pass both blob content and blob original content, so blob original content is the content before changes and blob content is the current state of the document and then Source editor will compare this to and provide you with the with the div Global ID is something that you probably shouldn't think about it's Auto generated here.

A

We had some cases where in in particular in the Legacy web ID, where, uh due to the architecture of the Legacy webri, we had collisions when Monaco, so underlying engine tried to destroy different instances and they they had the same Global ID, which was not really cool. We protected from from happening by General Auto, generating the you ID.

A

But if you want to control this, if, for example, in the future, you want to know and know for sure the instance you're getting to by your ID. This is the place to pass that uid and then access it by this uid and SDF is pretty much self-explanatory, whether we are creating diff uh in diff instance or not, and that's that's it.

A

This is the entry point the instance options. This is the entry points for your custom per instance options if you want to override something from the global editor or you want to extend those uh options on this particular uh instance level. This is the place to to pass the options and that which what it does is. It defines whether we create the diff, editor or simple code editor. It creates the instance.

A

The editor Source editor instance- this is just the hook, for uh this is proprietary gitlab hook, because we have to wait for startup CSS to be bootstrapped before we can sort of after the bootstrap after the startup CSS is booted.

A

We have to relay out uh our editor because uh the CSS coming after startup CSS might change the layout of the page, and hence we have to make sure that sourceater takes the whole Space it has in its parent. So this is just uh for for gitlop thing, and then we create a model.

A

We are going to talk about model a bit later, so modal is just the code representation of the content of your instance, so every content of every instance is going to be represented by modal, based on the language based on the uh content based on the um whether it's a diff or not diff. So different things like this. We do not need to think about this for now really and then just just internal magic.

A

We create we put all the instances in the in the global registry of our Global Editor to to share the code to do some some helper things, but in general you do not need to get into all of these internals. What you have to know is just this create instance, on the global editor. That's it all. This internals are just internals think about it as the Black Box.

A

So getting back to our slides um uh again. This is the picture uh of the main components here right. So the information on the Monaco we get from the official Monaco documentation, information on the source, editor core. We get from our source, header module, which is in our editor, slash, Source, editor.js, pretty straightforward uh instance. We get from sourceater instance, module again a separate editor Source editor instance: dot GS module.

A

It comes with asterisk I'm gonna talk about this in a second The Source header view component again represents the instance level. So when you add a view component you're adding an instance of the source header, you do not add a global editor, it's the instance and then for the extension again. We have a separate extension module.

A

Surprisingly editor Source editor extension, the this one comes with asterisk as well. So what, by what I mean by this asterisks? Is that, as we saw in this create instance method you do not create, you do not create neither extension, nor instance manually explicitly. You do not get to these modules explicitly. They are internal, and uh the only uh consumer of this modules is create. Instance, function on your Global editor, so these are just for the educational purposes.

A

You do not need to use those, they are kind of like treat them as private, private, uh private modules or whatever you prefer to call it. So, let's talk about the application architecture, typical Source, editor application architecture. As we said, as we said, we have the global editor at the top that we create with new uh Source editor um Constructor done. Global editor can have one or many instances uh connected to it. Then every instance is going to have one modal. As I said, this is texture. This is code representation of the editor's content.

A

uh It's very important to understand that every instance at any given point in time will have only one model, so it's possible to attach another model to the instance, but it will replace the previous modal. uh Where is it useful? This is the architecture that is used in the Legacy web ID Legacy ID is built with global editor, just one instance not many instances, one instance and then every tab you open is representing its own module. So what happens is when you click a file?

A

You open the tab, we create a modal and that model replaces the previous model. In the existing instance. We do not create one instance per tab. We create one model per tab, because creating a model is much cheaper than creating an instance, so we just swap the modals within one instance and that's it because you never look at two files side by side at the same time.

A

So there is no danger in reusing the existing instance and just swapping the modals so one model at a time, and then we can have any number of extensions connected to each particular instance. We can even have a one extension. The same extension shared by one or several instances, uh and that's that's going to be fine, because every extension is represented by either class or function and every instance can import that class or function and just uh apply it we're going to talk about how to apply extension a bit later.

A

Do we have any questions about this messy graph here.

D

D

How do we identify an instance, um so you said: there's one: if you open, you can have multiple instances, uh the same model um but.

A

No, no, no wait. A second uh modal is connected to an instance, so it's not possible to share model between instances. It's possible to share extensions between instances, but not modal modal is just one instance. It's like one to one one modal per one instance, and they are connected.

D

A

Okay, that makes sense so and uh if you, if you, uh if you mean how do we identify what instance to install extension for uh then uh or is this um now, let's let me just get up not here. Let me get to two two. Two two.

B

Two two two, two, two two two two two two two two two two a bit here: where is this? Yes, here we go.

A

So when you create an instance, so create instance function Returns the instance, so you can store it in a in a constant in a variable, and then you can use that instance. So to any given point of time, you know exactly what uh what instance you're you're working with, because you can save it in in the constant. If you need multiple instances, you create multiple constants, for example, instant ones instance, two instance three and that's how you can control what instance to install extension for or uninstall.

B

C

Okay, yeah. That's your first answer, your question.

D

uh Yeah I think that's that makes sense. Yeah, okay,.

B

C

Question about the tabs, because you said like once you open a new tab, then it will be same instance, but a new model which will start somewhere in yeah in the local storage network. No.

A

We do not store anything in the local storage. We technically like creating a model is super cheap, so uh for the Legacy web ID. What we do is when you open a new tab. We just discard the old model. It's just like it's, it's very cheap. It's really the code representation of the text, so we just create the new model and uh connect it to the existing instance. If we go back to the previous tab, we do the same.

A

We just discard the model we have now and we create the new model for for the previous tab. uh This.

C

A

Is this is very cheap comparing to creating new instance for the model, because otherwise we would have to, as I said, the connection between instance and modal is one model per instance and one instance per modal. If we would be uh to store to preserve the models, we would have to create uh one instance per Tab, and that operation is a bit more expensive than just creating and discarding models.

C

And, for example, the content, because, when I um have an editor, open and I changed something and, for example, I open a new duplicate, the top, so it's content being saved in a local storage, for example, nope.

A

Nope, no, it's not it's not stored. It's it's the content, which is um uh the uh in the in the Legacy web idea. We did not store anything in the local storage, no content, nothing! It's we uh uh I'm trying to to remember now how how in particular, we we deal with the content changes, but what I remember for sure is that we do not use local storage there and we discard the models.

A

uh The changes you make are stored in the memory while you're in the uh in the web ID. So when we go back to the previous tab, we have that in the memory the content and we just create a new the new model with that value in in the memory.

C

Okay, cool. Thank you. Yeah.

E

I'm, guessing that this is the system that we have in Snippets, where we have one Global, editor and multiple instances on the page is that it.

A

um The the problem is that, uh as I mentioned, this is a bit different for the view component and Snippets do use view, components, The, View components, The, View component, uh technically a base, the the idea of one single Global editor so view component. If we check it, um oh it's um now, it's it's not somewhere here opened so view component for Source header creates Global editor for every instance.

A

Whenever you open the component on the page, it internally will create the global uh Global editor and can create instance for this um for This Global editor internally in the component.

E

Okay, have you ever gotten like performance concerns, like really large Snippets? Have you ever found any bottlenecks in the architecture? Obviously,.

A

But no not in the architecture like as I said uh with the Snippets I would I would like the Snippets to follow the uh the pattern of global one Global editor and then uh creating one instance per per blob.

A

Okay, um the uh the performance uh concerns in the Snippets were related not to the uh to the architecture but to the fact of low to the to the matter of loading large file in in Monaco, but since uh Monaco loads file, loads content in in Chunk in you see only like I, don't know, depending on the height of the other it blow. It creates only the entries for the visible lines.

A

uh Then it's it's pretty pretty negligible, uh like even load really large files are loaded really fast there, because this is this is and I I'm sure Jacques experienced this with um with the blob viewer like the the problem with loading. Large files is not related to actually uh adding them in the code, for example, but due to the fact of rendering so many and uh HTML entries that's the problem. So a.

D

E

A

E

A

Source editor fights with this by uh creating uh only like five lines: 50 or 50 lines that are which are visible at the moment and then just reusing them once you scroll it guts, reuse, the those 50 lines, so it never renders more than 50 lines.

E

Classic virtual scrolling yeah yeah all right that that satisfies my curiosity. Okay, thanks.

A

Great uh thanks for the question, so uh this is this: is the architecture uh of the typical Global, a typical Source, later architecture.

A

uh So let's talk about the extension because that's where the the um the power of source header comes from right, so uh extension under the hood um in the source code in the in the source code, not the group but source code uh of gitlab product. We have the this uh file, which is called example, underscore Source, underscore X editor underscore extension, which actually provides you with a boilerplate for any extension you you need to create. It is very well documented. It has all the uh all. The things explained why you need those.

A

When do you want to use those? So whenever you create a new extension, you just take this as the boilerplate and adjust it for your needs for the needs of your application. But, let's briefly go through the main points of the extension. The uh there are only a few things that the extension is introducing. So, first of all, every extension has to have extension name. This is the static getter. You can see it on the right here.

A

uh In this case it returns. My fancy extension- we will be talking. We will talk about uh why this is important um a bit later, but every extension should have this. If extension doesn't have this getter the extension and you try to use that extension, it will throw in the console. So this is this is important, then, on setup, this is the Callback which you will probably use most of the times on setup is this is one time setup which sets up Monaco in most cases before your UH extension is available to the instance.

A

This is the place to to add actions in Monaco to add keystroke listeners, so everything related to Monaco to communication with Monaco setting up Monaco is going into the onsetup Callback, because on in this callback your instance still doesn't have access to the uh public API of your extension.

A

When this happens, uh the so the the next um the next um callback or uh life cycle moment of the extension is unused. This is exactly when you install extension for your instance and within this callback. All of the public API methods of your extension will be available to your instance.

A

On setup is one time setup you never get back to this on use is called every time your extension is installed because it's also possible to uninstall extension and then install it back. So this is the moment. This is the Callback that is used every time you install the extension.

A

There is the uh on before unused pullback. This is the Callback. When you want to uninstall uh an extension on before unused will be called while your public, your extensions public API, is still available. It is still here, so this is the Callback to run some time critical cleanup, while your extension is still full here. You want to do some cleanup, which is time critical, like remove some visual elements on the screen, or do something uh that needs to be done now and then on unused.

A

This is the Callback which is called when your extension is uninstalled, so your instance doesn't have access to your extensions API anymore, but this is a good place to do some asynchronous uh cleanup like unregister some some keystrokes or do something which is not time critical, but still needs to be done. So this is this. Separation is done with performance in mind so that we do not create a lot of the activity when it's uninstalling uh extension in a blocking manner uh blocking the main thread.

A

If you want to do if your operations or your plane up is not time sensitive. Please do this in this on unused callback. It will be done and do it in async manner if it doesn't require to be done right now, and that provides this is the Callback that defines your the public API of your extension. This is where you return. Where you return properties, you return uh functions, which you want your instance to be extended with your instance.

A

Won't have access to Onset up on use on this callbacks, but everything that is returned from the provides callback is going to define the public API of the extension and will extend your instance. So again, if we take a look on the life cycle of the extension, it all starts with on setup than its own use.

A

When you install your extension on before and use when you it's before, you uninstall the extension and then when you're done uninstalling the extension- uh this is the sort of the final point and between these two points on on use and on before unused. This is where your extensions API is available, which you define in provides and return uh in. This provides callback.

A

uh Your extensions API is not available outside of this point again. The link to the uh to the example Source header extension- uh if you, if we take a look at here at this just briefly, so uh we get this static getter, we have on setup, it does have instance and setup options defined, as the parameters here instance is passed passed here automatically in all of the callbacks instance. You don't need to explicitly pass it uh on. It will be there for your needs.

A

You don't need to pass anything because you do not really call this uh callback functions manually and that provides it just returns, a real object with the methods or properties that you want to extend your instance with.

A

There are different examples here uh with properties functions and how to use this. So this is a good source of information about how to write the extension now. Yes, this is the example. We yeah, let's take a look at the real time, real life extension. This is the simplest extension we have. uh Apparently, this is the CI schema extension. This is used to load. The um CI schema for pipeline editor when you're working with gitlab CI yaml file and all it does. As you can see, this is a very minimalistic extension.

A

It has static getter, as I said, if you don't have one, your extension will throw in the console and it doesn't even have on setup on you on use on unused because it doesn't need those all it does is provide the public API in form of register. Ci schema method, this method, once this extension, is installed for an for an instance.

A

This method will be available for your instance and what all it does it fetches the schema and applies it for the uh for the actual modal of our instance, because that's the textual representation of our content. This is very minimalistic minimalistic and it. This kind of this shows that extensions can be as complex as you want or as simple as you want.

A

So we have two sort of polarized extensions, so CI schema extension is the minimalistic one and then we have technically the whole Legacy web IDE is yet another extension, so all of the functionality related to editing files in the legacy webad is just is just another extension. If you go to editor extensions, there will be Source editor web ID extension, and this one is not minimalistic, but still pretty. Okay provide again, has public API and provides it has on you on use on setup.

A

So it's not that dramatically complex either, but it it definitely has much more than just the schema um schema extension foreign.

A

So how do we use the extensions? How how do we I'm telling we install install extension? How do we install by simple use of dot use method? Instance, dot use method, so this is something that we have to talk about now. How do we install thing installing an extension? So, let's assume we have instance- and we have an extension that we want to install for the for this instance. As I said, we do, we rely on the dot use method. Again. This is the proprietary method of source header.

A

This is not Monaco API, there's a source, editor API, so you won't find a documentation on use in Monaco documentation, so we do instance dot use and then the um the signature of the object that we passed there is. We have the definition and we have the setup options. Two things that we pass as as the different as the descriptor of the extension definition is, the extension function or class extensions can be written as functions or classes. Whatever way you prefer.

A

So this is where you pass your extension. You import your extension in your module and then you pass that default return of your import. As definition of the extension, then, where is the setup you options used? It is passed to your own setup as the second argument, so that you have a way of fine-tuning your extension. The same extension on different might might behave different in different instances. So this is the way where you can pass the setup options and, uh depending on the options passed there, your extension might behave a bit differently.

A

So these are the two things. The only two things you pass to the use function in order to install the extension. uh Do we have any questions about this.

D

um You might I've got a a question about uninstalling, but it might be something that is still going to cover yeah. We.

A

Yeah we're gonna get.

D

A

uh So what happens when we do sort of we have this dot use right, but what happens when we actually um call this method on our instance? So again we have an extension. We have our instance and that we call instance.use for for this extension, we pass the object with definition, extension and let's say we do not accept any setup options. We don't need to to set up this extension in the simplest possible form. Instance. Use will be just I, think we have it in the yeah. So you see here use also accepts the array.

A

This is this: is the uh edit blob, the one we have in the web editor, so editor instance, dot use, accepts the array of different extensions and the setup options might be not needed. The only thing that is required is definition so that we, so that instance would know where to pull in the extension definition from that's the only required thing. So there are three extensions passed here: none of those needs any setup options.

A

So what happens when we call this use uh and in the very first iterations of source header, we had a lot of problems with this.

A

We, what we tried to do was to really extend instance, so make instance uh provide all of those methods from the extensions, but what uh we ended up with was actually that we were mutating the instance, and this led to the situation where we could not really unuse extensions, because if you mutate the instance, you don't have you lose the information of what method comes from where or you you can. You have to create a really complex registry of these dependencies so and mutating instance is really bad idea.

A

So uh we had to come back to the Whiteboard so to speak and rethink the architecture of how we work with extensions and what we came up with was the proxy pattern architecture. What this means is we go the other way around instead of mutating instance and letting instance sort of swallow, the extension. What we do is extension wraps itself around the instance using a proxy pattern.

A

So whenever we create We call instance.use, we are getting a proxy proxy which manages uh relationship between instance and the extension.

A

So whenever we um we call some function that we know is coming from the extension, so we do instance dot extension function. This is not the function from the instance. This is function. Coming from the extension, what happens is so? Yes, as I said, we return the process so technically, when every time you, you call instance dot something you're calling a proxy. So when you create an instance, you technically get a proxy.

A

You don't get the raw instance, so raw instance is protected. It's going to be immutable, so instance, extension function. What happens? Is our proxy gets into the in into itself and tries to figure out whether this function name belongs to the core instance, which is immutable which is intact? If it's not, then it tries to figure out what extension this function is belonging to, and then it returns this function from our extension, not from the instance.

A

This leads to the situation where, for example, um if we need to install the second extension right, as we saw here, we uh here, we actually have three different extensions. So how does this work in real life? We already have one extension. What happens with the second extension?

A

We do instance, dot use second extension and it wraps itself around the wrapper. So we create proxy on top of proxy, and this is totally valid proxy pattern.

A

This. This is something that I call the stacking Dole architecture, so we have instance, which is wrapped, with extension, wrapped with extension, wrapped with extension, and there is no limit to this- uh and here we come to the unused uh or uninstallation of the extension Point. How does this work? So? Let's assume we have this um this structure we have. We have instance, we applied one extension. Then we applied the second extension, and now we want to unuse the very first extension that has been applied.

A

uh It has been installed, not the last one, but the the one in the middle. What happens here is that our proxy keeps track of.

A

uh There are two Registries in our uh in in in the standard instance, um instance instance, so to speak, uh so not the proxy itself, but the um the instance. So if we go here, for example, yes, when we create the instance, this editor is returning is getting the proxy, but it also has access to two Registries. uh One registry is keeping the names of the extensions.

A

Why so? Because if we UNS uninstall an extension and then we want to or not not the names but the definitions, so if we uninstall one extension and then we want to install it again, we do not pull it back from uh from the code uh from from the network again, what we do is just we reach out to our registry. Do we have this extension registered already Yes? We had it it's gone now, but we have the diff. We still have the definition, so we just use the definition to speed up the process.

A

We always uh keep the access to to uninstalled extensions definitions and then the second registry keeps track of all the props and methods added by each individual extension. It has technically the the uh the map where we have the the relation between extension name and that's why the static getter for the extension is important. That's going to be the key, defining your extension in the registry, so the relationship between that key, so the name of your extension and all the methods and props provided by this extension.

A

So when we unuse we can get to this uh to this registry and know exactly what props and methods belong to this extension, we are going to unused now so technically, what we do is we disassemble this proxy that we have, and we know for sure what uh methods and properties come with each particular extension.

A

We get rid of all the methods and properties related to that extension. uh We are unusing and then we assemble the proxy back and return it back to the user again. This is uh this is how it works um under the hood. This uninstall unused mechanism is really it's quite robust, and this allows us to technically do things like when we are in the web editor and we are editing a file. Let's say we start with.

A

We are creating a new file. There is no path, so we know we have no idea what syntax is highlighting to apply what extensions to apply. We know nothing. So user code goes in and type names it test.md.

A

Okay, we know because we have the event listener. This is beyond the um uh the scope of source header, but the the user of sourceter notifies The, Source header. Okay, we've got the the name for the file now Source editor knows that we are working with markdown file, it goes and pulls in the markdown extension, because we have the MD file and applies it so automatically by just typing at the path for the file user gets the updated editor. This is the gradual, uh complete sort of gradual, um Improvement or gradual complication of the interface.

A

We start very simple and then based on the user action. We do enrich the experience. So user starts working with this and then they suddenly realize. Oh I. Don't really need this to be the markdown file, so they go back to the file name field. They remove MD and name it dot. Txt Again, The Listener tells Source header. Well, we are dealing with the txt file now, what source editor does it goes to the Registries and on uses the markdown markdown extension, because it has no value for the txt files.

A

So it removes this and again returns this proxy assembles if there were some other extensions and Returns the proxy without markdown extension, robust solution- and we had had put back in the editor, we put a lot of thoughts into this architecture and that's pretty much. What do we have to talk about in this technical uh Deep dive? We have five minutes.

A

um uh It took a bit uh longer than I anticipated, but do you have any questions? No.

D

um I've got one about the extensions um gun, extensions communicate with one another.

A

Yes, that's a very good question, the the only thing and actually we have. We have this example here, so the order of the order. You apply your extensions in matters so, as we saw on um on this on this example, so Technically when you apply extension one.

A

You know nothing about extension, 2 right, but then, when you install extension, two you'd know everything about extension, one so the order you apply extension in uh matters, and since we are when you use in this particular case, when you use use extension, two, you have access to everything that this proxy returns, both to the core instance methods and to the methods and properties provided by the extension. So you do know everything about the extension and you can call the methods and properties of that extension.

A

The first extension knows nothing about the second one, but it can do some checks because in the in the overall proxy, uh if you after you used both extensions, you can you have access to to the methods and properties of both extensions. Let me show this on an on the example um uh yeah. So in this particular uh example, we are dealing with the web address, so we first we install the toolbar extension and then we have the um uh Source editor base extension.

A

So there is the base extension uh which in this particular case, let's check this out. um Let's go to the extensions.

A

So if we go to the toolbar extension, which is the first extension being applied and go to the provides so the public API it Returns, the toolbar object with different methods. Get item get all items. Add items remove items.

A

If we go to this second extension, Source header extension, which is the base Source editor extension base.

A

And go to the on setup, you'll notice that we, this extension, tries to install a button, a button for soft wrap so whether to to to so toggling the soft wrap um of the content.

A

If we don't have the toolbar extension installed, then we don't have access to the uh to to all the two totally methods within the toolbar right. So we have to double check this.

A

If the install the toolbar extension is installed, then we have, then we can go on with setup toolbar extension, and then we know for sure that we have this instance.toolbar dot, add items method which is defined in the toolbar extension toolbar, add items, so extensions can check the uh the methods available from other extensions and then they can hold those methods, because technically at any given point of time, every extension is dealing with the proxy of the instance, which knows everything about the already installed extensions.

A

So in this case we can build extensions which depend on methods from other extensions, but not necessarily um uh digital dependence. So in this case the bias extension can totally be used without that button. Without that soft trap button, because that button is used only for um for the um I, don't know for for markdown, I think or for some textual thing, but if the toolbar extension is not available, this is not the reason to not install the base extension because it provides.

A

It still provides some public API for highlighting, for example, and highlight lines and remove highlights this is when you uh link to a particular line in the editor.

A

This functionality is still valuable, even without the toolbar, even without a button. But if the toolbar is available, we extend we. We extend this functionality and reach this functionality with um with new button in on the. In the context of this extension, it was pretty chaotic explanation. I realized this, so I will be happy to jump on another call and give some more explanations, but in general, does this somehow answer the question yeah.

D

It does thank you very much. Okay,.

A

Cool, so we are, we are a time now I'm I'm, happy to to to continue the discussion if you want to, if you have more questions now, uh but if you, if you need to drop off, that's that's totally fine. Well,.

C

Yeah I'm, not in a hurry and uh okay I have uh yeah. First of all, thank you. Both very nice, comprehensive presentation and I really think it will help um to understand would help to understand how the editor works and will help to work in it and yeah. My question is like, as a user I actually would like to see uh the feature that, when I do edit um I don't know to create a new file and do something in the editor or when I edit an existing file.

C

That I am um uh like when I accidentally, like close my tab or, if I refresh page, for some reason that my contents are saved and I think this functionality is not available now, because I checked and yeah. So my question is: what is the reason why it is not there? Is it hard to implement, or nobody was thinking about it? This.

A

Is a very good question and the uh so from the question: I assume you mean the web editor, so the editor for the repository yes and the reason why this, because uh putting the content storing the content in the local storage, just like we do for uh for.

C

Comments or descriptions.

A

It's a super trivial thing right: it's not done for the web editor in particular on purpose. The reason being we are talking about the gits commit workflow. So if you make changes and then you abandon this tab, the chain, the the changes are stored in the local storage, then at some point you come back to this file start edit this and reload those changes from the local storage, because we do not have any way to present the changes automatically to the user. So user has to explicitly click preview changes. In order to see the changes.

A

There is a very high danger of users accidentally committing the things that they did not mean to commit, because simply because they didn't notice this- that the content has been updated with the content from local storage and with the actively developed prod projects like gitlab, for example, if you uh work with an actively developed file- and you do some changes, but you do not commit, they are stored in the local storage. But there are many many different changes in this file during the day and then the next day you come to edit this file.

A

Again, we load the uh yesterday's copy of this file and then you accidentally overwrite all of the changes that have been made during this day because you don't see the changes. This is the user experience problem uh which we have to deal with either presenting the div before you actually click commit so that users are notified about the changes uh or, as we do now, as the simple most boring solution. We just don't support this. uh uh This feature.

A

That's that's pretty much it, but we can do this for the Snippets, for example, it's just the value is really low. There. I guess.

C

Yeah but, for example, uh uh like um just a normal editor like this code or idea, yeah, it's different, but in this case, if you close the top right, your changes are still there and even if remote has changed, you still have your changes so because.

A

You because you you have to you, go through the through the workflow, where you kind of you have the way to to preview changes properly in vs code, for example, yeah.

B

C

You personally do you think that which is still um valuable enough to work on I.

A

Would love this feature? I would love this to be to be available for uh for the soil, for the for the web? Editor the but as I said technically, there is like there's one hour: okay right to introduce the local storage support, the uex discussion about possible complications and outcomes of this decision might be counted in months, because we have to provide users with a proper workflow where they are notified about the changes or uh about the fact that they are actually working with the uh with the restored uh version.

A

I have um I have had the POC, where we showed the notification after the oh I. Think it's the part of that uh POC for consolidation, consolidating uh sources and content editor for webi or for web editor, but uh the the idea is that if we detect that there is the content stored in local storage, we replace it replace the content of the file.

A

With with that content and show the The Flash to the user, that we have restored this content from the local storage and then we would provide two buttons uh preview changes so that you can. You can compare the changes you have got from the local storage to the actual file now or another button, just reset this and load the content from the server. So there are different things to approach this. But again this involves a lot of user experience. uh Discussions.

C

Okay, cool sounds good, sounds great. Thank you. You're awesome.

A

You're welcome great thanks for the question.

B

C

A

E

Okay, so this these extensions you're talking about that's how you we could achieve adding the simplest highlighting for the code ownership right exactly.

A

E

A

Just we just detect, detect the file type. We detect that it's the code owner. What does this mean? We just pull in the code owner's extension with syntax, highlighting and all the features that we want like put new buttons to the toolbar.

A

It's like this guy is the limit here.

E

Oh so, basically, what you're saying like the code owner's extension could detect the toolbar extension and then add tools there.

B

Right exactly cute thanks.

A

For the question, um it's um technically uh due to some to sum it up a bit so pretty much any new extension again, we do not change the source code editor or a source editor uh code. Oh now, I'm I'm, going to confuse all those things now: source code, Source header, editor code code, editor. So uh all of the functionality uh comes from the extensions new functions, new features. Everything comes from the extensions if there is no available extension for this file type.

A

Yet we just create a new extension, but we never mess up with the source Setter core that one should be stable and intact.

A

So in case of code owners, we create the new code owners extension and then we we are free to use anything and Implement anything we want. This allows us to have a very well scoped um scoped code, very easy to test very easy to catch issues because they are scoped uh and in general, this um I don't know. I I, really like the the current architecture of the of the source, header and extensions in particular how these two things work together.

A

Yes, um so I think this. This was the last question, at least in the in the document. So if you have any any other questions, if you've find some something that you uh you're wondering about in the code or you have some some idea, please do reach out to me, or let's just discuss uh transparently in the group channel, so that everybody could participate and everybody could throw ideas.

A

That would be that'd, be super great to continue the discussion and to uh to sort of to get outside of this uh knowledge, Silo that we have now where this knowledge is sort of on me. But we want to spread this uh among the group members. So if you would like to to chat about this, let's do this transparently in the issue in on in the slack Channel.

C

A

Just send me an invitation and then we will convert our conversation into the transparent document.

C

Great cool, thank you very much. Thank.

A

You thank you very much for attending.

C

A

Hope, thank you and I hope that our Cloud streaming will work out after all, um I'm, so not sure. No we'll see.

B

A

Thanks a lot have a great day, and uh uh hopefully the recording will reach the the slide Channel.

C

A