Magento PWA Studio, 31 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PWA Studio Community Sync 31 July, 2020

Description

Demos for Out-of-Stock product error, Prefetch Optimizations on Category/Product Pages, I18n/L10n Updates, and a review of the new Extensibility Framework

A

All right, happy friday, everybody thank you again for joining us all for another pwa studio community sync. We have a pretty packed agenda today with some demos from the team we'll try to make our way through all of that content.

A

Obviously we'll save some time at the end for additional questions, any items that we might have from the community in community corner and then we'll uh we'll wrap up and step into our weekend right. um So we have uh to start off with uh we're gonna start with tommy today for demos, um uh as you guys saw on the agenda, we have a quick update on kind of out of stock and an issue that tommy addressed.

A

Take it away, tommy.

B

Thank you, andrew all right, so uh we had a tiny bug pop-up that required a large solution um and figured it'd be best to highlight this uh in case you've encountered it it's kind of just a weird um edge case in um graphql and kind of I'll start off with. Like a today, I learned oh jeez, I lost my spot.

B

um All right so today I learned um if you can get data and errors back from graphql, and this is exactly the behavior we see from the magentographql api when you have a product that goes out of stock. So in this example I just have a cart already set up.

B

I have two items in that cart, whiskers and mittens mittens has gone out of stock. I waited too long. Somebody else purchased that kitten, um so one of the things you'll see is in a let me bump this up in that graphql call find the right one, get cart, details, you'll, see um data and errors.

B

So we get our cart back with all of our items and then I'll talk about that in a second there's, a null item there. So we get both of our items back, even though one of them is out of stock, and then we also get errors saying that some of the products are out of stock.

B

So it's kind of like an error that um we don't want to be blocking, but a lot of times we write code that like, if I receive an error, something went wrong and I don't want to render, but that's not the case here so first I'll go over uh the treatment, then I'll talk about this guy a little bit um and then I'll try not to take up too much time. So we leave plenty of time left for zetland to talk about extensibility, um so the treatment now is uh we no longer block.

B

So I think previously, if I were to try to interact with anything. In my cart, I would just get toasts saying like there's. There is an uh out of stock item in your cart uh so now, instead we're just going to kind of ignore that error. um Since, um since all the code is kind of written to block on errors, we kind of had to make this decision to just ignore it and then uh with ignoring it.

B

We have to decide when to address it, so we decided on three areas: we're not really gonna like prevent you from like trying to check out. But if you go through each of these three warnings and you ignore them you're going to have a bad time, so the first one is in the mini. Cart. You'll, see that an item is currently out of stock, we'll highlight which one of those items is out of stock.

B

We also tell you it needs to be removed if you want to check out. Additionally, if you go to your cart or if you're on mobile, you don't have the mini, cart you'll again see another notice, an item in your cart. It's currently out of stock must be removed, and if you ignore that we get a little more bold and say you again, you must do this.

B

We make it convenient for you to go back to your cart and then, of course, if you remove that item everything's all all good again and you can continue in your checkout process.

B

um So I did want to highlight how we did this um it piggybacked on some work that stephen recently did. So we used a on air um link in apollo, so this is kind of it deep into apollo's middleware when it receives a response on air, is kind of one of the first links to fire and allows you to kind of just do whatever you want with a with any air. So like I.

B

Mentioned up in index.js, um so uh we just added additional uh logic to the air link that fires to detect this this air. So we can ignore it so a little fragile in that hopefully they'll ever change this error message. But when we see this air we do a few things.

B

We slice it out of the air response, so that will cause it not to throw in any kind of query or mutation, and then we also do you saw that null.

B

C

There's a way to do this right right of the file.

B

Thanks all right, so we do two things. We slice out that null item. uh That's, that is a bug that um magento core has acknowledged and they should be fixing it. um One of our architects did mention that that is kind of a common pattern. So um maybe look out for that. Maybe magenta will come back and say, like the null product is supposed to like doubly indicate to you that there was an error that you need to go look at, but I think they've said they're gonna.

B

That was a bug and they're going to pull that out, but so for right now we're going to fix that bug by just slicing it out of the cart response that we get, and then we also want to make sure that we slice out um that error message, so it doesn't throw and also, if you had like something monitoring the error response from like a used query or a used mutation, um you probably were going to like throw a toaster like throw something on the form, but we we.

B

We feel confident that this is something you can safely ignore and just address when you see fit. um So I think that's it. uh I kind of covered a lot there. Any questions about this change.

C

Hey tommy, you mentioned that so we're fixing this bug where the first null the first item is null in this case. um This is only client side right, we're spike we're splicing it out of the response that we get and then what we're using to render um does that item get removed after you at any point, or is it only like? Does it disappear after you remove the out of stock item or is.

B

C

B

Item being out of stock, yes, um so yeah the the bug was like uh yeah, it's for some reason: the air didn't have a current reference to the actual product, so it created a null one. So it could say I have an error, but I don't know for which products I'm gonna create an old product. It's a very odd, odd thing. But yes, once you remove that item, that code doesn't kick in anymore. That null thing uh the null product does go away.

C

Okay, uh I had another question: can you see us doing this for any other cases in the app sort of a non-blocking error? Can we expect? Was there anything you discovered in your work on this pr.

B

You know I I haven't done any digging to see if there's any other, like positive air cases from the magento graphql api um that if it did come up again, we would probably do it that way, but I think there's an architecture proposal that kind of would, even though this is supported by the spec. It's still it's a little weird to like have a positive error or a non-blocking error or an informational error.

B

I don't know what you want to call it um so they're talking about putting that on the like result, set so there'd, be a field called like user errors, or something like that that would, um if you cared about blocking on errors, you would like go through that field.

B

I don't know if that's been accepted yet, but uh yeah. It's just something to keep in mind if we do yeah, if we do find another kind of positive air case that we don't want to block on. I think this is a perfect solution here.

C

Yeah, it's kind of interesting that it's an error at all, because it's not blocking and like it could have just been informational. We could have just checked for the stock status, which is a property on the on the item itself and done this ui uh flow, but but the the the reason we have to do. This is because it actually does prevent a user from checking out if there's an out of stock item- and we have to surface that somehow.

B

Yep, I think it's just one of those things. It was modeled after luma, so luma doesn't class, it doesn't say anything about an out-of-stock item until you get to checkout so um we're at least like trying to get a little more in front of it. I think there's an epic coming up where there might be like a toast that we pop like very early as soon as we know it's out of stock, we'll let you know um you could even like automate just removing that item and, like I think that's what amazon does is.

B

um I don't know if I can say that word uh they like automatically.

D

Just remove it.

B

From your cart and then tell you um so I mean you could do something like that, and air handler is actually like super powerful and like, if there's anything that you're getting from graphql that you don't like, like even in the response object like you, can change it. So um it's kind of like it's a very powerful piece of um functionality that you can easily tap into.

A

All right any other questions for tommy.

E

A

A

uh Great well, uh the next step stephen, is uh here to demo some optimization work.

C

Yeah, so I uh wanted to demo this thing that I worked on last week, which is sort of a little shuffling of the prefetch logic that was happening in category and product page.

C

uh If anybody's done any work in here, you might remember that the category query used to make a um sort of a just an implied, uh prefetch call wherein when you, when you're on the category page the uh here and I've cleared my cache, the network request would fetch the products that are going to be rendered on that page, so that, when you click on the item it will, it will automatically load as fast as possible for it for the user, which is a nice optimization um on paper, but it actually turned out not to really do that much, because uh you have to wait for the url resolver query anyways, so that we can determine what component to render.

C

When you hit this, uh you know a product link, so um so that aside uh the cap, the category page was pre-fetching product data. um uh You know in in an attempt to make it faster. You know on venue, we have six. You know six items on the category page. I think is the default that we've used, but I'm sure a lot of you have customized your uis to render more than six. You know you can render anything you want. You can paginate as much as you want. um You know.

C

So imagine if, if you had like 50 items on the category page, your category query was: was fetching 50 products or end products worth of data just to pre-fetch, and that was all up front, regardless of whether the user clicked the first or the last item it would get all the items in between, and so one thing I did was move the query for that product data into um into a a less sort of implicit location. It's now just a direct query called get product details.

C

I think yeah, and this pro this product you know you'll under you'll. um You can see the the path here. It belongs to the root product which makes this this query. When you hit the product page itself now, but um we're able to to sort of use this in two places and maintain the prefetch logic. So here's the product page making its own call.

C

But the gallery item itself, the the the let's see here. This is the gallery, so each one of these items now also uses the product detail, query and inside uh inside use gallery item.

C

uh We have this uh cool logic here, which uh creates an intersection observer waits for 50 of the of the image, the gallery item to be in the viewport and then runs the prefetch query. It uses cache first as a fetch policy, which I believe is the default.

C

So I actually don't think I need to do this here, but but that way uh you know the first time you hit this page first time you scroll into into the item, we'll make a prefetch query, we'll set we'll say: you've already prefetched this thing, so we won't ever try to prefetch again and if there is something in the cache, it won't do the prefetch, because the benefit of doing that prefetch is moot anyways.

C

um And so you know that's really it this this little logic right here when it scrolls an item, 50 percent of the way into the viewport it it makes query so here I have my local setup.

C

I just want to demo it real quick, so when I, when I load the page, oh and I've added a gap by the way, so uh that way the bottom doesn't render. So you can see here, I think, there's the product filters query. So here you now see the four products that are in the viewport uh being requested, the crochet shorts, the um yeah.

C

So you can see all them now, I'm gonna do something: that's gonna be really magical watch as I scroll boom, there's the magic right there, uh the two uh products that just scrolled into the viewport um uh emitted that that that prefetch query. So now, when I click on this, uh you know we still have to wait for that. Url resolver call, but there is no other there's no need to wait or block on the next request, which that would otherwise be made.

C

If you went directly to this url, so yeah you'll see that there are two requests once you hit the product page, but that's because we explicitly defined the caching network, fetch policy, which is something I wanted to talk about as well briefly, but you can see the breadcrumbs query and the product details, query on the product, page use cache and network, and that's just a way to make sure that we true up with the server data, make sure that there's no no stale data being rendered in the cache, and that just brings me to a small point, which is something I wanted to float, which is that we might be considering using caching network as the default fetch policy, because we're using it in a lot of places.

C

And there really isn't um you know so long as there's, not a network error. That causes causes the app to crash.

C

It should be fine to use cache network in that we can always lean on the cache first and then update our data afterwards to be to match the server data um any other things I wanted to talk about. Oh there's, a small bug.

C

I wanted to uh mention here um inside the category query we make uh we make that products query still, but we don't fetch as much data as we used to you'll see if you look in here, it's just name price, small image and url key, and that's because that's what's needed to render a gallery item, and we would just be using a gallery item fragment here, but I found there was a bug and they're resolving it and I think 241 that this wouldn't actually return correctly.

C

If you used a fragment small image, url would be like null, even though without the fragment, when you inline the the property here, it returns the actual value for whatever reason so uh just be aware of that. If you're writing your own graphql queries, if you're trying to use fragments double check that the data is correct, coming back and that there's not a bug and maybe just reference this uh issue, if you, if you, if you run into that, um I think that's it. Is there any questions about the the work in this pr.

D

Yeah, I have one question about the prefetch: um make you a measurement about uh what is the difference between uh if you don't prefetch the product on the category page? How? How fast is uh it is or how slow it is? It's much a different between uh don't prefetch the product, because, from my point of view, if you have uh 40 products and a user scroll on the category page uh down to the latest product, we still prefetch all products and will get many of uh craft coil cores to the back end.

D

And still we get a massive load.

C

Right, so it's the difference. There is, do you batch up front in the category query, call, or do you make prefetch queries as you scroll and you're right, um the intersection observer will, if you know, if you have a row of 10 items, it'll make 10 craft kill calls as you scroll up. It might emit a whole bunch of graphical calls um it's possible to remove the prefetch entirely. If you want.

C

um Let me see what so this call the product call on this product page took 1.27 seconds, which means that if there is- and this is the cash and network call, but that does mean that if you hit this product with no cash, you would at least be waiting 1.27 seconds on this run. I don't know what the average is, um so you know so that's to be considered, at least for the cost of hitting the product page without a cash.

C

The cost to hitting the category page and scrolling um is. Is that difference that I mentioned it's just? Do you batch upfront in the category call or do you do you um just prefetch the visible products.

C

There is, I guess, there's possibly some safety checks. We can do. First of all, we only emit the the uh prefetch once so. You know you scroll in scroll away, scroll back, it doesn't prefetch twice. um We might be able to add some sort of like timing check on the intersection observer to see.

C

If somebody like scrolls really fast, you know make sure it doesn't doesn't refetch uh just because it like went past the viewport, um so there's probably optimizations around that to be done, uh but um I don't have specific numbers in terms of like how much load this would have would would would put on the server.

C

So sorry, I don't have an answer for your question. Lars.

D

Yeah no problem. Thank you.

A

So steven it looks like in chat there's some questions from chris on. You know how this will scale and the load that it places on the back end. I don't know if you want to check it out or christmas and jump on, so I don't have to interpret the question directly, but.

F

Yeah, I'm just like I'm trying to see how this will scale for like high traffic environments. If I have 10 000 active users on uncached category pages, I'm hitting like graphql 100 000 times at once, I'm just trying to work out like how that impacts. The back end load, because this could like significantly change that.

B

Yes, really quick, I I would probably like throw this on the edge cache. To be honest, like all of the catalog data can probably be cached, um so I mean that the.

F

B

F

Have a warmed, cache yeah.

D

And right now you guys don't.

C

F

And this is all post requests right now, still you guys don't catch any of this environment right? Yes, yeah yeah,.

B

So we're working on that to start using git for queries and then fastly caching will kick in and then these are going to be like two millisecond responses, uh somebody just profiled it but yeah it's like leaps and bounds better and then I think, like kind of the the concern here about uh overloading the back end, um would kind of dissipate, because the catalog is something that that is heavily edge cached and that first request. Yeah would take that one second, um but every request after that would be speedy. So, but it's only.

F

Speedy like for one product right, but if I'm hitting 12 different 16 different products on a page that are on cash and.

A

If I save a category, I'm invalidating.

F

The cash for that entire category and every page and every filter type in that category.

B

Yep I mean we, I mean, there's things in the magento cloud to like warm up the cache. um There are definitely things you could do to like get around this, but maybe maybe the better question is like. Can we feature toggle this on or off like if this isn't functionality that you want, we can make it easier to like turn it off. If that's that's the case,.

D

Yeah, it should be very easy to to remove the preload on the category page from developer point of view, uh because uh if, if you have a high performance case, what uh christopher describes there you don't want, maybe prefetch or maybe you need to pre-render already, but it's like yeah. It should be uh one hook or something like that. What you need to remove and then it should be disabled. From my point of view,.

C

A

I'll go ahead, go ahead.

C

Well, I was just gonna answer that so um we can make it really easy. I can pass a prop to gallery items that disables uh should prefetch or something like that um before the logic before this pr would have been much more complex to remove that pre-loading of the category of all the products on in the single category query. I know that that's not necessarily the concern that y'all had because that's I mean that's the way it works right now, so you know I I don't mind.

C

I don't mind adding that that prop at all, and then we can keep having that discussion. I think andrew wants to keep the demos going.

A

Yeah yeah, I was going to say this. It is really important feedback, though so, let's make sure we capture.

D

A

The pr for sure we continue the discussion in the pr on how to address it, but for the sake of uh the last two topics we have on the demo, let's, let's kind of keep moving here, um all right, so uh yep thanks steven and thanks everyone again, let's, let's, let's pick it back up on the pr and make sure that we we we close the loop here um up next, we have dave who's going to give us an update on uh on the obsessive owl's uh work on internationalization.

G

Great, thank you andrew. So let's say I wanted to do a big shout out to chris. um I think, he's in the cool as that pr. You did a little while ago, and that was a really great starting point for us to develop our ideas for localization in pwa studio.

G

So we spent a good long week me and my team doing a lot of investigation, a lot of research and trying to work out what the best solution was for pwa studio, and we started with the mentality that we want to do something the industry is very used to. So that's the the front-end industry, but we also wanted it to be very similar to magento developers.

G

So we were kind of building a solution for two different, unique groups so from our research there's, obviously a few competing libraries in the space- and I know chris used iat next in his pr, but from all of our research performance, testings uh bundle analysis. We found that the react intl library was actually generally smaller.

G

They both performed about the same so that was kind of negligible, and then we also saw that it seems to be widely supported in the community. This is kind of hard to judge really because the iit next library is fragmented across multiple packages, and then we have an internal discussion with adobe's globalization team who are responsible for globalizing our sas products, so the products that you would typically visit to manage. You know your creative cloud, membership or your documents and they actually used react-intl.

