Web components and micro apps, the web technologies peacekeeper – Yaser Adel Mehraban

all right let's begin hello everyone hello that's better how many people from Oslo are here oh nice so this is becoming my tradition I want to take a photo of us but I need a favor from you I want you to do a crazy move while I'm taking the photo please and here we go all right come on one two three thank you I'll share this later thank you so much for coming along we're going to talk about micro front ends today but before I jump into the topic it's a lovely city I love your city it's it's been magnificent so far for me especially this is my first time in Oslo I've been a couple of NDC's but this one by far is the most exciting and scariest so if you see me stumble upon something please forgive me so mantra front ends or motor apps are basically it's it's not a framework it's not a library it's a technique it's a way that allows you to implement your to structure your front-end in a way where it gives you all the goodness of microservices in the fronton wall however when it comes to statistics it's not that popular and there is a reason for it it's way damn hard to implement there are many ways of implementing micro fronting some of which we go through today but the fact that it's not that widespread it's because many teams have implemented in many ways some some of which are successful some of which are not so they had to roll back to the previous version of their system but hopefully at the end of today you will be motivated enough to go and explore the last option not the middle ones so let's see what's on the agenda today we're gonna go to a short intro a quick intro on what it is then we will have a look at core ideas behind micro fronting or more crabs then I will introduce you to ally and her team and what issue they were facing for the product which trials they did try and work what some of those ways and their pros and cons of each of those ways and the final solution which is really in the most important bit for this talk and also in the motto fronting world before we go into the talk you probably should know me first so my name is yessir I'm a lead consultant at ratify a consultancy back in Australia I was expecting a bit of chuckle but that's fine it's far far away it's been crazy coming here but it's totally worth it you can find me at Twitter your since I've also got my own blog and I've started to cross post my blogs on dev community which has been taking off pretty cool so check it out a disclaimer I absolutely love monolith what a good money in fact I believe that if you can write a good money you wouldn't be successful implementing module front ends Martin Fowler has a quote about mark services he says if your system is not complex enough to manage as a monolith don't even consider micro services I've done some manipulation to this code and this is my version if you can't vertically slash your system to be able to have isolated apps from data store through the front end it's probably not a good idea to move to micro fronting because it just makes stuff more complex so one of the core ideas behind Matra fronting the first one is development speed you want to deliver features or fix bugs really really fast you don't want to for example wait for a deployment I don't know every quarter or something to be able to deliver a new feature so this is the very important one next bit you want is team autonomy you want your team to be autonomous to be able to move at their own pace to be able to develop at their own speed and also deploy at their own pace this is very important it has to be customer focus you don't want to add something which doesn't add value to your end users you don't want to implement something you don't want to spend time on implementing something which doesn't add value to your customers so it has to be customer focused and one of the reasons why mantra fronting help the customers at the end of the journey is that it allows you to deliver all of those features to the customers really fast and in isolation which we'll see and the last one is each team should be able to pick their own technology or tech stack to implement whatever they're doing they wouldn't be confined to a particular library or a framework to be able to operate they can choose whatever they want however as we all know there are heaps of many different libraries and frameworks in the fronting world as David said before one of which probably has been born five minutes ago you have to check it out but the fact that you can do it it doesn't mean you should do it and we'll see where it works and where it doesn't work so I want to introduce Ali to you she is a product owner and a company this is all imaginary by the way don't go look it up it doesn't exist his she is running a product for a car dealership with her team which is called car Cielo I just made that up if there is a company out there with this name disclaimer this is not that it's it's a completely made-up so what's happening here with ally and her team is they have this product people can come in search for a car and then they can order that car through the same good app they can do the payments even or get for example a car loan and then go through the whole process from the same app but the problem was they were having like one dealership everything was fine they started to open up more dealerships and then things started to slow down they had also the request from also customers they also had partnership with other dealerships and it just got worse and worse so what was the issue the issue was they had a pretty basic three layered structure Mauri nothing very special about it it was like a data store a business layer and the front end what fixing a board or adding a new feature took probably about one month to be able to deliver that process including testing and user testing and deployment so she thought now we're not gonna do that she went on search and they came up collectively with a set of criteria they wanted to meet for the Florida and here are those criterias so with the current set up they didn't have any team ownership they couldn't develop or deploying independency they couldn't run independently and so on so forth but they had some benefits like the corporate identity implementation was fairly easy because it was the same app sharing say wasn't a problem spool user actions yep it was the same app nothing special about it native support was good but was it enough now they needed to do better than this so Cavin google they found the chair micro-services they became interested Darren and try to implement mark services so instead of having one giant team working in the same product they started to break up those teams into smaller teams every team dedicated to a particular feature so they had the order team search team inventory payment order whatever however when it came to fronting it was all the same it was the same monolith every new deployment will result to the same results as before it was a bit faster because each mark service could deploy independently but at the end of the day they all had to wait for the fronton so fronting was the bottleneck so in terms of criteria nothing happened everything was the same although they had actually a good structure to move to the front Matra fronting ball so they thought okay let's set up a vision and move towards that vision and this is what they had in mind so they wanted each team to own that piece completely from all the way down to the data store to the fronton every team was responsible for delivering that particular feature if a bug was raised if a feature request was coming they would know which team is responsible everything was triage pretty fast bug fixes were deploying pretty fast so this is the vision they wanted to go now why this vision works is basically comes to these two sentences if you want to go fast you have to go alone so every individual team is responsible for that particular feature which means they can pretty move move pretty fast but if you want to go far if you want to add more features to the same product you all these teams have to work together so that's the next bit of puzzle so although every team was responsible all of the team needed to collaborate together to be able to deliver the same product so they started their first attempt they separated those apps through the Markov to the fronton as well and they started to use – links to link those apps so they were completely separate apps deployed separately run separately and they were all having links and it's pretty simple basically you had a hyperlink in a page it will redirect you to somewhere else now that was the first try it wasn't bad because that gave them some structure they gave him team autonomy they could develop and deploy independently but it wasn't fast loading every link that user clicked will result in the whole app to be reloaded so it wasn't really that fast and also they lost ability to implement the Corporal entity properly they had to use some packets to get that working sharing state was basically through URL and that was an ideal they couldn't do modular and this modular is basically a six module implementation by the way and user interaction was a dead spoon user had to wait for the whole app to reload it every time they click on a link but nature's food was still there so they look back so now we're not going to happy with this we will have to do something else so they random explore other options to implement the same thing in different ways and there are a few options as I mentioned before you can have real time integration for all those separate apps you can have client-side or services integration at one time so instead of using Build time you do it at dawn time either on the client side or on the server side some of big companies were following this approach like one of these approaches are like Amazon the Londo hellofresh and also ask at 24 they are probably the first companies who tried some of these approaches and if you go have a look at their they've got blog posts about their experience and they share their mistakes and what happened and how they got where they are today so it's pretty amazing check it out but let's go back to the bills time let's see what the bills town looks like at the end of the day there are many ways to do it but the most elegant way is probably using NPM package so every app will produce an NPM package it will add as a dependency to something else it can be another app or it can be a umbrella like an app shell which then puts together all these and then you will basically build everything into the same app deliver it to the client seems easy it's fairly easy to implement you can use it through web pack roll-up what about the bundling we can use and the experience is same as before that you read the model it but this time the teams are separate so every team is working on their own product part before so when it came back to the criteria they had some sort of team ownership but they had to collaborate through one team at the end which was the umbrella or tomato app they could develop independently to some level but they lost ability to run apparently because it was all the same app again and then deployment was again through the app shell so they had to wait for everything to gain deploy everything together and fast loading everything was bundled and they had also technologies implemented react view and then the result bundle was like so bigger than the monolith before so it wasn't really fast but again a couple of things that they lost through the previous experience so all of these resulted in them being not happy with this approach anyway they said okay we're gonna try something else so they move to service or include service our composition service our composition is possible with two major ways there are many ways but the two major ones are service all includes which is not something new in fact I have found that reference in a book which is published at 2000 so it's pretty old and it's nothing special you have some tax in your markup when the client sends a request to that particular page the server looks at these tags it knows how to get that particular app or the particular resource and replace it with these tag sends it back to the browser and that's how it works but it's pretty slow because the server has to look up all the current markup plus link markups and then and then so on and so forth so this process takes a bit of time to do that a better way to do this is true each site includes and buyouts are we don't mean browser each side is like a server which is responsible for answer in the browser at the edge which can be a CDN server or nginx and then that server knows where to get for example the other apps from other places so if you have a markup for example which has a reference to search it knows that it has to get it from the search server who place it and then send it back to the client so it's a bit more elegant because all of those apps can run independently whereas the Saraswat include it's just one server running everything so it gives a bit more flexibility in terms of running and deploying independently but it has the same problem loading is not that fast loading takes a bit of time because this edge server needs to parse all of those markups and all of those individual apps can actually have tags which need to be parsed again and fetched again from somewhere else so when it comes to criteria yep they had team ownership they could run and deploy independently I wasn't fast loading again mentioned this before but they had corporate energy because that there and if they was at the same under the same app on the client side so they could implement some sort of corporate entity sharing staples in their heart anymore they could really share states from the client side through the server side as well but the user interactions weren't as smart anymore user had to wait for the edge server to go and which stuff and then come back so they said okay if we lack still the most important parts are about customer or about end user so how what we can do to improve that beam so they move to client composition clients are competition and clone clones are composition is available to two ways basically you can do our friends who here loves our friends everyone loves our frames I hate them but iframes are ideal for isolated apps if you have isolated apps and you want to run them in the same page our friends are the best but they have some basically drawbacks search engine optimization is not that good security staff clickjacking all sort of different issues which comes with our frames most of which can be fixed but then it's additional work so you don't want to do that and then when it comes to criteria again you miss a bunch of stuff which you don't want to miss so instead of going through this way and using iframes they said okay let's try the next one and this is the most important part of this talk through web components so web components gives you ability to make your app as a component and then reuse that component everywhere else you want to communication with the components pretty easy just normal as tributes in fact using web components gives you ability to create reusable components because you can simply say okay I'll have this search here I can reuse this search in this app and that happened whatever web components are basically around for technology or maybe concepts the first one is custom elements and custom elements are just basically a an internal element which are derived from the main HTML element the actual spec but they you can't customize them so you can have custom HTML template as see here you can use the six modules to deliver that particular piece of code or the most important part is it you can use shadow Don which gives you isolation so every component has its own isolation inside Dom which means that it can affect any other place so instead in terms of for example CSS it will be safe to use it even if you have separate CSS attributes and classes with the same name so they wouldn't affect any way anywhere else the API it's pretty straightforward so you can use typescript or even normal JavaScript the recommendation is to use top script because it gives you types so you can actually know what methods and whatnot is possible through the API you extend HTML element which is the base class for all the HTML elements and then you can have a constructor which you call the super to initialize the actual HTML element and then you basically attach to the shadow Dom which gives you a shadow root which then you can use to replace your template inside it so anything that you have it's basically inside that shadow root you can also ignore this you can have your web components to be add sort of shadow root shadow down but that's not really recommended then you use the custom elements of window object in JavaScript to define your element with a name and its class and then you just include the JavaScript file the result of the bundle and then use that tag it's pretty straightforward there are however some other methods which helps you because if you want to have all of those benefits sharing state authentication what's what not you have to be able to pass the attributes in to the web component and expect some changes so imagine that in the Search Search app the user is always changing the search term but if you want to recommend something like the inspire team or recommending some for example accessories for different cause if the car changes in the search result you want to reflect that into the for example the other app so the suggestions are based on the current car cars which are appearing on the searches all so that's how you do it through the attribute change callback for example or if you want to trigger an G HTTP request you get some data from for example the backend service you can use the connected callback and that's when the your node is attached to DOM or disconnected called like if you want to clean up some stuff so it's a powerful API definitely look it up but this talk is not about just web components we are basically fitting this picture this concept into a bigger picture how web components help you with the macro front-end web components by themselves are not enough though we still need something like apps shell which you mentioned before to glue everything together so imagine an app which has a header a footer it has logging for example functionality it has a little menu item there they probably switch the view they load a different route all of these are handled by the app shell an option knows where to get for example a particular web component from so if you are for example exposing your web component through an NPM package the app shell knows where to get it or if you just simply are hosting your fault on a live server which then needs to be fetched also app shell knows about it which will demo surely but people are not really using vanilla JavaScript these days they might probably use a framework or one of the major ones or there are some people still using jQuery for example or all sort of different libraries and technologies so let's have a see let's have a look at the framework support as of today angular has angular elements which is a wave exposes a web component so you can have a piece of logic an angular app or a mini app and expose it through as a web component which can be used later on in any other app I've got a blog post about having a react app as a web component so angular vice-versa using these techniques veal has its own weight using view CLI so you can actually write a web component through CLR it's pretty easy very very straightforward react unfortunately doesn't have anything built-in create react app doesn't support it but there are community solutions you can use or you can do it manually it's very very easy I'll show you in a demo shortly so if we went with this implementation what do we get we get basically everything all those criteria will be met it's very very exciting that we can do it as of today because previously the browser supports for web component wasn't really there but today major browsers all support web components so let's have a look at a demo just to make you simple let me just duplicate my display that's probably better so I've got an app here which consists of three different apps so I've got the container of the wrapper or the app show and then an angular app and the react app and the app shell basically fetches these which are exposed as web components forms it into the same app now if you want to let's see it in action and then we go through the code and explain what's happening so let's go here let's start this one so this one so these are three completely isolated apps which can be used standalone also you have but we just need this one so this is our app shell it's it's a very simple app you just type your name that name is passed as attributes to those child apps which are running independently and then they can react to it so you can actually send messages back and forth through all of those components that's how you do communications between all those components if you want to update them which are using the attribute change callback for that so I can change this for example to something else I don't know and then tell the components about it and then it gets updated here now the angular app for some reason hasn't started up let me just check that yeah it seems to be working with yeah seems to be working just refresh this all right there we go so if I update this to something else and then I can reflect it it will reflect inside those components which are completely separate apps and by that we mean so I've gone and created a index.html for all of those so you can run them in the parity so if I create on angular app it will load just the angular app which is a component inside its own app so if you want to run tests on that particular app independently you could potentially do that if you want to run that app independently and use it in multiple places you could potentially do that that's the power of web components and how can you I can help you so let's go through code let's all me the option option is pretty straightforward it's just a normal HTML page which has a bunch of salt CSS JavaScript and then sorry are the funky sure let me just bring up it's too weak just close that and that should do it thank you we don't need that thank you full screen is that enough pretty enough all right cool so what do we have here we have a script tag which is basically a function which communicates with the components and then we have these two scripts which are exposed to their respective servers so I'm running three apps run time and each app is exposing their relevant javascript file which I'm including here so these are the separate apps we just talked about you will need the web components custom elements yes far adapter if you want to have backward compatibility with IE 11 for example the ones that some people and if you're doing for example let me just come through here so if you're doing messaging you will probably have to instantiate those components and then pass a message to it so this particular function here is getting an element from the Dom which is like a div placeholder d5 foot in the HTML it is then creating the react basically it's setting a bunch of attributes like the name I mean then changes the event handler it just adds an email handler to it and Ivan listener which then you can just say for example this is what I want to do when that particular event is fired and same thing for here for basically reacts this is the container so it gets that div did the container div so basically if you remember that custom elements that define method where we defined before we had a tag name and a class this particular create element document the current element is getting that particular tag name which is registered using custom elements so when we say create element react element it will instantiate a new instance of that component and gives us an instance and then here we get the container which is the react container in this example we remove all the Chou's because we don't want to duplicate that component in there which also triggers the disconnect callback if you remember from those methods and then we add this new child to it so it's fairly straightforward same thing with angular so we create a new angular component in this instance and do the same for it and then attach it to that Dom node and this is basically what we get from that particular page so if this is an app shell it doesn't have anything to do with any of those components this is just gluing everything together it's a central app so the good thing about this approach is that if you don't want your for example if you have your search in the main page but you don't have order this app shell can lazy load that particular component behind the scenes for you so if you're for example you can use many other techniques one of which is guest:yes so if you want to predict where the user is going through the app you can use that library which uses machine learning and they are to detect the behavior of the user and preload those resources behind the scene for that particular user and the source is Google Analytics so it's fairly straightforward but this is the this is the power which comes with web components and this particular technique so all of those apps are separate so as we saw before running separately deploying separately the collaboration is happening through the app shop now if you go to the other one one of the for example the react app which is manual and that's the important bit about it I just have an index which is my react component it's basically as you saw it's got a template you see where I came from the template it's coming from this component so this is the component example component it's got some props and a render method which renders that HTML for you which is fairly just a bunch of divs and the image and then this index file is where the creation of web components from that component is happening so this is like taking that react app standard or is it so it could be used in different browser in different browsers and different apps as a standard version so react Dom exposes for example these two methods and online component at know which then gives you so you can use HTML to react which is like a community solution in this instance and all you need to do is create your component extended from the HTML element which we saw before so this is your custom element use the constructor I'm just using a mutation observer for the updates to capture all the changes and rear-end during the component behind the scene you can use the connected and disconnected callback to call react for example mount and unmount and then it's from there it's fairly straightforward so you just set props if you happen to detect the change in your attributes you just propagate that into your props into the react app and here this library which I mentioned before it was is basically acting as parsing that template changes and pass it to the react app from there you have the customer living define with all the react element which exposes that to web component if we have a look at the web pack config which bundles everything together it's just using babel loader in this instance which package is that the component to the main J's file which is our before and I'm also adding an additional HTML file which can consume that it's very similar to the app shell but I needed to be able to run this particular web components standalone so I can test it before it gets merge to the main app and if you have a look at the angular app on the other hand this is a bit easier I didn't use angular elements here because that's that hides a bit of logic from you so you get lucky of some magic things happening which then expose the web component so you better understand how it works before using one of those libraries all you have here is your app module and then you basically define your module you use this custom element component from the custom elements which is this one this is our custom element which basically has the template so it's fairly straightforward it doesn't even have all of those crazy logic which react I've had about prop changes and everything else to rerender the page and then from there you just to hook up to the ng do bootstrap which is called when the ng app is trying to bootstrap and then you just inject use the injector if you want to for example add any dependency or a or use the DI from the angular to inject any dependencies from there and you create your custom element pass it the element pass the injector because remember that although you have a web component exposed behind the scenes still the angular engine is running so same as react so all of those template changes rendering changes prop changes all of those are handles still by the relevant app so that's why in this instance you have to inject the injector as well because let's say you are injecting a service into your component web components wouldn't know how to handle that situation so you still have to use the angular engine for it and one of the reasons I mentioned before about being careful about using different technologies is this because you are still relying on all of these frameworks so your web component code includes some of this logic from the angular engine and the web pack for angular is pretty straightforward as well we have a look at this it's just an app you can expect I what you want to expose give you the path etc etc if you want have additional start sheets you can also do that now this demo was fairly simple in the real life scenario you will have a bunch of problems especially with the styling so if each apps is isolated how do you make sure that they all reflect the same look and feel when it comes to the same because at the end of the day user doesn't care what technology you use user that doesn't care what are you using for example for I don't know rendering your page or how do you bundle your app or is the app running separately or do you deploy separately user doesn't care so just use the app and the most important part for them is the UX and the experience which they have to look and feel and also interaction so that's the most important part so when it comes to those parts all you need to do is make sure that the experience for them is basically the same so you can use the same technique you can use the same web components instead of having it for all those separate apps you can break those apps down into a smaller reusable component so let's say you have a component library which contains I don't know input boxes form examples you've seen it in many different frameworks out there on github for example when they have it for ng bootstrap or other it'll react something something so all of those are trying to give you a set of a library of components which you can reuse which gives the same look and feel whenever they use it so every app if they want to show an input for example a password input they will have the same password input in all those places so it wouldn't be different from any other ones which also saves a bit of bundle size because the CSS is not repeated anymore you're reusing the same CSS stylesheets throughout the different apps so if you want to have a look at some of the real life use cases for web macro front ends we come up to a bunch of very important ones the very first one is if you want to migrate your current app into a different app into a different framework for example so let's say you have a simple single app you want to Margaret it from react to angular because you love angular in this instance you have the two apps exposed as web components but then you can gradually shift your features from the first app into the second app without breaking anything so the user wouldn't be affected by all of these migrations and at the end of the day if you end up with all sort of components using just angular that's fine too you don't need to use different frameworks because remember the bundle size problem fixing box you can completely fix a bug in the react component as I showed you before there is no other way to be dependent on the angular app that's a separate thing so if fixing your bug in the search feature doesn't necessarily affect something in the Aspire team or in the order team and then you can isolate those for example you can set integration tests for all of those to make sure that all of those the components work together so your integration test basically is similar to having that app shell glue everything together pass attributes to it and inspect what's happening inspect the Dom very very simple testing it is basically makes your life very easier and then you can reuse an entire app so if you have a search mechanism which takes input for example and then gives you an output which is a legitimate template you can reuse that whole web component in completely different product so not just reusing components inside the same app you can reuse the app in multiple products so all of those products look like they all belong to the same company in this instance and when it comes to every refactoring every change not just in the front and in the back end it's this one taking balanced decisions is the secret to success you need to be able to make these decisions in a balanced way you can't say I just want to have you react angular all of those but then expect to have a good page size load if you haven't done it properly if you're not doing lazy loading if you're not careful about how do you propagate your stalls if you're not careful the shadow DOM and how do these components talk to each other and also ID at the same time as I mentioned before you wouldn't even meet mantra fronting if your app is fairly simple like this is for very complex enterprise applications we're here talking about for normal applications a monolith a good moderate maintainable readable code in the same model it works fine you wouldn't even need to consider these techniques how'd it go with x all right so I was expecting to see everyone like this at the end didn't happen I'm glad that you're sitting upright I know that you're very hungry for lunch but time for any questions you might have do we have mic for all these I'll just act as mic yeah so the question is how do we deal with stylings as I mentioned before the best and elegant solution for styling is having component libraries and a master slide so imagine all of those apps which are using their own styles if a particular style is applicable to everything let's say similar to bootstrap so if you have a container class which forces a certain style for the main container in the page they all get it from the same store sheet so you will have to share that story for all the common components but they use build time integration trim basically bring those in and implement it but then the trick is how do we get in the real time how do you make sure that that's not duplicated for all of those components so you load one resource and then you load that resource inside each component which you can easily do basically let's say you wanted to call a back-end service like an API or you want to get an aesthetic resource to show it in a particular component that call can be done in the lifecycle of that component even in the connected space in the connected callback or in the attribute change method similar to that you can request the main starchy's than the component loads so all of those cells are applied to the same components they all look the same but they also can have their differences because they might have different controls which should look different in in a sense does that answer your question yep so the question is what is the authentication workflow in an Matra fronting wall as I mentioned before everything comes down to app shell so imagine that app shell is doing the authentication it's getting the token from whatever identity server using any authentication flow would work but then when it comes to all of those individual apps and how do they use for example if you're using rule based access control to show and hide stuff inside each app the app shell is responsible to pass that information that token to those web components through attributes so all of those get the same token which they can then act upon add some instances you might have also separate authorization for each component so you want to have the overall login for example but a particular app which should be only available for for example internal people that can have a second level of authorization to see whether this person is internal or external so it can have its own back-end which then does a second-level authorization for that particular user which is internal so if you have admin person sitting there watching a report or even doing some for example config changes for a particular dealership in this instance that can handle that can be handled by the admin app for example so you have your central login which is all you know people come in log in by Google or people come in log in by your own identity server whatever it is as your ad anything you can use anything the fact is how do you pass that information into those child or separate apps which is in this instance it's pretty straightforward it's just attributes you just pass an attribute that component gets it acts upon that particular attribute change so the question is what is the use case for a state management library the most important part when we talk about state sharing between all these components is you can definitely do that you can use our state management library and then get for example a particular set of particular sub sort of state passed it as an attribute to ever component right the reality is do you even need that it's all comes down to when we talk about auto-generated apps all they need to worry about is their own state and what is to be exposed to another app so you wouldn't even need a central state management because each app is managing their own state they can use their state management internally but at the end of the day it's just input/output you wanted to keep it that way because D if you go with for example the state management then your integration tests will be bloated because you have to take about all of those as well so you want to keep it simple each component takes an input gives an output regardless of how many times you do it you get the same result right it's pure functions basically in a very component world well you will okay the question is if you have if you want to use react for all the lot of all its components so let's say that you have multiple web components they all are using react the question is do you even need to have the app shell well at the end of the day you will need one component which manages other components right so you can't say I don't have a pure but I have a mother ship component which manages that which is again sort of like an app show it's okay so the question is in terms of smaller components like a input or like a combo box or I don't know very smaller components if you want to use react for these components it gets bloated at some point you have to basically repeat the same thing in same thing again my question to you was if you have those small components what do you need to react for those because remember the input it's just that you can assign an event handler to it change the input see what happens you wouldn't potentially need react for it when we talk about reusable components vanilla JavaScript will do and that's basically two lines of code in normal JavaScript you wouldn't need react for that react is basically for more complex scenarios if you want to have a for example if you don't have a custom elements with a particular template let's say you have a login form you want to share it with other apps so that makes sense you have to use react and then you can use the state management library large react Redux for example Redux forms to manage the form state on the client-side and then sync it to server and do authentication all sort of stuff that makes them to use react for example but for the smaller ones it wouldn't probably make sense so when we talk about component library that's just purely JavaScript CSS HTML nothing more because you wouldn't need a giant engine to manage that particular event handler for you does that answer your question anything else I don't know didn't hear your question so the question is how does this solution the motor front-end + web component solves the performance issue the speed load when we talk about page load speed so most of this stuff is a trade-off when we talk about performance so you gain some stuff you lose some stuff but in this instance let's say you have a particular page with three components they need to be loaded anyway regardless of whether it's a monolith or a separate app right the only difference is when you use different technology which makes the whole app a bit more bloated so you get an app which consists of for example three different frameworks and all those engines need to be loaded into the same app so that's that's a bit of a trade-off but at the same time imagine that app shell for example can lazy load something so if you have a in a quick example like you have a really long page your index page is really long so it's a scrollable page and you have a component which is hidden during the page load app shall definitely can lazy load that and just load it when it comes to view it's one of the samples when I have when I talk about performance and lazy loading especially for images so if you have a page where the elements which are hidden they're not visible at this point in time you could lazy load them later when the user starts to scroll so that's one of the examples the other example is when you talk about wraps and navigation if you're going from page one to page two and page two is using a different component for example page one can still lazy load that particular component so it's just read even the user navigates into the second page that's another benefit in terms of performance but at the end of the day as I mentioned before the fact that you can use a different framework it doesn't mean that you should use a difference almost it's just that how do you manage this balance decision you want to make every team can have their own stuff but if all the teams are using angular you just load the engine once you don't load the engine multiple songs for each component which basically makes everything smaller but if for example an app is used multiple in multiple products it probably makes sense to allow them to use their own take sack because they might have a different app which is using react and this component is written in react so that particular product is faster it comes to priorities and how do you manage those decisions anything else all right it's been an honor to present this topic to you I hope that this has been motivating enough go and poke around with this there are heaps of resources which I share shortly on Twitter and also on a short blog post about all of these if you want sir yes that will be in the github repo which I've created previously you can go through the source code I'll put the slides up there too and the other thing is there are multiple really good resources about motor fronton there are blog posts on Motty fellows website which got published three weeks ago two weeks ago there is a micro fronting org website which basically has the whole app written in multiple ways include web components and they talk about they haven't got to the point we're talking about styling but they also talk about a bunch of stuff that I've couldn't fit in the this you know short session so explore those options and make sure that you basically tackle this problem if your problem is complex you wouldn't need to spend heaps of hours on implementing something which is not going to be used anyway so definitely my advice just be smart as you are now and enjoy the lunch thanks for coming

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *