GitLab Create Editor Group, 27 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Source Editor Architecture discussion. 09/27/2021

Description

Discussing the PoC for the Inversion of Control architecture for the extensions in Source Editor.

A

Hello, uh we are here to talk about to continue talking about the source, editor architecture. In regards to the extensions, and today we are going to talk about the conversion of control architecture applicable for applicable to to source editor extensions.

A

So, based on the discussions we had last week um during the architecture session and during the deep dive uh I've, I've started exploring the inversion control architecture, a version of control pattern for for the extensions, and he came up with um with the poc so far, hey paul I've linked the uh the snippet in um on the channel.

A

There is a link to the snippet, and I can I can share my screen now to make it a bit more interesting. So what's what's what.

B

A

The link it's um in g underscore create underscore editor slack channel.

C

uh Good morning and afternoon.

D

A

um So I can, uh let me just add the things to the to the agenda. Apparently, since we keep doing this in the agenda, so okay today is 27th of september. Time flies.

A

You'll see of ioc and source.

A

So let me just link it in the agenda copy link, so the link is in the agenda as well now so it's the snippet and let me just share start sharing my screen.

A

Okay, do you see my screen now cool, so this snippet um has uh three things: it has the two extensions one extension two extension and the the actual like implementation with with some visual tests. So again I want to to work with this in isolation, not uh within the product just yet so to be able to catch the things early on and iterate faster. So technically, if you want, you can also copy the thing and then go to.

A

For example, I don't know gsbn or something or codes code, sandbox or something like this and I like js bin, because then I can actually have the.

A

uh Canine I'm wondering yeah I can. I can get all the all the output here right away, so the.

A

The way I did this so technically, this poc contains pretty much everything we were talking about uh and addresses. Most of the issues uh raised during the previous calls.

A

Let me just make the brief introduction into how this is built, so, instead of the that pattern with the russian russian doll, uh where we have extension wrapping in the instance with the proxy and then another extension wrapping with another proxy, so building this um this structure now we have it a bit differently. So now we have um instance, uh it's not muta mutating as it used to be in the russian doll architecture.

A

However, this is this. Is this second path that I mentioned during the deep dive where we have the separate registry for the extensions and instead of instantiating uh proxy every time, every time we um call use on the instance and then x, it's out, it becomes up to the extension to generate the proxy and return the proxy.

A

uh We create only one proxy on the instance, and then this proxy decides where to get the requested method from later on.

A

uh This is sort of the part of this shift of paradigm, so we move the control from from the extension to the to the source, editor itself uh and in this scenario like let's look at this extension, two dot gs. So this is simplest version. So technically this on setup on before and use on use, these are not required uh things like I.

A

I went with the uh with a class extension here, so this is the thing I was trying to follow more or less the patterns established by by view, so we define the methods in a separate, separate block. So these are the methods from this extension and the life cycle of an extension has. If we take a look at the extension one has uh this four main um points so first on setup, this is for setting up the extension.

A

This is useful when you need to get access to the monaco api uh before like you, when you do not need your instance, but you want to reach out to the monaco api. For example, when you set up a monaco action or key keystroke, or something like this, you you set up things that are native in monaco world, so you don't have access to the um to the like.

A

You have the access to the instance here only through this um option that is injected by source editor itself, so you do not need to pass to pass instance here manually this. This part, uh the instance, is passed to the options um from source editor.

A

So this is this is before we even uh register the extension with source editor, then on use is called right after the extension is registered with the instance, and here you have access to all of the instances, methods uh on before unused. This is when you on before you unuse the the extension so to clean out to do some cleanup, while the extension is still available and then on use.

A

This is for major cleanup after your extension has been unregistered from source header and removed uh from the from the instance, so uh very basic uh functions here, just to test so architecture wise wise when one requests a method from from the instance. Let's, let's take a look at one of the tests, for example, uh so let's take this one, so uh we create the new instance.

A

We use extension. So this signature of of how we use the extension we pass. Two parameters. Options is optional and definition is what you actually want to pass. As the definition of your extension options is, options is the object containing parameters that will be used for setting up the extension if, if the extension needs to be set up, uh so that's that's pretty easy, pretty simple, so this definition can be a function can be class.

