GitLab Create Editor Group, 3 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Editor Lite Deep Dive. 2020-09-03

Description

Deep Dive into Editor Lite. What's that, how to use it, how to extend and what to expect.

A

Okay, nice, uh yes, okay, I think I see all of the people who were supposed to join and um I would like to thank you all for joining this um deep dive and uh this deep dive is going to be dedicated to the uh thing that is called editor light that that brings a lot of confusion to the team, and this is this talk is aimed at answering the questions. First of all, what is the editing story in the product in general?

A

What place in this story takes the editor light? What is editor light? How to use editor light, uh how to extend editor light and what is the future of editor light? So uh there are a lot of things to cover. So, uh let's just begin, let me just uh apparently I need to share my screen now to show the.

B

A

So do you do? Do you see the presentation now cool so editor light deep dive, um I'm dennis uh the reason why I want to talk to you about ideal light. Is that I'm part of create editor group that actually has the like? The whole purpose of this group is to work with the editing experience in the product.

A

So, let's, let's start before talking about editor light. Let's talk about the editor's mass we have in the product, so it's going to be about history, speculations and confusions that we have in the product at the moment.

A

Apparently all of you have heard things like gravity. Maybe somebody uses single file. Editor ace monaco web id lite. So um what is this about?

A

First of all, let's set the basis and figure out what is actually the editing story in the product, so, first of all, uh gitlab used to have the single file editor that was based on the ace editor. This is the third party editor and not developed by gitlab, but the third party editor- and we have the single file editor based on this external edit.

A

Then the web id has been developed and it was based on a little different editor at the bottom called monica right, so ace and monaco two different things diverging since 13.1.

A

If I don't mistaken this, we at editor do the attempt of uh combining these things and move all of the editing experience on exactly the same basis of monaco editor. That is the heart of the vs code, editor that probably most of you are using so since 13.1 single file later and web id look. The difference between these two is obviously that single file letter is for single file. Editing and web id is for like whole project editing and merge, requests, editing and many many more.

A

So the point is we want to unify the editing experience. We move everything to this to one core to monaco, but the story doesn't end there right. So what is editor live because I did a lot. There is no editor light in this picture. Yet so what is editor light? It's again, monaco based editor. It's very! It's extremely slim wrapper around monaco. It's only 340, bytes gzipped wrapper round around monaco.

A

It's very extensible and it's main usage uh single file editing, but this is for now we will be talking about the future of federal light and things, but for now the per the purpose of editor light is single file, editing experience.

A

So the point is why I put for now in that sentence, because technically right now editor light. There is one more request that is in the um in the train at the moment, so it's going to be merged today, where we start supporting multiple instances of editor light on the same page. So technically edit. The light supports multiple instances and then the question arises. So we have single file letter for single file experience. We.

C

A

Web id for multi-file, snippet, multi-file, editing experience an editor light is something between in between single file editor web id, and I already know what you're asking yourself like seriously like. We were talking about the editor's mask and we are introducing the new editor now.

A

No, this is what we used to have, but this is where we are at the moment technically edit a light in the course of this huge uh epic called replace ace with editor light, also known as the great ace eclipse we are replacing all the instances of single file editor based on ace, with the editor light, the only bit that is missing that is still using ace is this link that you can find in the slides, and this is about replacing ace with any light for ci linting editor.

A

This is the only place where we still have ace. After that uh we are going to get to this picture. Two editors editor light and web id, both of which are based on the same monocle core.

A

This is the attempt of unifying the editing experience and providing solidified basis for anything related to editing in the product. uh Will editor lite actually replace web id? Will web 80 replace editor light on some point?

A

This is still arguable, but uh if you um saw the recent blog post on our unfiltered gitlab blog, the recent ux research that our ex departments made states that technically we clearly have you clear usage for webide and clear usage for editor line or single file editor, so these two things will leave together for a pretty long period of time.

A

What can change, though, is that at some point, editor light will replace the custom written wrappers of web ide, and then we will have edible light and web id will be the extension of the uh editor light at some point, but there are. This is very far in the future. This is just the speculation at the moment, but this will be possible since we support multi multi-file instances in editor light now and both editor light and web id use the same basis.

A

Monaco. uh Do we have any questions about this editor's mass.

D

Yes, no, I was just wondering dennis around the you said that the wrapper is 380 by it's jesus. What's the.

A

Size of monaco.

D

For comparison, uh what the size.