G

They had actually forked it internally to enhance the library, sadly, that library is closed source, so we weren't able to use that, but from based on all their research as well. You know this. This pointed us more towards this library choice and we intend to implement this as expected following you know, their guidelines and their documentation. So when you think of localization in pwa, studio, you're actually just doing react, intl, there's no special source, there's no weird magenta abstraction! It's just you can go use.

G

Those dots and 95 of those dots will will be true to how to use it in petabyte studio. So the next big decision we made was where we should retrieve those translation from so in magento typical development. As you're probably aware, you have dot csv files um within an i18n directory, so we wanted to explore how best to still get value from these, but not overcomplicate our solution.

G

So I know chris's original pr actually used the graphql endpoint to retrieve the translations directly from magento, but we felt for this first initial push that that would add a little bit too much complexity for the solution we want to get out.

G

So we opted to actually store these in the pw studio, app, which will actually be within the npm packages that the pwa studio app is built up with. So you know, venue will own its own translations for any strings present in that app um page builder is now an extension, so it would have its own translations too, and you know the main reason we chose those is it's simple, um it's very transparent of what it's doing. It's going to load some files and combine them together, it's going to be very fast and it's very predictable.

G

There's a single source of truth for all translations and it's within the app. So we also noted that you know there are, wants and needs for other ways of retrieving these translations. Getting them from magento is certainly not a bad idea by any means, so we certainly intend to build this part of the localization as an adapter, so you can build in new strategies to easily you know, grab them from magenta or even you know, hit a third-party service, which is one of those paid localization things.

G

um So this was kind of the best for everyone. um We want to be able to deliver this as quickly as possible, so this you know fits in with that that idea.

G

We also intend to do automatic, locale detection using a except language which is fairly common, and there will be a storm currency switcher which will have parity with luma in the way they function.

G

As part of this work, we are going to touch on some multi-store concepts, but we have a future um item of work where we will complete that so there will be some elements of multi-store created as part of localization, but we're trying to you know, keep them as separate as possible.

G

um So with that any questions or any more clarifications on our decisions here.

H

How easy is it to update or, like add, new translations? uh If it's a package, does it need to be your version or like something else.

G

Yeah, so we would most likely see language packs. So if you wanted to build a russian language pack as a new mpm package which would just be um you know, npm installed.

H

Okay, so just uh checking, um I don't know how localization is it like per word basis or like per sentence spaces like you have like hello world, for instance, is it toast translation? So it's just one translation.

G

It's perfect: you can't translate uh single words, because the sentences wouldn't make sense. You need to translate the whole phrase.

H

Okay, the phrase: okay, okay, um so I was like thinking like how often would it happen that people would like to add new translations and how many versions are like how many times they have to redeploy their app uh just to get new translations into the app uh or like a new language set? um Yes, and what that happened is just checking.

G

All of those things with deployments right now in magento anyway, so they would continue to be builds and deploys in pwa studio, translation shouldn't change over time. The only times they would feasibly change is, if you've done development to add a new feature there or install the new extension um all of your entity data like products, categories, cms pages, you still localize- that in the magento admin. So when graphql requests the page, if you've translated it under the specific store, it will get the correct.

H

Version I have one.

D

I have one question about uh developer experience there. uh Currently we have already many uh language pack build for magento 2, but this is in a c5 format and I don't know if we can provide some converter or it's possible to uh have some migration part, because I think some translation would be the same in luma and vineyard and from my point of view, maybe we can reduce them or make it very easy to move this translation to to um our own language pack.

D

This is uh maybe one thing what we can improve there or it's. I don't know.

G

Yeah we highlighted this we'll definitely explore building a tool to translate these language packs over. You know, react intl typically uses a json file, but it's still fundamentally just a load of strings in a file in a certain format. So going from csv to json is super easy, so your converter would definitely be on the table.

D

Cool. Thank you.

A

F

Within a local project, how are you emerging in um the package translations with the local project translations.

G

The package in local translation, so we are still in the discovery phase, so we haven't built these pods yet, but we intend to use special features to allow modules to declare um additional translation strings so kind of following a similar pattern to how many as its module translations in each module. That makes sense, um and then it merges them later on so right now the local translations would need to sit in in a package somewhere. um So it depends if you typically would create an external npm package for your customizations or if you're, just editing.