A

What is changed in this implementation is that now we do not accept uh playing objects, so it's only either function or a class.

A

uh We can restrict it even more and say only functions or only classes are accepted, but I don't really see any viable point in this restriction. To be honest, so uh this is how we use the extension and technically, like this basic comes method, comes from the extension itself. The alpha method comes from the instance itself.

A

What is um interesting here is paul asked a very, very uh like raised a very uh good concern during the last week's um architectural discussion when he, uh uh when uh looking at the at that uh russian doll architecture, he noticed that, since every time we use an extension, we were returning a proxy.

A

This means that every time you were referencing instance before using any extension that reference didn't know anything about the extension, so that was that was a major flaw of the architecture in this case, since we moved the proxy to the instance level instant instance will know about any um currently registered extensions, no matter where it's wrap it's being referenced.

A

uh We if we take a look at the at this method, so from the methods here uh we have access to, we can set up. It can pass uh properties to the methods so um just like.

A

A

Right so just like regular uh regular parameters or as an object, it will will keep uh keep working just fine. We have access to the instance, so the uh the one and only place where we register reference to the instance on this uh extension is in the uh setup uh process.

A

If we take a look at the uh at the implementation so technically- and this is so this- this is the entry point where we uh get reference where we reference the instance. uh That's why we do not pass instance to any of the methods or in this thing so instance, is already here.

A

uh If we take a look at the implementation right, so we have a couple of static. So here is the the main, um the main proxy when we uh create the new editor instance. This is what we get. We get the proxy with the get handler that manages uh so that dispatches the request, whether uh to return um a thing from from an extension from one of the registered extensions or from the instance itself.

A

We have two maps on the instance now one that stores um extensions as underscoring extensions. It stores the relationship between uh name as a string and the actual extension, and then we have methods uh this one has the relationship between the method of method, name and all the extension names that provide this method. So the principle of lasting for style is still preserved here. So the last extension registering.

A

With the name, conflict will uh be prioritized so that that extension will return the result, but uh this map is al also allows us to actually appropriately unuse extensions when we, when we need to do that, and uh if you, if you have any questions, just stop me and pause me anytime. You want, since this is not any deep dive or anything like like that.

B

So in the handler like you're practicing get, will there be other things like? Will it be set and no other operations as well like we can, but for now there isn't no need for that, because none of the.

A

B

Real ones do anything other than get.

A

Well uh view, for example, it proxies pretty much everything like get set, uh I think applied, but for for our needs we don't we don't need that.

B

Like the current.

A

B

Extension is written with the current architecture that are already in use like they only ever get things. I'm.

A

Not even sure that they use proxy, I didn't. I haven't looked at how the native monaco extensions do this or native vs code extensions. Do this. I wanted to to finish the the idea that I had before being uh influenced by by those.

B

A

B

In using gitlab, like the current content, editor that we have some usages of it or there's, there's no usages of this extension pattern live yet I'm.

A

I'm not sure, probably himanshu is the right person to answer this.

A

Whether we have similar patterns in um like I don't. I don't think we have proxy in the competitor.

E

It's very noisy, but yeah. We don't really have a proxy patent, uh but uh as as paul had mentioned in uh in in last session uh that we have something like we have different sort of event, handlers that all the extensions can subscribe to. So we have a couple of uh let's say it's like an interface, so each extension has to follow an interface.

E

So we have a couple of functions uh and the extensions just follow the interface and extend certain methods and basically hooking uh up to certain functionality of the the.

C

That's that's! What's really cool with uh with this, um this extension approach that you're showing dennis uh because there is a specific interface that extensions have yeah. I see like there's this life cycle methods. I want to provide.

A

C

This is how you do it, uh and it's.

A

Like I did, I didn't um I wanted to keep the the number of the slight cycle, events to the bare minimum, so that yeah, so that it's like it's not over complicated and.

C

A

C

This is all you need right now, because.

A

Exactly I have.

C

uh When I've used it, I need to do some setup, and then you know when I'm not being used. I need to do some teardown yep and that's that's about. I think, like exactly.