A

Yeah, you know where to ask man, so monaco is pretty pretty happy itself right, but the thing is I I uh take take this with a pinch of salt because I didn't, I don't have exact numbers. I don't think monaco is any bigger than a's used to be uh at the same, so we technically replace ace with monaco and it doesn't really affect the the overall bundle size. But what is cool is that monaco uh is now in a separate um chunk in our webpack settings in our webpack bundle.

A

It is technically cacheable and reused uh for between web id and single file and editor light. So uh I don't have exact number, but clearly the picture is much better with uh monaco in both instances, rather than with ace and monaco. The number that I mentioned, 340 bytes gzip, is exactly the core of editor light. So, yes, there is mo.

A

There is monaco, but we cannot leave without money right and then what we write on top of that the core of adidas light is only 340 bytes gizmt in in gitlab world, where we have 10 times compression with 10 with index down.

A

This is, um this is the short story. um Is there? Are there any questions, and I'm not even sure I answered too much your question.

D

Thanks dennis yeah.

A

Okay, so let's, let's, let's move on so how does a little light work, so we figured out okay, edit, a light uh is technically the new single file editor and a bit more than that. How does it work? Let's talk about the uh internal architecture of edulite.

A

The code will say much more. I think I need to share the whole screen the whole desktop. Now. Excuse me so yes, so, let's take a look at.

A

A

Okay, I didn't check the the chat but seems like there is nothing really.

A

Question related okay, cool uh edit, a light.

A

Since we um right I'm, I I need to make sure that we are yes uh right now, I'm on my branch that is about to be merged uh into master, but I will show you the current state of the uh of the in your life as it as it's going to be by the end of today.

A

So this is editor editor light uh 101 line, including the uh closing one. uh All it does is, let's close these things right.

A

It has very, very simple api, technically the purpose of edit the light to be as close to the basis to mod to the standard monaco as possible, so that we could uh piggyback the documentation of monaco and just read the the monaco's documentation in order to understand how editable light works. So, technically, all the api you find for modico will still work in editor light with some very basic additions.

A

When we create the the instance of the editor light or let's, let's, let's talk about how we get to the instance editor light uh in editor light when you initiate initialize editor light, you create the global editor.

A

It is the editor that can have multiple instances.

A

You set up the global editor with some options, for example, to render the mini map when you navigate to long files or not how to treat the um line endings, how to like whether to break lines uh or not, and so on. You can set up this on the global level on the global editor on your page, and then you can create instances of this editor.

A

Those instances can be set up with their own options. They will inherit all the global options from the global editor they will be. They have the possibility of being extended with local local options. If we take a look at this method, create instance, this is this: is the matter method that you are going to use anytime? You want to uh set up the editor for your page, uh you. We can see this instance options as the last parameter here.

A

This is exactly where we can pass instance options, but where do we get those options? As I said, we just go to monaco documentation.

A

And we actually, we go to the editor options, and here we find all possible options to set up both global editor and each particular instance. We can even like set form family. We can create global global editor and then, for example, five editors on the page, five instances think about every um every editor you see on the page as a separate instance, not separate editor but separate instance of the same editor, and you can you can go nuts and say: okay, I want to use different font families for all these five instances.

A

Nothing really except, of course, common sense. Nothing stops you from doing that.

A

Tons of settings like pixel ratio, mouse will scroll, scroll sensitivity, mind-blowing set of options, and the cool thing is that we do not need to write those our selves, we just piggyback what is already in monaco, so global editor and any number of instances on the page. Where can we see this in action right now? Nowhere the uh meaning of this um of this flexibility, so that we have just one global uh editor and several instances will be possible for implementation of multi-file snippets.

A

uh I can show you the example.

A

At the moment, we'll get to this example in a bit, but this is a sneak preview of what is coming to gitlab pretty soon right. Now, it's behind the feature flag, actually behind two or three feature flags, uh so.

A

When we load the snippets, editing, page or creation page, we are loading we are creating one editor, but and in this particular case, by default we create one editor one instance of this editor. Let's take a look at the at the code.

A

It's going to be.

B

Visibility, it.

B

I think it's somewhere.

A

Here our blue edit, not bob.

B

A

So uh here we go, we we abstract the uh things for snippets, since we we use it in several places. Here is the bare minimum of how you initialize the editor light on your page, so we create new editor. This is our header and we pass the global options to the editor when we are done with that. We create the instance on this editor, at least one instance.

A

This is by default. This is what we have seen for snippets just now. Here we can pass more local options, local to the instance, but this is what it's about.

A

Yeah so in this particular case we initialize the editor light. We pass some the element on which we.

A

On which to initialize the editor, so you can have uh we we don't record hard code, any id or class or anything you can specify. What dom element should get the.

D

A

So, no matter, what's the id or something you specify the blob path, this is used for uh to use to figure out the syntax, highlighting because, based on the extension of that or another blob, we are loading different, uh different syntax, highlighting let's take a look at this in in action. For example, if I do this.

A

So this is clearly the markup that I'm writing right, but if I have the txt extension, nothing happens. It just looks like text. If I change it to md, we get the highlight syntax, highlighting if I write host a equals foo that is clearly javascript.

A

Nothing really happens for markdown. This makes no sense, but if we change to javascript.

A

We get the javascript syntax highlighting this is what the oops. This is, what the blob path parameter about this is. This is the bit of information from which uh editor can get information about syntax, highlight and then blob content, if you're, for example, editing an existing snippet existing blob. You want that content to be loaded into the editor right away right. If it's the new snippet like in this particular case, we we have, then nothing will be loaded here.

A

Obviously, blob global id is a quite specific thing for the uh for the snippets, so you don't really need to bother about this.

A

This is about one instance, but.

A

We, as I said we are in 13.5 or 13.6. We are going to launch the multi-file snippets so when one snippet can contain several files- and in this particular case in this case, how it's going to work is we have one global editor, but on the same editor with the same options, we create two instances uh of this editor. Why? So?

A

The reason is that we can have different uh extensions, for example. This is the mark. This is going to be javascript. This is going to be the markdown. We want these instances to behave different based on the uh on the extension. We want this instances to be to have separate models. We will talk about the concept of a model a bit uh later behind every instance. There is the modal representing this. um uh This editor this instance I'm sorry, so we don't want these things to to collide, so every global instance can have multiple.

A

Every global editor can have multiple instances underneath this is uh for now. This is the only place in um in gitlab that is going to use this multi-uh instances, architecture and multi-instances capabilities very light, and this is exactly the capability that might at some point sneak into web ide to replace the current core. We have web id, and this is pretty much it. This is all you need to do to create the very basic uh instance of editor light. You don't need anything else.

A

You, as I said you can play with the options, but this is as simple as that.

A

Let's get back to this one, you create new editor and then you create instance on this editor. That's pretty much. It.

A

To to wrap this part up a bit again, we have very small core of edited light that deals with only pretty much two things: uh crea constructing the editor, the global one and creating the instances.

A

Everything else like all the magic technically happens on the instance level, but we will get to this in a bit- and this is this is as simple as that. If we get back to the editor light, the create instance function itself is pretty pretty simple as well again as much as we can. We piggyback the standard monaco setup standard monaco api to just to provide this uh possibility, with possibility to use monaco api documentation as a little light api documentation.

A

Now this is uh about the oops. This is about the internal architecture. Do you have any questions at this moment.

C

I have one quick question for you, um so the one thing I'm not totally certain about is is the idea that every time we use this, we are going to be instantiating it this way, or is it going to have a view wrapper where you essentially just like, grab the component and then it and pass it props, and it does that or is the idea that we'll keep instantiating it like this.

A

This is a very, very good question and I have the answer for that. That is the issue right.

A

That is the issue that is assigned for 13.5. That says, wrap editor live into a view component, but keep in mind the reason. So technically we will have the view component for editor light and we will be able to say just edit a light then pass parameters to it uh all the dom dom element and be done with that. Nothing, no fancy thing. The reason we will still need to have it in vanilla javascript is that editor light is framework.

A

Agnostic, editor light can be used both in view applications in haml applications in like radiance applications. It can be used anywhere. So, in order to not lock us down to just eu implementations, we will keep using uh plain javascript, but for obviously for the convenience of uh other groups, we will wrap it into a view component.

A

There are some complexities related to this when it comes to extensibility of.

E

A

Light, but this is what we are going to do to be talking about a bit later, because it's not very easy to um considering the dom just one dom element to say that that yeah, okay, I need to load 10 extensions for this instance of the editor.

A

uh It's going to be a bit tricky, but again I have the plan for that and we'll be we'll talk about this later. Does it answer your question? Sorry.

C

Yes, it does thank you so much sorry to jump so far ahead. I see I can.

A

C

A

That's that's very that's very, uh very good question actually, because, obviously uh we are aware uh that we, if we want as wide adoption of editor light as possible- and uh I personally do want that- uh we need to make it convenient and easy for people to use it. So this is definitely in the pipeline to to make uh to make things easier.

E

A

E

I had a question and I'm sorry if you answered this on an earlier slide, but what is the elevator pitch of what the purpose of this is? Is it just a a simpler api around monaco or what is it giving.

A

E

This is, this is very.

A

Good question, like um I tried to uh to depict this in this fancy: first slides where, like all the all the bells and whistles, but uh I'm I'm aware that I didn't uh didn't, really communicate this clearly so the um for uh many years we had both. We have ace and monaco as the core edit editors, core editing experience right, ace was used for single file, editing monocle for web id, the purp.

A

The idea we had in the editor group was to unify the editing, experience and move everything to one basis to monaco, so replacing aids and using monaco all over. But while doing that, we said okay like using monaco directly, would be a bit too uh too fragile for such a big project. So we need some abstraction, and this is where editor light sort of uh was born. So editable light is the convenience abstraction around uh monaco for using in gitlab and technically anywhere you want.

A

So the idea was to unify the editing experience moving everything editor related to one uh to one track.

E

Okay, that makes sense so think of it as like, a proxy pattern around a more complex external api that makes it easier to continue got it yeah, yeah.

A

Yeah so so technically, editor light is the abstraction that uh knows about gitlab product and makes uh makes the api easy to consume in this particular product.

A

Any other questions.

F

I have one: um do you know, do you have plans on how the interaction with other teams and the energy team will work around this abstraction around monaco so like? If are there like breaking changes? Okay, are they gonna be breaking changes? Are there things that will be exposed that we shouldn't use?

F

Are there any plans of like making sure that it's kind of self-documented like because when we were talking about the view component, the first thing that popped my mind was that could be a good way to kind of direct and expose what can be used by other teams so that you can't use like anything and when I go and break it. um So I don't know if you have like if I leave it. My question is clear, but well.

A

I I I think I I I understood, but uh so we are uh at the moment uh the process of replacing of like of introducing potentially breaking changes in the product is going on.

A

So, as I showed on that slide uh on this one, we are pretty um pretty close on closing this gap, where we have potential for breaking changes, but so far we are going pretty good and there is only one thing that is left to replace to completely replace ace, and then we are, on the same um editing basis for the whole product, introducing breaking changes when using editor light in in different groups, for example, this there is potential for that of course, because, for example, your experiment that you did with sarah on previewing the the graphs uh I already updated edit light so that your preview will be broken most probably uh so I'm I'm sorry for that.

A

It wasn't intentional.

C

Oh so nice, thank you. I love presents dennis.

A

Yay, no okay, uh so area light was not up until today, I think eddie light was not intended to to be like used widely it's more. It was more of an experiment, because uh there were still uh things that that didn't make a lot of sense. In other light- and I uh today, as I said like uh I during last week, I had two emerging quests uh merged in where I come. I trimmed down all nonsense from editor light that uh that was, they are just sort of in as an intermediary state now eddie light.

A

There is technically there is nothing to remove from medieval light at the moment. So the core of the editor light is pretty stable and the way we try to fight with the potential for of breaking changes is the way we say um how how to use ideal light. You do not there. There are very rare cases where you use ideal light as like, as just edit like bear. This is only for snippets technically anywhere else.

A

Most probably, you will need to do edit light plus extension that we are going to be talking about in a second, and this is where every group will have power to write their own extension, extending editor light to anything they want without breaking the core, so the core will be stable uh and we are going to talk about the extensions architecture in a second, but considering the core, the the very minimal core of editor light.

A

I don't foresee any any breaking changes really unless, unless uh several groups use the same extension and then this extension gets updated, but then again we can split that extension into two separate ones. One group uses their extension. Another group uses their extension and we get you're, you look skeptical. Do you have anything to say? No, no sorry. This face was related to something completely. Oh.

G

I'm sorry, okay,.

A

I was I was just like uh I. I was just thinking that maybe I'm saying something wrong, but okay, okay, cool, so.

A

Let's talk any other questions at this moment. Let's talk about real power of uh editing light because, like core of edited light is very boring. There is nothing to to play with there where the fun part comes is actually in the extensions of eddie light aerial light core. So the core of eddie light has the method called use just like we have in view when we want to use some plugins, we call use and what this use does at the moment. This is like this is this.

A

I think this is the most brilliant part of editor light, because what it does it just uses object design to extend the core of editor light with whatever functionality you want.

A

You piggyback monaco api, you piggyback what is already in edital light, and you write whatever you want. You extend it to any um like the sky. Is the limit really, so you do whatever you want. Let's start, let's take a look at how this is done practically and that will get to the to the actual uh actual extension or actually, let's start with the extension in the code base. We already have one extension that is uh in master, that is called edit markdown extension.

A

This is the extension that deals with markdown files, in particular when we are editing uh editing a file. Well, at the moment, you see also the preview, but by default you don't see any preview for blobs at the moment. The preview is something that we'll get back to soon. So when we get to editing a markdown file, we have this bar that deals with uh inserting like bolding bolded text or like um italicized and links, and things like this. This functionality is not part of edited core editor has nothing to do with particularly markdown.

A

This is the perfect scenario for extending editor light. So what I did was, I wrote the editor markdown extension that deals with everything related to this markdown toolbar in the in the editor.

A

It has methods like get selected text, replace selected text move course or in select select within selection like things that are necessary for making for making this functionality, uh like you know, quotes and stuff like this working in edited light and again the reason it is made. In extension, one of the reasons is that this functionality doesn't belong to editor core. This is a particular case of editor line. How do we use this extension?

A

We wrote our methods, and here in the extension, uh you should keep in mind that extension is going to be used on the instance level, not the global, editor level, but instance level. So if you see, for example, this in an extension, this means this refers to the instance, not the global editor. This is instance.

A

So in this particular case, we get selection of a particular instance, because taking selection of the global editor doesn't make a lot of sense, uh same thing for get position, so all of the extensions are going to be used on the instance level, not global level.

A

The reasonable question is that: why do we have this use in the core of editor light in the global api? Well, if we take a look here, we can pass the instance parameter to the use to say that. Okay, I want to use this this this and this extension on this particular instance, and then global global editor will apply these extensions to this particular instance.

A

If you do not pass a particular instance, then a global editor will go on and assign the specified extensions for all of the instances on the page, so just just the convenience uh to be able to either extend all of the instances of the page or just particular instance, uh because- and this is this is particularly the reason why we cannot move this use method to the uh to the instance level physically, because each particular instance knows nothing about other instances of this global global editor.

A

They are pretty well isolated, so we have to route this through the global editor and then global editor says: okay, extend this this this instance, so extensions extensions are initiated on the on the uh instance. Level question is how right.

A

This is the um edit blob script that is responsible for managing for managing this editing of the blob, the editing page.

A

A

Here you, if you will take a look at this script later, you will see a lot of uh nonsense here, like monaco enabled and things like this. This is related to that uh to us being not 100 um monaco based. We still have one instance of uh of ace editor and that's why we have to be very cautious with what we do in this script.

A

But here is the configure monaco editor.

A

The very the the best thing about editor light is that it's really performance, aware extensibility of editor light and putting all of all bits of functionality in different extensions means that we can load. Those extensions asynchronously on request means if we load the blob page, and we know that it's not in markdown, we do not load markdown extension, once user adds, for example, test.md, and, as I showed here, we are going to listen to the to the changes in this blob path. Name.

A

If that name changes and we see md in as the extension, we can load markdown extensions on demand, and this will save us a lot of performance uh issues.

A

This is what we do for uh for this particular page for for editing, globs.

A

First of all, we load the uh editor light itself only on demand, because, as I said it might I, if the feature flag is not enabled, it will still load ace editor and then we do not need to load edit light.

A

This means we want to load editor light only when the feature flag is enabled when editing light can be rendered, and then we render the markdown extension that I just showed. You uh editor markdown next.

A

So we just check: is it marked down? Okay now load the extension. If it's not, we just resolve this promise and that's it uh edit. Your file template. What's this in your file, template, I think I wrote some. I wrote one extension that I oh right, yeah we have two extensions, turns out: okay got it, uh but let's talk about this markdown thing, so we technically have two promises for editor light itself and for the markdown extension, and then we just do uh regular javascript, no fancy stuff here.

A

So we wait for all of the promises to actually finish again. uh We need to finish wait for both of those editor light and extension. Only because um editor light was not initiated uh in the first place. Here, usually, you will load the editor light in the in the head of your module, so it will be there and you will just wait for for the extensions to load.