G

You know venue directly if you're using venue directly, you can just modify the translations inside that directory.

F

Right so you're putting in venue concept or you're putting in like vendor ui, uh they will.

G

Be housed wherever the streams are located, so I believe it's in whichever one of those all the files are in.

F

The new ui, which means you can't modify directly because that's installed into npm so like and we need to be able to so one of the typical use cases for translations is just like simply renaming strings across the magento front. End like one of the common ones will be like wishlist right, that's a phrase that is commonly translated, it's like favorites, and you would just do that with another english in your theme.

F

So in like your structure, how would you do something like that.

G

So we have that concept baked into how we intend to build this, um so we would use the build bus ordering to when we have key conflicts when merging all the translation files. The similar to how magento does the one later on in the order would become the priority. So if you had a npm extension that wanted to you know rename wishlist, as you just said, you would make sure it's in the correct border after the new ui or a concept. So then it's key will overwrite the others.

G

That's similar to how magento works in priority.

F

Right, but I need to be able to do that in my theme, not through an npm package like in my venue concept. I need to be able to merge that in right and prioritize. What's in my venue concept, which isn't an npm package.

G

Okay, well, we will definitely explore that a little bit further and get you a more definitive answer.

A

Yeah, uh just for the sake of time here I'll step in again, because you definitely want to get to zelen here with accessibility. This there's obviously a lot of fairly large and future poor decisions that are being made here with around internationalization in the project. So we want to make sure that we're being very transparent about those decisions. Why we're making them how we're moving forward and we're getting getting that feedback from the larger community, so chris, obviously you're you're key and a lot of that feedback.

A

So again, let's make sure that we're picking up this this feedback loop in in the pr in this conversation in the pr um and then we we're continuing the the dialog as we move forward, um but thanks dave um again we'll we'll follow up, and then um we can also obviously also follow up with the community slack. um So without further ado uh james apologize, we saved some time here then it's, I think, if everyone's going.

D

To stick around with you.

A

For a few extra minutes as well, uh you know, while james kind of dives into the weeds here on extensibility and obviously.

E

We're gonna have some.

A

Some some other follow-ups as well: around accessibility.

E

No worries at all, so hello, everybody um is a lot to cover.

E

I think uh I was supposed to do this last week and I had a sort of a scheduling conflict with uh personal city stuff, renewing a license, and so by this time I think enough time has passed that I'm not totally sure what is the most on people's minds anymore, um but we've been having some internal conversations with other teams at adobe and they are definitely using the system in the same way that you folks, working outside the company are, and so I've had some interesting feedback quite recently.

E

Originally I was going to show uh the routing system and kind of how it's built up from the bottom up, and I can still do that, but I can also show something that I discussed recently um with an internal team and that I discussed with a certain community maintainer who can show himself if he wants to, and that subject is replacing components how we would do it, how we would support it with multiple components um and how we would do that without having to do too much work. um Who's ready for.

E

That come on, I just need, like everyone.

B

E

On everyone's ready, everyone's ready for that, uh okay, so I have uh an issue hold on. I need to get it working again come on.

E

um I have an issue where um there's all sorts of components in this app, I'm gonna see about sharing my screen.

E

E

Just another minute.

E

Oh, I already didn't have much time. Okay, all right. Can you guys.

B

See very tiny, yes,.

E

All right well I'll, make it bigger. So here's the main component, the main component, renders everything inside the the browser view. So we can see that because it's got the header and then it's got everything else and it's got the footer. The main component lives in venia ui that whole big list of components and yes, it lives alongside all these things, but it's not reachable from an external system. We know from the uh stuff we've discussed earlier uh that vania ui the package declares a few targets.

E

You can change the rich content renderer, you can add some routes so far, that's what we got, but there's no actual way to mess with these components, um and so the typical way that somebody who knows much about webpack would do. It is oh hold on one. Second,.

E

ah There it is.

E

The typical way that somebody would do it in the sort of the world of webpack is that they would just add a webpack, alias you can do that here in the webpack config, which is just part of the the venia concept package right. This is your pwa and if you want to replace one main component with another, you know you could do it in a way that you, you might find familiar, alias uh bento, venia, ui, lib components, main main dot js.

E