B

C

Right now and yeah, it sounds um uh that that looks great. I think I think that there's a a little bit of confusion on what is the problem we're wanting to solve with the proxies. um I'm really not sure. Why do we want extensions to expose methods like like, um because that's still and that still keeps some coupling where you know my my type? What I can do is gonna change based on. What's I've done at runtime?

C

What if extensions, were just listening to monaco events and is that possible and what problems are we trying to solve sure? That's, that's totally possible.

A

Let's, um let me just do this thing, so this is, um let me just move it here, so this is uh my local sort of environment. uh If we go back go to to an extension, let's, let's take this simple one. So technically what we can do is we can say here.

A

This instance, and since let's, if we want you to listen to the events on the monaco instance or we import monaco and do monaco on, I don't know like paste or something like this. I don't remember those those events and then we reference one of the uh methods.

A

uh This syntax will be a bit odd, for example, but.

D

A

This is this, is this is what.

C

We're saying we're saying we want.

A

D

Reference, our own methods, yeah.

A

D

Like another, this is just a regular.

A

Class, this is a regular class that right that that doesn't sort of doesn't really expose the things it's just. We we get access to these methods in the source header in order to build that map of um relationship between method, name and the and particular extensions that that provide this method.

C

So here these methods that we're providing those are um only ex expected to be called within this extension. Other extensions may not know that these methods exist.

A

No, no, the no, the other other extensions do not have access to the methods they might have. The they will have the access to the methods that are registered by source editor because those are like. Technically, if you do the instance dot something uh we will, the proxy will kick in and if, if some other extension registers this method, we will get access to this, but attacking, but other extensions won't have access to these internal methods uh really.

C

And like and not feel, like extension from extension yeah, and I think, and I think we'd like I think in the long run, we can avoid a lot of um weird coupling things that come up.

C

If we don't want, if we just land on now, we don't want extensions to call other extensions methods and we rely on other means of like message passing if there has to be some sort of communication, if we use some sort of event hub, maybe using the instance as an event hub. I don't know. If monaco, how like flexible, you can be with events that are emitted or listened to, but.

A

This would would pretty much over complicate the the end user, uh the yeah, the end usage of the things. So if, for example, I have like I'm building the the complete experience like, I have, for example, two extensions that kind of like one of the extensions relies and depends on on the other extension. So I have to have the access to the methods of the first extension from the second one.

A

In order to build like, uh let me give you an example, so the the toolbar for the uh for the source header, uh the very first thing- will be the extension of providing the content panels. So the panels that sit within the content uh within the editor area, one can set it up to be placed on the left on the right on the top of the bottom of the editor and then at the actual, toolbar extension will be.

A

You will be depending on that extension because it will be introduced as the content panel above the the editor, so the toolbar extension in this case will have to have access to potentially will have to have access some access to the to the content panel. Extensions methods, like methods introduced by that content panel, obviously the communication will happen through the through the instance, so extension won't be talking to the to the to each other directly.

A

All the communication will happen through the instance so.

C

Yeah so you're saying one extension could provide like the basically it's going to provide the framework for another extension. Like you know, we're going to need panels, here's the panel extension and then here's another extension. You know I want to.

D

C

To the right panel or something yeah, that's that's interesting.

D

A

For, for example, in the um in the toolbars extension I'm on in the on setup uh callback, I might already want to set up that panel for for the toolbar. So I do expect the panel being there uh when I'm calling the extension and if the panel is not or like the functionality for the content panels, and if the content panel's functionality is not there. I just stop and do not do anything, because without that extension, it doesn't make sense.

A

Obviously I can do class toolbar extends the content panel class, but that's that's not really optimal, because that's exactly what builds the uh the dependencies. Also, that won't work in the. If uh somebody, if we decide to go with the uh with the extensions that are functions, not classes.

C

So uh hamachu does uh does tip tap or whatever tip tap is based off of I forgot, or maybe the other thing um do we ever have extensions that are are required from other extensions like for this extension to work. You need to have this extension loaded or like.

E