A

uh So we we just load the extensions reload, the editor load, the extensions and then after, like creating the instance of the editor right. So we create the global editor. We create the instance, and then we say okay in this particular case. I did this uh on the root editor right, because we scratched that I had to use this on the root editor because use is the uh global api for it of the light okay.

A

So the cool thing is that I don't need to you to call use on every uh extension I just say use, and then I specify the array of all the extensions I want to use, and then I specified the instance that is confusingly called editor in this particular case. But this is, this. Editor is actually the instance.

A

This editor is instance. So again we call we say edit a light. Please take these two extensions and apply them to this editor, and that's that's pretty much it once we do this.

A

We get all the functionality for uh uh for for this toolbar in this particular case, getting back to the extension again just to wrap it up. Extension is the extensions of the methods that extend the editor light score functionality.

A

The extensions are associated with each particular instance, not the global editor, but each particular instance, and the way to use that or another extension is just call root, editor or whatever you call it technically, whatever you call this variable or something on which you initiated the error like so you say: okay, edit a light. Please use this this this extension on this instance or you omit the reference to the instance and then all of the instances uh on this global editor will get those extensions.

A

There are some additional things this is. This is the part where we are listening to changes in that blob path. So once we in this particular file name element is this one? So once we detect the change in that uh in the file name, we call update model language method on the instance, and this is where uh editor light parses. The extension of file name identifies the language, the uh syntax highlighter.

A

That needs to be applied to the doc, to the uh to the file to the document and applies that one so update mode language again. This is uh this one. This is one of the uh custom api methods for editing light, but if you want to see the internals again, this is there is the static method in edit light. That shows the um shows how that how that switch of this index highlighting happens.

A

Do we have any questions about the extensions.

G

Yeah, I just had a quick question. This may be obvious. You may have hit on it earlier, but um for um issue. Feedback and comments is this: is it fair to assume that this uh editor light is being used or is there something else? No.

A

This is uh technically the the comments are implemented in different ways and different views. There are views where it's a view component. There are views where it's just the text area, so there is absolutely no consistency in that in that implementation and I'm not aware of any plans to introduce any light for those parts.

A

G

Interesting, um I guess my next question would be: where do you anticipate in the product so with the current product and or future plans? Where do you anticipate editor light slotting in you obviously had the um example at the very beginning where there's uh the ci linting is. The only is the one last place where you at the moment anticipated kind of overriding and then naturally, we'll have monaco as the base across the across the board.

G

Where do you anticipate this slotting sliding in and or potentially being used.

A

uh Anywhere we, where uh we need the editing experience technically how I anticipate this is that people start writing the extensions, for example, uh for the example that I showed to static site, editor group right, so the preview, the markdown preview. This can be and should be built as an extension. So uh because this is pretty cool to you know to be able to uh to to get the preview of markdown once the mar when markdown is, uh is being edited.

A

The example that fred and sarah built, where you get the real-time feedback for the graphs that that you, you edit the document and then you get the real real-time feedback instead of clicking preview, you get it right away. So extensions like this. uh Also, it seems, like um several groups, are in the search of editing experience at the moment uh for different for different parts and technically comments might be one of those uh use cases as well. We can we can just go on and uh put eddie light there.

C

A

The uh the problem with that is that, uh technically it's just like bureaucratic problem, because who uh we, what group owns that I mean like what group has to take the responsibility of updating something that doesn't belong to any group. I have no idea. This is not the question to me. This is a question to the product. uh Apparently, uh and that's that's the reason why, on different views, have different multiplications of of comments.

A

Comments do not belong to any group and that's that's the main problem. So technically, what should happen is that um somebody, I or somebody else uh on the spare time just do that. That's it do that replacement and implement.

G

That yeah, oh sorry,.

C

I was just going to say I do know too that ci has kind of a lot of plans around extensions. One of the things we're focusing on right now is helping people understand their ci animals by visualizing them.

C

So in some cases it's like, as you make a ci ammo, what fred's actually working on right now, as you make a ci yaml it'll show you like a layout of what your pipeline graph would look like and that actually can go very, very, very deep, because then you're like resolving imports and like so that's a big piece of it. We're also you know the linting experience um and there's other things.

C

So a lot of it is around the ci yaml and making that a little bit more transparent to people who don't like to build yaml trees in their head.

A

