 All right. Hello everyone. Thank you for coming. Is that camera pointing correctly? That's how I gave them a hard time by like walking this way and that way Okay, so I'm gonna talk a little bit about Apart to accessibility right so right now a lot of the internet is not accessible to people in terms of you know blind or colorblind or Cognitively impaired and there's various strategies that you can use to resolve that problem what we are trying to do here is to include accessibility testing into your acceptance testing So that you will have a better understanding of whether you have successful or not just by running your acceptance test versus Running specific tools on specific pages and going through like lists of information yeah, and Yeah, at the same time we're improving Your testing experience by making more ergonomic and also this is my guitar panel Billy Bones and that's my face My online face Okay, so ergonomic testing Ergonomic end-to-end testing. What does that mean and how do we what are the key requirements for it? So firstly, we need our test to be stable So if we make a few changes to the way that our app looks our test shouldn't break And we want it to be decoupled from implementation so that we can actually write TDD Right if I get given a design, I should be able to write a test If I can't write a test based on that design then we have failed Right because the whole point is that you shouldn't need to know how something was coded In order to write the test to improve stability If you want if you you know bound to CSS if you bound to JavaScript in your testing it's going to make your refactoring life harder Okay, so what are the current approaches? So we have CSS selectors, right? This is the most power that you can have you can literally select anything on the page that you want But it's extremely brittle like you made refactor your CSS Everything looks the same everything works the same way But your tests all broken and you must go back and you must fix all those CSS selectors in order to Fix your application and it's a hundred percent couple to to implementation So it's gonna be really hard for you to write a test before you write the code Unless you like theoretically plan or your whole CSS layout before you write any code, which is very hard. I think So the solution to CSS selectors was data test helpers, right? So what this means is that we Throughout our code we can annotate it with like this is data test login input This is data test image and then within our test We just do data test selectors like this and there's you know, it's probably a few well There might be some sugar on that where you pretty much go data test save and that will give you like the save button And you can click it So this is stable and It's sort of coupled to implementation, right? You can sort of just annotate in your head like okay. This button is a data to save this inputs data test log in this Images data test test image and you can write your test with that. So you can do TDD with data test But as you refactor your code you got to make sure that you bring those annotations with you Otherwise it will break and also I call it a vestigial annotation because it actually does nothing for The customer or for the user of the application, right? It's purely there for developers and The first thing we do is we take it out the dome right when we make for production We just remove all data tests from everything So it doesn't really give much more other than adding some stability Then we have I'm gonna say Khabibara style Khabibara is the testing engine that we use for rails where you can click the save button so it's bound to the text which is a massive improvement of CSS and So it gives you the same stability as data test helpers as long as we as long as you decide that if my save button By accidentally becomes don't save that's a bug So if you consider that a bug then it's a hundred percent stable But if you don't consider that a bug then it may not be so stable. It's probably 50 percent stable, I suppose It's not compelled to implementation at all right, so you see the sign you can write your test The problem that we've had with it in the past that it doesn't always work Like you try to do something, but you can't do it and you can't really extend it that easily So you have to code exactly how they want you to code and also it's not available in JavaScript So if you want to write tests without the server, so just the accession says for your JavaScript code You don't have that power And then the last one is page object. So page objects is a pattern Which can be used with all of these styles of selectors? But basically you have a file which describes a page and then you interact with your page by using that description So instead of saying click save they would have a function from like page object dot click save button And then you can pass that reference that page objects around and everyone can call it And if you change the save button you just change it in one place. So it's abstracting a little bit further to make refactoring easier Okay So I'm sure we all know the refactor process But you do something which makes all the errors come you fix the errors until your test go green and then you happy Yeah, so this can also be applied to things like ear slant You can activate an error in ear slant. You can fix some of them. If you haven't fixed all of them You can then maybe deactivate it Or you can do ear slant ignore files. So, okay, I'm gonna fix this whole folder first and then ignore the rest of the folders So that's sort of the refactor process of linting your code It's gonna make sense soon. So With that in mind So introducing semantic testing for JavaScript Okay, so what is it if we want to access a UI element in a test We do so as if we were using a screen reader This was by an RFC that Jamie White wrote for ember And this is akin to the capybara style and the decouple from implementation So this is the basic rule that we apply when we do the testing and when we build a framework So previously we used to write tests like this where we use CSS selectors As you can see you can get like pretty unwieldy and huge We connect ourselves to the JavaScript implementation. So if we change some of those JavaScript notation everything breaks We need to do introspection to find out like is this the CSS selector you won't be able to know unless you like dig into the code We have this which is probably wet all over the place But all in all there's a lot of maintenance to do on a test like this but with semantic testing Your test becomes like this where everything that's you're clicking interacting with is In the design and it's just the text right so you just click the button you fill in the input you click this other button so there's something interesting here, which is a Requests server to track requests So what this does is that when you click continue all server requests during this period while this promise is completing Will be tracked and then taken from jest. It will be snapped short into a file and that way you expose how your application is interacting with the server as a by-product and Instead of doing that other alert thing. We can just use a certain alert which will find a Element that's semantically an alert and we'll make sure that is text is this and that the CSS is that so we've trimmed down the code and What we've done especially in this is we've Asserted the semantics of the application, right? So if you try to fill in something that was not a An input it would complain or if the way that your label was connected to input was incorrect It would complain If this was not an alert it would complain Right now some of them won't work like it won't find so I cannot find this thing But as we what you'll see is very configurable So as we grow and as we add more like code to this It will get smart and be able to offer alternative implementations fallbacks. I'm hints on how to fix your HTML And this is not connected to what's the rule of least power by Tim Berners-Lee Basically the TLDR of what it's saying is that if you build like a DSL because it's a lower level language you have The ability to Understand from a code from a code point of view what's going on in the application and therefore giving you more power like for example JavaScript Is a less powerful language than C, right? But because I'm Australian JavaScript we can remove memory allocation work from JavaScript engineers and let only the C people deal with that So this is also now with semantic testing, right? So before you you test with CSS which is the highest power But now you test with text which is a much lower power But in order to make that text work. We understand your application a whole lot deeper okay, so from inspiration of Lenses out there we basically provide a Rule file which you can modify So for example, you can specify a preset in this case like area compliant That means that it will only allow Selection of area compliant elements and for fines an element that's not area compliant while doing the selection process and the Finding process it will throw an error telling you oh your label is semantically incorrect You should fix that But obviously since we starting from not semantically correct and when it gets a semantically correct We need a migration path And for that there's a default preset Which enables a few rules by default Like being able to find your elements using the name attribute being able to find your elements by placeholder being able to support semantically incorrect labels to inputs And what will happen is that? Based on your rule configuration here the default rule configuration is that if If you use one of those fallback strategies, it will just throw a warning So you can look through your logs and oh this thing is we should fix that we should fix that but it won't impede your development process You can build custom finders. There's an API for that so to all the current finders uses API including the area compliant finder So this allows for extensibility on that and then actors Will so basically you find an object and then you act in the object So you find a button and then you click the button actors are for that This is also for things like for example in embo we use power select But with research that I've done power select is not semantically correct So if you wanted to support power select tomorrow, we could do that by making a custom a custom actor for it until the point that we fix power select semantic element and allow this thing to traverse the semantic tree to act on elements then we can remove the actor So this API is just to help us get to the end, but enjoy the benefits today And it uses the same way that you do rules in Iceland zero one and two as well Okay, so this is the example that I've been using where you have a semantically incorrect label So here we have a label that's targeting a div now labels only allow to target Form control so the correct way was that this label should target this input and so when you run your tests if You had it on throw era If you had the configuration to throw an error, it would tell you that control login was found through the invalid label for relationship And then you would be able to fix that But if you want to just be able to write your test and keep your velocity high You can set it to warning where your test will oh, sorry This was the warning one. This is the warning example. So as you can see your test passed So it doesn't stop your test from failing but allows you to find your mistakes and as you fix them those Logs should disappear But if you if your app was error-compliant and you don't want to go back into broken You can make a throw error and then it will just inform the user that this is the problem And it should be relatively easy to fix Yeah Okay, so this is what the HTML should look like correctly. This is the correct HTML and There's a lot of various like the way you do tables like how do you label a table? How do you label an alert yesterday? I find out that if you put a area label on an alert It will concatenate that label with this text when it alerts it to the user So for example, that's one way or that's one mistake that people might make that this library can Inform them about when they use when they do the testing So the current architecture of The package is we have the ember semantic test helper, which is ember specific So it's got blueprints. So when you go ember install, it does some configuration for you sets up a file with the configure function and Has all the access for ember and then we've got select semantic DOM selectors Which is the finding engine So this is the engine that either throws an error or throws a warning or doesn't throw anything That iterates over the finders to find objects And this is platform agnostic So hopefully we can get a similar thing to this for react and angular and view and anyone. It's absolutely platform agnostic Q unit semantic assertions allows you to do things like assert dot input my input exists or Has value x so you're able to assert the value of your DOM without introspecting into the JavaScript and obviously this only works for qunit Well, what this does is it uses the finding engine and it proxies all the found elements to qunit DOM And then Domda qunit Dom does most the assertions and we add a couple extra ones on top of that Which are more semantic specific Yeah, okay, so now I'm just gonna go a little bit deeper into the code itself So here we have three of the main functions of semantic DOM selectors you got find objects Find object and find element. So what happens that find object will just proxy to find objects find objects is a recursive function if I'm mistaken Where it will just run the say run itself for every single Finding strategy that you have until the array is empty And if they raise empty it will throw an error nothing found basically and if we find stuff It will just return to find object and find object will assert that only one object was found and This is I would say these two are more low-level APIs the more higher level API is find element now what's interesting here is that There is a label and type and method so don't worry about method so much method is just find objects or find object But type what it will do is it will go to oh This is not working out for me There was a plan Okay So as you can see here, we have defined. This is what a button is a button can be any one of these This is what a text field is right any one of these things can be considered a text field Any of these can be considered a toggle even double checkboxes Any of these can be considered like a select component. So These concatenations of that we've defined up here can be considered form controls So what we're doing is we're taking the semantic definitions of the web on the documentation And we're just codifying all that information In order to make this engine work So what I would do is if I wanted to find all controls I Would just say find element Find object and then the label that I'm looking for or the text Which identifies that and then type being form controls then that would mean that any form control will be found with that I do have right now. It's extremely coupled to Your basic semantic must be correct, right? So it has to be you know an input or a roll of input But I have seen opportunities where we could find generic divs So if you had a div labeled as my component and that was meant to be an alert if you went like find alert My component it would find it and give it to you so you can do assertions on it and act on it But also say the thing that I found for you was actually just a div and we recommend that you put roll alert or use this semantic Element to describe this particular part of your application So this is not built yet, but sort of my musings And same with the on the ember side so this should say ember semantic test helpers But these are the functions that you use in ember so you go fill in label value And what this does is it just proxies these things like type text type button type select to the semantic DOM selectors These are various links right now all documentation is an ember semantic test helpers You can use this as a source of truth because as I move documentation from here to here. There will be links to guide people through Okay, so what are the key features that we've achieved For me most importantly is useful annotations, right? So we had data test electors, which were useless annotations for Users of your application, but now when we annotate things you annotate things by using the area specification or the accessibility Specification and this means that when a screen reader uses our application it will work correctly So we've improved our testing and we've approved the accessibility of our application It's configurable and extensible So unlike with a capybara engine like you can actually easily configure this And I hope to build and have people work me to build like a large library of rules that we can use We completely decoupled from the implementation so we can get a design we can write the test no problem and we have stability Because what we consider change of text a bug, but you could use translations there There's some space for some work with translations here And we just need to know how that fits into the whole picture Yep Okay, so what success that we had from using this in Trey Gecko. So Now we reaching a point where teams can actually write TDD so they can do TDD behavior We write the test and then build the application and this will ensure that our whole application is tested Like I mentioned before we have useful annotations and what's most interesting is that it sort of created a culture of What is the correct semantic of using? HTML and What is accessibility? How does that work and now because we're using this as it's a conversation it's a conversation topic Which at the end of the day allows us to build a culture where we produce higher quality web applications Then we would have before and for me that is the best part of it all Okay, so this is sort of reaching the end here, but so what's the roadmap so we built a basic version for ember Extracting an engine so the next piece is to build more rules like the one I mentioned about Oh by the way, you use the wrong semantic for this element to be able to understand Custom elements semantic trees, right? So if you build like a custom select box like power select What is what is that correct tree look like because it's a couple of dumb elements Which needs to be all connected with specific mock-up and by understanding that we can create generic code which walks that tree and Makes and and can fill in any input on the internet and if it can't if that tree isn't correct It can tell library authors. Oh by the way, you did this You know, maybe you need to do this and this if as long as library authors can use a tool like this When we consume libraries our apps become more semantics Like it's gonna not be your job to connect the label to input It should be the job of a form library and the form library should make sure that it passes a semantic testing And yeah, so just like usage improving of the engine and most importantly feedback For people that use it out there in the wild to like tell us or tell me like oh, this is my experience This doesn't work. This does work and yeah, and then Yeah, that's about it any questions Yes Okay, yeah Okay, so the workflow is you tell ember semantic dorm select ember semantic test helpers I want to do this like I want to click some text Right, I want to click this button that has a text of this element That is described by this text. So what will happen is it will use Finders so area compliant is a finder, right? All of these rules are finder And you can make custom finders and finders will I have at least one rule if not more So the first thing will happen is will recurse over the array of finders until it finds an object and then it will Do a notification on the object and then it will return the object and then ember Semantic test helpers will then say okay any actors do you want to act on this object and then an actor will say oh I want to act on this object like for example Power select actor. We'd like okay this object I want to act on this and we'll act on it and if no actors are found Then it will act on it with a default action, which would be the ember click helper But yeah, that's about it Make sense. Yeah, cool Okay Yeah Oh this one. Yeah, so what happens is this will work on colors This will work on the computer final CSS style so if you have like ten selectors and like inline styles and They all apply colors like they will only be one that will win. So this is the one that will win will be the one that you assert on No, no does not It uses the JavaScript API and so this assertion is actually done on QUN a DOM So I haven't built this assertion All I did was build this which finds the object and gives it to QUN a DOM to do assertions on so Yeah Yeah Well existing right now elsewhere, not that I know of But with the extraction of the core engine There's pretty much no code in this file like 90% of the code is in this file So the idea is that like, you know, for example, Selva uses react He can build this for react. He can build this version for react by using this and write almost no code So ideally, I would like this to be in more than just the ember community Yeah, maybe I'll learn angular and Okay, anything else Okay, thank you very much Okay, shall we start? I'm Selva and you can find me at selvax in the social networks I built stubs at Tegaco emojis stubs mostly and on the free time I build some react stubs and angular and some react native as well So I mostly believe on inspiring getting inspired from the cross-community culture like getting the best from different communities and put into work so today, I'm going to share something about profiling ember apps that We did like few months back like we faced a huge memory memory performance problem in Tegaco And especially that was found that was actually blocking our test cases to run like it out this case never ran to the till the end. So We are we did some profiling stubs. We spent some like few weeks on it to actually Drill down the memory problems and be fixing. So today. I'm mostly going to share about it So performance Like for every software developer, we want to ship Performance apps like so it's also an inherent feature that every app must have like failing to deliver it So we'll cause our users to churn especially Also in addition to that performance penalty is going to cost us more in terms of maintaining it like we have to work around whenever we face her performance problems also we have to Fixing fixing performance problems is also quite costly so in JS world like The performance itself is a huge topic like I try to categorize Into two major categories. One is the load performance and others the runtime performance so when it comes to load performance the two important metrics are time taken to first meaningful paint which means we Show the users some meaningful content Which will increase the perceived performance like they when they load up when they load our app They feel they don't want to see a huge spender loading for a while So they just go to see a get to see a meaningful content. That's a tender on the screen in a mobile like We can employ fastboot to achieve this like you can tender the streamer on the server and so the HTML to our browsers So the second metric is time taken to first meaningful interaction Which means when you when you when you deliver some HTML when you deliver some content to the users The next step would be obvious. They will try to interact with it, right? So to in for interaction to happen. We have to load the JavaScript bundle so Mostly in ember apps that javascript bundles are quite huge, right? So we need to actually split the split up huge JavaScript bundles into multiple bundles Right now we have ember community has the ember engines which is quite experimental But still you you can able you will be able to speed the huge JavaScript bundle into multiple chunks so that you can actually load the critical JavaScript piece to Give the fastest interaction as possible so Regarding the runtime performance So the two important metrics I could see is like the rendering one So whenever the user you users actually play play around your app the Experience should be quite fluid, right? They shouldn't have feel any junk junk soil playing with your app. So the Goal is to have 60 frame frames per second. So as As front-end engineers, we we should like avoid expensive dorm data rewrites Like which causes reflow and repaints because those are going to affect our frame rates badly So the second one is memory monitoring, which is like we time to neglect quite often because Because jas takes care and most of the times like even our frameworks takes care most of the time that we Almost neglect the memory monitoring stuff But that that neglect neglecting that is actually costed us a lot So before driving into it, like I just want to give a snapshot on what is memory management, right? So when we load when we load our JS apps, like everything goes and sits in the users memory uses coming systems memory, right? Like the code we ship the data we load the objects we create everything is going to go and occupy some space on the ramp So it's quite important that we don't We don't cross the we don't reach unusual limits in our in the users in the user's device So the most of the Uphill task is taken it's taken camp by JS engine right and like our low-level languages like see which allows you to Which forces you to actually? Allocate memory and free memory when it's not used JS engine here does does the job for us like it creates it allocates memory when the object is created and Deallocates it when the object is not used anymore. So what will we do have here? like little in nothing But there is some role we have because it's like avoiding some memory leak mistakes like we often tend to Commit some mistakes that prevent the JavaScript engine Doing its own job like holding references to the dead objects. That's all not needed anymore, right? So So JavaScript engine actually collects the dead objects via a special program called garbage collector. So But garbage collection happens at a cost like when I'm gonna grab a collection happens like your entire app freezes for a while Nothing runs. So it comes at a high high cost, right? so so usually how the garbage collection works is like it starts from the root root of root object root scope and it What it travels is deep down and fun mark all the objects is that I have references as a live objects and Objects which are not live are considered dead and are not used to anymore. So browser decides when to have into actually trigger a garbage collection It is based on numerous factors like the memory of the device Also sometime. So there is no actually Define the definite way to save this is when the garbage collection happens. So So the problem because here is the to hold the reference of the dead objects from being collected by the garbage collector So that's called memory leaks like the few symptoms of memory leaks or like if your app is Started to perform quite badly over the time. It means that you are actually leaking some Memory you're having you're actually holding some references to the dead objects Which are meant to be like garbage collected. So if you Okay, so that's a one of the symptoms and also While working with Jaws good objects if you have to make sure that you don't create more objects than necessary because that would that would force the browser to trigger the garbage collection Quite frequently, which is not which doesn't come at a free cost, right? So where to start to profile memory manager. So the best tool is like Chrome's task manager. So I use from as a primary Browser for for my document. So task manager gives you Overview of how much memory you are tap each each in Chrome like each tab is a individual process, right? So task manager gives you a overview of how much memory each tab actually consumes So that should give like if the if that number is Unusual like if it's there if it's spiking to more than 500 700 MB then something is wrong actually So the next handy tool is Memory allocation timeline like this one is a part of Chrome DevTools You can find this from the memory tab So this is this gives you a live timeline Like you can record a timeline and play with the play with the app It shows when the memory is allocated and the memories when the memory is freed freed up the third tool is like a Heaps snap it's not it's actually a subset of the memory allocation time plane at a specific point of time So either of these two should suffice the same news So before actually Showcasing a memory profiling I want to share a few tips the first one is like Don't try to fix a problem on assumption try to identify the exact leak the That you anticipate So that you can actually measure your output so Before profiling use incognito mode or guest window So that your add-ons or extensions doesn't actually Intercept with your memory timeline so everyone is try to so Chrome DevTools has a force cabbage collector button try to do a cabbage right before actually taking a snapshot because that will cause the JS engine to collect the dead objects so Which means you have less thing to take care and this is an important thing like everything on the Snapshot is not a leak. So as I said like whatever you do. It's going to occupy some memory on your So the device right like your create objects your load data. So it's going to sit on memory. So everything on memory are not leaks so in Emma world You would like to you should actually inspect for objects with a destroyed flag So ember marks the objects are destroyed if it's not being used in anywhere anymore anywhere inside the framework So that's actually the key to the Profile ember apps So I have one one quick demo I'll just show to you Okay Yeah, so I have this app which is just a list and it what it does is Just a model with the details and cancel nothing else so Let me try profiling this one like memory So I do I'll let me refresh the app. Okay. All done So this is the memory tab you find two things to eat snapshot and this is the timeline of the snapshot So I check that So I forgot to initiate the garbage collection. So let me initiate garbage collection. Click it start then let me Do the normal actions usually the blue bus the blue bar indicates the amount of memory That's allocated during your course of action and the gray bus is the amount of memory that gets freed out like So in an ideal world, you should see a lot of gray bus instead of blue bars So I let me perform one action this one Let me perform few times So you see that so whenever I take a model you see there's a spike blue bar So an object is created which is fine But when I close the model that that component destroyed like it should it is not required by the app anymore So ideally that should be flat for garbage collection, but the gray bar is like not the full It doesn't it's not it doesn't match the blue bar, right? So there's obviously some memory leak further. I just top the profile I click on the Duba you'll find a Stack on that particular instance. It's quite hard actually to Profile everything like that's why remember our performance penalty is really costly a lid It's going to be time-consuming and lots of you need more patience over it so I Directly inspect the classes arrays or like native arrays like there will be like the stack is filled with system call system arrays Like there will be tons of information that you don't need that's totally unrelated to your app so here that I Directly go to class because our components are actually classes. So You see here. I have to work over here to actually see What class is that directly then just inspect the destroyed flag to so if you find that this object Is destroyed then it's meant for garbage collection, but we are still holding the reference reference to it and that's the reason It's not freedom. So yeah, we have to Find the culprit which holds a reference and we have to like fix it. So this one looks like an input Component which are which I had inside the model. So if you look at the code So this is the code I had See Cool. So this is a dialogue component HBS So when I click on the button, I just render a dialogue with the customer form in it and If I open the customer form you have those inputs on it so the Customer form on a whole it doesn't have any JS code. Yeah, so there are less possibilities that this one leaks memory So the main possibilities like the parent component is not actually dereferenced because of which the child components are also stays Stays in memory for a while. So if you check the parent component, I have event listener on key down and I have I try to remove the even listener on destroy Can anyone spot the what the problem this year? Why it's what is the actual line that actually What's the reference of the component even after it's destroyed is this code kind like did I try to remove remove the listener in the right way? Yeah, you're right This is like, you know the answer before I have discussed this like a lot of times with you Okay, it's fine, thanks So So add add even listener and to move and listen, okay So I try to register a function like I just try to register handler on key down But I try to remove that handler When the component is destroyed, but the culprit is like I do to have the discontext on the Handler I do a bind of this But what JavaScript bind function is does is like it returns it binds the contest and returns a new reference to it So it's not not actually equivalent like the one you register is not equivalent to one you unregister it So eventually you didn't you didn't you didn't unregister the right handler. That's actually causing a memory So right fixes to just copy this have hold the reference somewhere this dot let's go close model and I have this Here remove this here and I Unregister the same handler. So I believe this should fix it Check again So I let me refresh it Clear the existing one trigger garbage collection start Like let me try So it's time to at least remove most of it, right? so the the least part is like something related to detached home, which Which is totally a different topic like there's one more leak called detached dome which means our your dome references still hold somewhere and Even after even if it's not actually part of the render tree or the home tree And this is not actually a problem with our code This is actually a problem with the ember itself like they are there's an active discussion on discuss.ember.js.com regarding this and it is intentional and it is not meant to be like long live So this will be you can ignore that simply if you inspect that you can actually find it What's actually holding that? Okay, not possible here. I'll just do a snapshot at this point So if you check for detached home You can still find like that's been hold so The red color red background says you that This node object is being held By some other objects. It's not it doesn't have a direct reference to your code So this one is mostly like if you've taken this one is like that's tactics is huge. Let me try to have a small one Oh, man, this was a huge Everything is huge fine. Just ignore this one I can link you to the discussion that that's going on on this aspect and it's probably it's probably not a fault with our code It's good for now So back to the presentation, so I just want to share So it's one just one of one pattern that can cause memory leaks like there are like few patterns I could we came across in our ember code base that I used to share the one first one is the Prototypal link state leakage This means that you have class components and which means The the components gets instantiated whenever it's rendered right so Leaking the instance state into the parent class Which means any in any instances that are created henceforth will share the same state of the previous instance So I'll show some code maybe this one is the evenlessness leakage that we just fixed it third party libraries so It's quite common that we want to use some some existing third party plugins Because we don't want to build everything from the scratch like reinventing the wheel is not ideal always so When it comes to jQuery plugins, it totally falls out of the ember life cycle books like it's they have the one APS to create instantiate they have the one APS to destroy it right so When integrating that into ember component, we have to make sure that Whenever whenever the component is destroyed we have to make sure that we destroy the third party libraries as well using the APIs The reason is like third party libraries can have even listeners attached to the DOM or anywhere for the plug-in to work So the they probably they expect The probably they would expose an API to destroy those even listeners and the next one is Having set timeout set interval run run later Timers so it's quite a there might be use cases like we want to have a scheduler call back Maybe like you want to refresh the exchange rates of your app like you want to fetch it like every 30 minutes, maybe We have to make sure that when when you move out of the route or whenever where you don't need it You just cancel those timers always that time at the handler in those timers might have The scope of the parent like we used to use this dot something do something then this is like a past scope of the parent So which get which gets leaked to the until the lifetime of of your app Modules scope leakage means right now way we use JavaScript modules a lot and This one is like having a mutable JavaScript module level constants Constraints at the top of your file. So we can avoid that because that's because it's the same It has the same effect as the first one protocol state leakage like having any shared object over there is going to be Reused among all the all the objects in the same file, right? So module is evaluated once for lifetime like once when the JS is loaded Global it's quite obvious like we don't want global variables to stick around throughout the lifetime Let me show some code. So this is the first one. I say I mentioned the protocol leakage So that one is a bad piece of code like a whatever you put inside the extent is going to stay inside the prototype chain Which means it's going to be shared among the instances of the component. So we have tags as an Non-tags as an array, which is a non primitive data type So we have an action called a tag when we when you try to push object to the Tags array it gets shared among the different instance of the same component. So to fix it use any tools to instantiate the Instance properties don't have it on prototypes In the in the class syntax, it will be like static So in class syntax, it's quite explicit that we we don't end up in writing static But in this one this syntax, it's not explicit like we end up having this kind of code throughout So the next one this one that we fixed like the event listeners try to remove it appropriately Third one is the jQuery third part is like we integrate a selectize on a text field Didn't submit but what we did wrong was to remove it on when the component is destroyed So make sure that you destroy via the destroy API of selectize This one the same thing like a set timeout If you have some set timeout Timers on your app that does something and we if it if it has a this context Which means this is the component itself is going to leak like unless you remove the Handless via clear timeout or number dot on dot cancel So this is the model level example Don't have any mutable data at the model level. That's totally a bad practice because If a mutable data is modified from one of the components, then it's going to be affected on the other components as well So never do that and never don't use globals as well. So Fixes to just use the instance Instance level properties on in it Okay, almost at the end summarizing like Don't set as a tumble don't set non primitives on prototypes because that's going to cost state instance leakage Plus it is it will bite us heavily on test cases Because when you run the same component integration test multiple times, you're going to have this chat state between your test comes Second one, this is quite a good rule like don't pass the entire component reference or controller reference around that Like we do this like we create a component and pass controller to inside a component Which is not a quite like we shouldn't be doing that why a component should know about the entire controller which controls the state of the template so the Solution is to use either guys. He'll yield the public API of your components via a hand hash helper Third one is clear the time intervals all the timers even listeners and third party libraries Final one is not actually as a memory leakage problem It's like a more of memory optimizing Point like don't create objects unless it is necessary Also, don't increase the life cycle of an object because more the objects is there then It would blow the memory and would trigger cabbage collection, which is not free And that's it. Thanks for listening And more importantly, this is not applicable only for ember apps It's like framework framework optimistic at least about that point like do it for JS talks. So The pattern applies for everything Any questions Yeah That's good thing, but I'm not listening to the key down of the company. I'm listening to a key down of the window Okay, but using key down of the components doesn't need you don't need to undigested No idea, no idea. I just said it's depends on various factors like the device RAM The device RAM are available space. It's really not different. So you can't say that this is the time it's going to collect Yeah, it chromed out of patrols. Yes, not via programmatically any other Yeah How and face Mary Paulson Anything Thanks