uh We sorry we sort of had a uh situation where we would require other extensions, but uh tiptap doesn't normally do that. So we came up with an alternate solution where we don't really need to rely on uh another extension source so that sort of uh smell uh like sounds like a cold smell. So what we did was we abstracted that piece of code into a separate utility so that utility can be shared across different extensions.

A

And this is this: is beauty beautiful here as well, because, technically you can. You can use this exactly the same approach here as well right, but um this would be sort of artificial limitation if we would not allow extend, because you know uh in order to like just think about the life cycle of the of the extension. So we have bare uh like plane instance without any extensions, then we uh we say okay instance use uh content panel extension and uh toolbar extension.

A

So, first of all the uh content panel extension will be applied to to the instance, then the toolbar, so technically, we will also have to to be able to just to differentiate whether a requested method uh comes from the instance or the method request. That comes is sort of expected to be somewhere on the extension so that we like, we could uh introduce the uh the um the good patterns notifying the user like okay. We should not write extensions requiring uh or expecting methods from another extension. This is sort of like unnecessary.

D

uh Artificial work to so, I think I think I get the.

C

I get, I think I get um some of the problems at hand and and and that helps- and so this this um desire to to for an extension to expose methods and what it's making me think of like if you ever dealt with uh like wordpress, plugins and php, it's like uh you'd install a plug-in and then some plug-ins require other plug-ins and every plug-in can provide. You know some public methods that other things can call and, like all of that um was helpful.

C

um Other things that this reminds me of is, um I think, uh how how modules kind of used to work with angularjs, um and I wonder if this would be helpful rather than writing anticipating we do all the communications with the instance.

C

What if we did some sort of providing and injecting pattern here, where an extension can say, uh I require panels and some extension before me had better, have registered and injected say here's panels and here's. You know the object for running panels or whatever so like on use.

C

I could say something you know we're gonna know like or maybe maybe it's one of like our functions that we return or like I inject panels. Here's the object for it, and so people can call add panel or or whatever it is, um and that way we're not just writing to this one. God object, that's just going to keep growing and hopefully doesn't have name collisions and things like that- and this is very similar.

C

I think you're thinking about having some sort of registry for extensions with names and stuff, but that way were one extension, could still call the methods of another extension. But at that dependency it's that dependency, it's not and those types are, are separated.

B

To jump in on that, that sounds a lot like what prose mirror does it? Has this concept of a state object that extensions can use and it sort of handles, registering and then registering stuff from the state I'll put the link in, but that's what enrique mentioned last time.

E

uh So that state object is just for serialization uh and that uh sterilization is not really a part of the extension workflow, but uh yeah that that is. uh I mean that that is a good example of how data sharing works between different extension.

E

I mean it could work, but we don't use extensions for that in content later, and the second point I wanted to highlight was that monaco has, I mean intentionally separated view and model into separate, separate modules, and what we are doing here is we are combining both of them into a single thing that can be consumed by uh anyone. So that is like. uh I think we should still try to keep both of those separate it's it's.

E

They have separated it for a very good reason, uh and by combining everything in a single class, we are sort of doing like everything uh in like, like, as paul mentioned, a sort of a god-like object uh which, which could be a cause for problem, maybe not now, but as the extensions keep growing uh I mean it could be problematic in the future.

C

Can you can you clarify what you mean by um putting everything in one object or one class.

E

I mean uh you're accessing the model and updating the view in the same class and exposing those functions for other extensions to use. uh I would rather I mean I would rather expose those functions separately and maybe not even call this whole architecture. Extensions to just expose the functions and whoever wants to use those functions can just import the functions.

E

A

This is I like, okay, maybe I I didn't explain this correctly. So, um okay, I'm I'm not sure. I hear anything that would contradict the current implementation. To be honest, so uh again, extensions do not get access to uh to each other methods directly right, so the um where? Is it yeah? So uh it's it's. The editor editor instance through the proxy figures out the all of the extensions registered for a particular method.

A

uh Where is it like uh right, so register extension for extension methods, so registers all the methods for the extension and then when the request is like when, when the client requests any particular method from this instance, the instance will return uh from the extension that is, that is, register registered last for for this for this method.