Yeah, so I would I would, I would say that uh obviously like, but this is this- is the ongoing discussion right, so static, site, editor and ci would be the main consumers of this. This is this is like my theory again.

A

I have no idea what uh what product, what plans do product have but uh sort of, and we can talk about this publicly up until recently, our product was pushing for using webi for using web id pretty much everywhere when uh editing experience is needed in the product, but um recently there was the um the blog post, as I said where uh both things are considered to be as valuable and um single file letter. That is editor, light driven and web id will coexist for a pretty pretty prolonged period of time. For now,.

A

Yes, any other questions, any questions about the extensions or architecture of extensions or building or using the extensions.

D

Well, I just have a comment on sarah's comment. Then I'm surprised that there will be people who don't like to build yaml trees in their heads. I I'm yet to hear about one.

A

Yeah, it's it's hard to find those people, but sometimes they just you know, start complaining that it's not fun, but usually it is fun to do this in in their heads.

A

It should be, it should be fun, painful and fun.

A

Okay, so extension of edible light.

A

What's next- and this is where that um issue about wrapping editor like into the view component snakes in, but since we uh covered that part, uh I will just dive a bit deeper into the into the things that I have in my head for the future of heating light. So, as you saw we have, uh we have eddie light core. That is very slick, very tiny, and then we have extensions that we can build as big as we want and do as crazy things as we want.

A

The problem is as you as you saw in the way we use the extensions at the moment. Let's say we wrap editor light in the view component and we want to use, let's say, five extensions.

A

How do we do that with the view with the uh with one dom element?

A

There are several ways of doing this, so my idea is the next step ready to light is I will uh implement the extension system so that one could specify either path to the extension file or the module itself or specify the inline extension. So there is no no reason to build an extension for just one tiny, tiny method. For example, we could we potentially we should be able to send it in line to uh to edit a light and since, if, for example, if it's just one off case, so there are different ways.

A

We have to be able to extend eddie light, and this is this is something that I have to keep in have to think through uh when um when we are talking about extensions, but the interesting thing is that it seems like there is a need for uh for another concept, not only extensions where we extend the functionality of analyte but the concept of a widget.

A

So what is the concept of the widget? This is exactly where all these previews fall in, so widgets should be responsible for creating a dom element connecting to edit a light listening to all the required events and update itself, based on the con on the content, changes of the editor line this. This is very. This is pretty trivial thing because, uh like as I show we we can build this markdown preview. Fred has and sarah has have uh example of graphs updates. So it's not that difficult and I right now I have the.

A

I have the diff of how it is it looks like so uh there is not yeah it's going to be quite tiring to get into this, but the interesting thing is that the core of such widgets will will be in one simple.

A

One simple uh method, or some one simple listener: technically uh every modal, so every instance has a model underneath and every modal exposes the method on the change content. This is where we listen to all the changes to the text of our editor, and then we can provide the function that reacts to that thing. So this is.

A

This is what uh something pretty pretty simple, but the concept of widgets is something that I have to keep in mind as well, and anybody who is willing to work with eddie light and extend it uh so technically this these are the main points for the future, so uh we are running out of time, but do we have any other questions now?

A

I would be happy to answer.

F

I have one um when you have like, because you were talking about the widget and obviously that interests me with the work I'm doing right now, um and so do you know if the plan is to keep it so that, like this update, is agnostic of what type of data it gives so like it can be. I can just run it right. It's like whatever is in the editor. It doesn't try and maybe my question is not even relevant actually, but it's like when I was using it before right.

F

I could use the like an update function and then, whatever I would like was in the editor that was exposed, kind of an api way and just plug on that and then use that to feed in my graph, that's kind of the same principle right. It's just exposing the data of the editor to whatever's listing okay, yeah yeah. So this.

A

Is there is this uh very simple method? I think it's? um Where is it right? So get value thing, so this is again standard monaco api, so you just on every instance. You run get value and you get the uh state of that. It's like the text that is in the editor at that moment, and then you combine it with this on the change content method and you have very powerful things.

A

So, every time this method is fired, this means that content has been changed and you react to it usually in debunked uh the bounced function, but that's the the sort of the detail of the implementation awesome thanks.

A

Yes, I think we have to wrap up, but thank you very much for uh joining this call very few people left, so um this is going to be uh put on the unfiltered and I will share the link in front and call and on the frontend slideshow I think, and if you have any questions just reach out to me and I'll be happy to help thanks dennis cool thanks have a nice day bye. You too.