Let's replace that with magento vinnia, alts, main components, lib components, alt main.js, so I guess that would work, but there's a problem with that and the problem is that my alt components uh come on. Can you see my other uh project.

E

I've switched uh code windows. I want to make sure you can see yeah, okay, so gotcha. So in my experiments, repository which I've showed off before I've created an alt main component and it's a new extension package which I just want to be able to install and then it replaces the main component, but inside the alt main components I can make a webpack config js all I want, but it's going to ignore it. I can't change what pack config js from my extension.

E

So in order to get my main component to be replaced in this way, I have to add documentation to my extension. That says something like.

E

I know this is tedious, but put this in webpack config.js. After installing sorry.

E

Alias you get the idea. We don't want to have to do that, especially because we would like these extensions to be able to compose without making people update their code over and over again. So.

E

Unfortunately, because we can't use aliases, there's another sort of webpack related mechanism and I'm going to stop sharing so that I can show you normal module replacement, plug-in I'm going to share my whole desktop and you see it okay, I know we're lo. I know we're short on time, so there is a webpack plug-in called normal module replacement plug-in, which lets you replace one module with another in the manner of an alias and we can add webpack plug-ins because of the webpack compiler target.

E

So here in the package.json, I have added an interceptor and made a tap into the webpack compiler so that I can add a normal module replacement, plugin cool cool cool. This works basically and sure enough.

E

My all component, which, as you can see, just takes away the header and the footer has automatically been installed. I didn't need to do anything besides just install that package and then it worked it replaced, um but this sucks- I mean it's better than this than saying you got to do this, but this seems unacceptably low level for such a common operation for replacing a component, you have to get access to a compiler, you have to instantiate a plug-in. This is not great. um So what could we do about it?

E

um I want to encourage people to get creative with the um the targets and the apis that they propose to add, and one thing that you could do is we could start using something like this and we could add the concept to venia, and I we don't have time to demonstrate this whole thing, but here in the venia targets directory you could add a kind of a new target and let's call it.

E

E

Api and then in the interceptor, we would do something like this, um so let's make a component.

E

E

So you could do this for every single component into it manually right.

E

And then you would call the target targets webpack tiler targets. I think it's built-ins right. We got built-ins.

E

Anyway, you get the idea, so I'm creating this api and then I, when I pass it in once, I'm inside the webpack compiler targets own components, tap a.

E

Call I pass that component api and then people can call this and pass those things into the compiler, but also for the number of components we have. This also is large and sort of ugly, so we could do something even crazier, which is that we could go through the directory of components like.

E

E

E

You get the idea, so at that point, even though this is not the safest way to do it, we've actually automatically generated a an api with a single target that you could use to call a function which overrides any of these things. So this is the kind of compromise between being able to override anything automatically and being able to decide as the implementer of venia that that's capable of override, and that would make this less ugly, so a little bit of a shortened demo. Does anybody have any.

A

Questions yeah I'd just like to start off with or just jump in here and also add. This is a very large top topic, something that I think a lot of people are excited for, but there's a lot of, I think, a kind of time that we need to really properly go over it.

A

So we're looking at you know how we host the the right types of kind of training, uh labs or hackathons in the future, um uh with the community to make sure that everyone is kind of um educated on on on this kind of new extensibility framework. So I just want to throw that out there.

E

Yeah, I know that uh we have a lot more to talk about, but rather than do sort of updates on how you guys can get involved, I thought you might want some some real meat, some real interesting, actual implementation of things.

A

And since I know that we are now five minutes over our a lot of end time, if there are no pressing questions for james, we'll make sure to pick this back up if we even have to put it back on the agenda for next week, we'll do that as well. So we can go into some more of the details and some more of the weeds there.

A

I think that it's definitely a topic that I think people are interested in seeing more about. So we are now six minutes over. Anybody have any other questions. uh Any other comments for the team we didn't get to community corner, but uh lars are uh jordan's not here, but lars. If you have anything yeah, all right cool, you don't have anything.

D

We are already over okay.

A

Well, great thanks: everybody.

D

For hanging out next.

A

Few minutes um we'll see you all again next week, uh have a great weekend stay safe. Thank you. Lars.

E

Show off your own thing in the uh in the community chat because he made something even cooler all right.

A

Thanks everyone.

E

Thank you, bye-bye.

D