A

So there is no direct communication and direct dependency between the between the extensions in in here.

A

So the the direct dependency might might occur on the on the level of the of the extension uh itself, but that's inevitable, uh like the the problem is that extensions in uh we are dealing with here and extensions in tiptop are a bit different things, so extensions that that are possible to create with them with the with the monaco with source header are like they're much broader in scope by by design much broader than scope than than those of uh tip top.

A

uh The uh the reason for that is that, um for example, again getting back to the.

A

To the content panel and the toolbar extensions example, so the content panel extension we'll have to have this setup on setup callback in order to get access to the raw monaco monaco api and do some setup before the toolbar can be uh can be created.

A

uh I'm not sure how how to break sort of that dependency and whether the dependency has to be broken at all, because technically, by registering uh the content. Panel extension once uh happens exactly the same thing that you pull described so any extension can actually get uh can can get access to to those methods through the through the instance not directly through the instance and uh that's technically from from minus, and that's that's what has been described so far, uh so we register extension once and then we can.

A

uh We can use it or uh request information from it at any point of time of from off another extension, for example, or the instance itself. So I'm not sure I I'm I'm following uh what is uh what is the flaw here.

B

How much do you do you have links to what you we're talking about the separation of view versus model for reference.

E

uh This is what we've done in the in the web ide. So in the web ide we have a separate model controller that controls uh multiple models uh and we have sort of a manager uh so and the view is taken care of uh like, but but even in the web ids, it's like a single editor class that takes care of everything and controls. Everything.

A

I think we we've got rid of that uh of that complexity in web ide when we were migrating to the source. Editor extension.

E

Now it's it's, it's still the same, it extends associated, but it's still pretty much the same.

C

Yeah you're talking about the editor component.

E

uh Not the component, but uh the i2.js file yeah.

A

Oh right right, the editor wait. The edited.gs file is not in use anymore right, so the editor.js file is not in use. We are using the source, editor extension. Instead of that, one uh that file is uh can can can be simply removed. That's not that editor.gs is not in use.

E

I mean yes, uh it's it may not be in use, but we're still uh using the same pattern and associated as well.

C

Okay yeah, I I still see editor.js there yeah and I read.

A

The gs is there simply because I didn't remove it uh so yeah like uh the whole process of creating the source. Editor extension for webii was just taking what we had in um editor.js wrapping it into the um extension format and do the very very rough cleanup of what is uh what is going on there.

A

So that's um editor.gs so that editor.js.

D

It looks like it might still have um okay, so this one this one.

A

Is not in use, we do not get this one so far. What we are using instead is web id uh sources web. This is the current web id uh state.

A

It's much smaller, uh it's much smaller and that's that's the thing like I that's why I say I think I've got rid of that complexity of um of models being separated from the from the views uh or no. There is the model model manager here. Okay, I'm sorry! I didn't get a read of that.

C

A

D

C

Is that the this we're still doing this separation? The the extension was based off of the old editor js, and so that pattern is still there is that kind of what you're saying hamachi.

E

uh I mean right now uh all the extensions that uh we use in source writer are, I mean, except for the web id? They don't really touch the model uh which in which, which kind of makes all the extensions. Like view only extensions uh I mean, uh except for maybe the the gitlab ci one which which does change uh the model, I guess a little bit, but but yeah I mean it's just uh like my preference, like I sort of prefer uh like a functional programming approach where just you just call functions.

A

E

A

But okay, like in in this in this approach, what prevents you from actually uh managing modal and view separately and that just wrap it into the same cloud into one class like what prevents you from doing that. Yeah.

E

That's the point: if uh you.

A

Mean nothing, nothing forces you to do so.

E

I think, but the the paradigm has already been established like we are already uh combining both model and view in every extension. So.

C

uh Are you thinking that maybe we could have extensions that are just model specific and extensions that are just presentation, specific, like having multiple extensions targeting those different parts or yes? But.

E

I wouldn't call them exchange since then they're, just modules.

C

Yeah, I think, um I think think something's an extent we're calling an extension- and I think you know plug-in- is kind of synonymous with it. If I'm I'm picturing from the view component, which is my desired interface for creating a source, editor instance, I would love to just say here's the list of things to here's the list of types of what I want to extend the core behavior with this and.

C

So I think that yeah, these are just mod modules. An extension can just be just the glue code, part of it, but it is nice having one type that you're referencing, for you know, here's how we want to extend the main source center, but if we want to do something for all of source, editing like for every instance of source editor it brings questions of.

C

When is something an extension, and when is something you know, maybe the core part of when we initialize the editor or something, and um especially for doing something with, uh especially if we're doing something with panels.

A

Like technically like.

C

A

Technically, what um the uh model only functionality can be totally like can be totally achieved like this, and then you just you just create only on setup in your extension and then you do you deal with the uh with the model.

A

Yeah like you, do not need all of these things, or actually you might want to uh to to keep the one before unused or unused to tear down the or reset the modal changes.

A

I I do agree that we do mix the things here. I just don't see any problem with that. That's the that's the thing.

C

I think what's what's I think monaco has those mix of responsibilities, and so that's, I think, part of where that's that that paradigm of you know monaco just has one one funky instance that has everything you ever want to do.

B

C

um And uh so the extension is naturally going to you know: hey we're extending you know what you could do with monaco here's the instance. Well, you know, and so I think it's worth keeping responsibilities small, because then we're going to be able to reuse them, um and I think that's something you'd want to want to keep uh keep an eye on. I do see benefit to having extension classes or even extension functions which may just be a used function with you know which returns how to dispose it like.

C

I think I can see a functional interface for this. um uh I think, having those you know, usables ie, plugins, ie extensions. It's really valuable because I think when I'm thinking of this interface with view components, I see that um being helpful.

C

This. What do you? What do you think commodity? Do you still?

C

um If I understood you correctly, it's not like you're saying for some things. We might not even need an extension and- and I think that might be right- I think it is nice. Having extensions be this glue code because you on some instances of source editor, you may not want to have certain behavior or whatever, and turning that on through these references sounds nice yeah. I can actually give you an.

E

Example of that like, for example, like themes and registering different languages. uh Ideally we could have an extension for that, but we don't uh we actually just initialize monaco and call the function just passing it to the the editor object and it just does the job.

E

So, ideally, that could also have been a separate exchange and we could have just sort of used it, but it's not so yeah. So we can think of situations. Where uh I mean does it really need to be an extension, and can it be just a function where you just pass it and add an object and it does what it needs to do.

A

Can't that, uh for example, be just just a separate like okay- it's not an extension, but it's just a module that you uh that we might simply uh make part of the source editor core.

A

Does it make sense to make the to make it part of this source source? Editor core? I don't know.

E

I mean yes, it could be a part of societal core or it could also be a part of a separate extension, because I mean you don't really need I mean, for example, if you add some more language support, you don't really need that support, for I mean everywhere.

A

Right, I don't know for me for me, it still sounds like an extension like I do, extend the functionality. I do extend what what is provided to me.

E

I mean yes, it can definitely be an extension as well, uh but it's not uh right now at least, uh and we could make it an extension or we could. uh uh Alternatively, we could also like use the same approach for extensions and uh and associated as well, because that would be much simpler. You wouldn't really need a proxy just describe a couple of functions.

B

I think there is benefit to it yeah. I think it doesn't really matter in this case either way, the same underlying method is being called. I I think, there's benefit.

A

To doing everything.

B

The same way and the extension approach seems to keep it less coupled and easier to test in isolation with a standard api for everything.

C

What's um and I apologize for keep bringing this up, but when I think of I want to interfaces through a view component, I'm not going to have access to the monaco instance at that time. Like I'm creating my view component monaco hasn't been set up, then I want to pass the list of extensions without with and and and I like- that, I don't even want to know monica's being used. I just want to say here's source editor, here's a list of extensions, um just devices from.

B

The life cycle of of creating it.

C

Yeah I I want to I want to I want to, uh and hamachi mentioned you know, I have a preferring functional style and I think that there's an api change we could make that would um I want us to be thinking about what would the functions for these kind of extensions look like and uh yes here it is. We could yes, we could do it like this, um but you see we're still kind of quite stateful of like saving off the incident. The incidents and and things of that nature.

C

I want to propose a functional interface uh for this and see what everyone thinks so here with this with this function. Extension: what if we received the options at the top level function and because, when I'm creating my from the view component perspective, I want to say I want to use this with these options and I want to just create. I don't, and I want.

A

C

A

You mean, uh let me just uh let me just do this, so uh here is the functional this one's.

B

Not in the this right.

A

This one, uh no, I just you know in order to not have the uh comments there, I will. I will create the new snippet or uh append that ones with the with a functional thing, so you mean paul something like.

A

Of like this, um with, like my oh yeah yeah this um this, this should be possible. So the problem is that I wanted to uh to keep to keep the options and the definition for the for the extension separate in order to properly register the the things, the methods and the definition of the extension in the registry of the of the source editor. That was the main. um The main reason for this um so technically.

C

Wouldn't that be in the um and the use of it like that's, I think the I think one I was gonna show how this would work with um like a functional interface, but looking at this class interface, I like- and I see on that line- oh yeah yeah, I so even oh yeah yeah, um I think it'd be really cool for this ioc extension um like I feel like I'd like to be able to create it, I like to be able to say here's a new ioc extension with options, and um I know I'm also thinking like you know, some of the ruby, plugins and stuff how we do this and um on the use and before unused.

C

Let me receive the instance, and this brings up this- is, I think, the the inversion of control that I was anticipating was rather than me, saving off the instance. Let me receive that in my life cycle, events yeah.

A

That's that's totally possible, that's like that's, uh that's absolutely possible and uh we can. We can.

D

C

It's yeah and it brings up. It brings up some interesting stuff, because then I could have something I could have an extension. That um maybe is is.

C

I could have an extension that technically lives beyond a um instance if we need to dispose and create instances real fast, and maybe this.

B

C

Though, like the side effects stuff, I don't necessarily need to keep recreating or undoing this.

A

I have a I have a question about this approach, though uh so, if we take a look at this uh at this extension, so um if we pass the instance to let's say on setup on use on on anything so technically, we have to pass the instance to every single method as well. When it's get when it gets cold right because, for example, we would uh where is it like yeah, for example? I would like to be able to have access to instance from from method. Probably I don't know like.

C

Yeah only the ones that need it, though, and some methods won't need it and and yeah.

A

D

C

Pass it around, so that's the point is like we wouldn't save it off. We would prefer passing it around, and this is probably going to create a number of like pure functions that that we could reuse across extensions too, because that's.

A

That that's how it used to be um earlier today. That's how it used to be uh I just I don't know. I just thought it's nice to have one entry point um and just store the instance on the.

B

But technically.

A

We can we can. We can easily do that because, as I said like it used to be this way uh at some point and it it's like it's very fast change to uh to to get to that state.

B

I think in general, it's best to lean that direction like pure functional interfaces have a lot of benefits, not only the ones paul mentioned, but like they're just easier to test, you don't have to worry about state when you test it, you can test them just by injecting a mock or whatever you want always right.

A

C

So the way what I would anticipate is um we would receive the instance in the life cycle methods, and then I may define some like private methods that I'm calling her passing along the instance um and uh or I it sounds like I may need to find new methods or some that's where things I think make it interesting.

C

um But I think that this is going to.

C

That's going to create a nicer api for when I'm wanting to bootstrap the source editor, because then I can just instantiate these extensions as constants and just just leave it, and- um and I think I like how how you're thinking about removing the awkwardness of like already you're, saying, here's the definition based on the class and the options you're going to pass to it, um and I like how you're thinking I I'm I'm going to reference these I'm going to break the because right now, there's some awkward code, where you're doing something, like instance, that use equals new extension.

C

Here's the instance uh currently in the code- and I like how we were breaking that. I wonder. Maybe we want to go all the way and now I can actually create new ones of these. I don't have to. I don't have to do this definition, object or anything. I can just instantiate these yes with functions. I can just call a function, and that might be nice, and this.

A

So technically we we now, I have removed this instance from so we do not store instance on the uh on the uh on the on the extension class. So we just directly pass instance to the uh to the method, so instance will be the first argument in the list. So there might be other things I don't know like foo or something uh but technically instance will be passed as the first argument uh or wait a second. But if we pass other arguments then we should make it like no or something well.

C

Something may not something may not need, so I think if we have an extension and it's using and unusing instances, um I am then going to if I'm, if I'm being used, we then want to provide certain functions and those at that time, when we provide those functions, um those can be uh instance bound or not, but I definitely- and this is another- this is there's a side topic. I know we're at or have time this one to just think about.

C

I don't have a clear picture in my head and I think, as we talk about it and wrestle with it and figure out what works and what doesn't we'll find a nice place, the um with methods I'd really really like to separate what are we publicly providing, and what can I just call and what, like I I'd like I'd like to make a distinction between public and private methods and, I think, provide an inject pattern- is a and you kind of already have that um infrastructure set up with these maps and stuff.

C

I think it'd be cool for I'm being used, I'm going to provide these public methods, but.

A

That's that's the.

C

Thing all these other methods.

A

This is, this is technically. This is what is done, like anything that is within methods is the public right, so anything that is outside of it is private. Technically, so only the methods from this methods thing uh become the pub sort of constitute the public interface of the instance later yeah.

C

I love that there is.

A

Clear separation.

C

Here, I think I think that's awesome and um I would love to then see if this means we could actually catch potential issues um early and that'd be really sweet because I would love to see here I'm an extension, and I require these things. Yeah.

A

C

Rather than you know, having a random runtime exception because we didn't set it up right, it'd be really cool for let's eagerly blow up, and that would blow up on tests because your extensions, you know, I'm about to call this map that I expect to be set up. That would be really sweet. It's.

A

Also, you know like we can even introduce the uh dependency, for example, if we have any sort of dependency on some uh on another extension. But it's only for one small specific case. Then we could even use something, like instance, use on the left. Oops instance use on the on that particular method level, so that we do not sort of blow up the whole performance uh chart. But just for this one particular case, we will have access to this as well.

C

Well, if we have if, but if, if we have tests that are at least just you don't have to run through all the edge cases of it. If we have tests, if we know I'm gonna, I need this for me. I think you can set that up and like somehow like the metadata, I have some ideas for how we could do that.

C

We could eagerly blow up, which is actually a good thing, because then we wouldn't then have to incur the cost of like using something you know, while we're trying to process a user event or something like that, and I don't know what could require there but, like I do think it's cool having one section where we're defining. What's public, that's really sweet, and I I have some ideas. I think we can even drop that inside of the on use and name space them too would be really cool, and um so I think this is.

C

This is a really. um I really love the restrictions with this interface that we have here and I and I think, um I'm excited about making these extensions a little less stateful and and being even more explicit- and this is this- is cool yeah, thanks for thanks for uh putting together this, this poc that we can uh play around with.

E

Yeah, uh I just wanted to add one more thing that uh instead of uh having this uh sort of uh on use and on unused approach, we could possibly have a setup and teardown approach where uh uh you you just uh declare a function.

E

That expects the editor object and then you return a teardown function uh that that's usually what other libraries do when they're registering events and returning an unregistered function back uh and you could also follow like in angular there used to be a I mean, even in view there is this factory pattern uh where you just declare a factory function where you could pass the options and it returns another function uh that takes the the edited object.

E

So you don't really have to uh I mean you can configure the extension, but you don't really have to uh have the item object beforehand before you instantiate the extension, so you wouldn't really need all these functions. You can I mean you can have all these functions as private functions inside the closure so and whatever you return, is uh uh sort of.

C

The exchange- that's that's, I think, you're. I think you are 100 describing the functional interface. I think I'm I'm anticipating too I'll. um Do you want to maybe write a? Can you write? Maybe an async comment on the issue or the mr kind of just with some pseudo code. Hamachi yeah.

E

C

E

C

That'd be awesome um dennis thanks so much this was awesome, yep cool. Thank you very.

A

Much I'll talk to you later.

C

A

A