JS Nation

JSNation 2022

The Wind and the Waves: The formation of Framework Waves from the Epicenter

Our collective understanding of innovation is wrong. It may seem at first like problems are solved and innovations are introduced by a single point of light, a lone person having a eureka moment. However, we can see that for any major innovation, this is just not the case. For instance, let's take the story of who invented the computer. It may at first seem linear, like a single event and a single implementation was the start. However, it was not one but many steps forward. Maybe under certain definitions it was ENIAC, widely regarded as the first electronic, general purpose digital computer. There were other computers that had all these features but the ENIAC had them all in one package. That said, it wasn't binary. Colossus was also regarded as the first programmable digital computer, although it was programmed by switches and plugs and not a stored program. Binary being pretty important, maybe we want to trace it back to Aikens Mark I, which had binary principles but wasn't electronic. Each storage location, set of switches and registers were assigned a unique index number. These numbers were represented in binary on the control tape. However, the Z3 and Z4 were the first programmable computer. Atanasoff and Berry designed the first digital electronic computer, the first time a computer was able to store information on its main memory. But none of those would have been possible without Turing evolving theory, writing his uncomputable numbers where he defines what we now know as a Turing machine. But also Claude Shannon laid the foundations of information theory. His theories laid the groundwork for all of electronic communication networks. But also EDVAC, Manchester Baby, the franzy Mark I, and IBM all brought new developments to bear, all of which influenced important pieces of what make up a computer. But none of this would have been possible without Jacquard's loom, which was a set of cards to produce a pattern in a weave in a cloth way back, or Babbage, who created two mechanical calculators, one was the difference engine and the other was the unfinished analytical machine. Or Ada Lovelace, who invented the concepts of modern computers, including software and subroutines. She thought about how computers could handle any subjects, not just numbers, and that data could be represented in digital form and published the first computer program. But then this really does depend on your definition of a computer, whether you mean modern computer or not, because what would computers be without the computer chip? Jack Kilby and Robert Noyce unveiled the integrated circuit known as the first computer chip. Or what about when the prototype of the modern computer was shown in a research center for augmented human intellect, including a mouse and a GUI? And really, what would modern computing be without the development of Ethernet for connecting multiple computers and other hardware? As Matt Ridley says in How Innovation Works, the innovation of a computer can no more be pinpointed into a single product than one can pinpoint the moment a child becomes an adult. For even one of these pieces, we can see that they're interconnected and not just on a linear timescale, but also connected by what spectrum of innovation it pushed forward the most. And thus, we see that innovation is a system, a series of interconnected frequencies. Innovation is connections. Innovation is a network. Yet many talk about innovation as a light bulb turning on, on an aha moment that strikes only the most brilliant of creators. But even the light bulb was invented simultaneously by 21 different people in different parts of the world. Edison might have gotten that final patent over the line, but the innovation of the light bulb was slow, cumulative, and inevitable. Innovation is not a singular eureka moment. So what does it take to make an entirely new and useful thing out of things that already exist? How do we create a seismic shift out of things that were here before? We often talk about the waves of JavaScript frameworks, that single moment in time where a framework hits massive relevance. But we don't talk about what makes up a wave. Waves are not created on their own. They're created by a force of nature, the wind. And so today, as we talk about innovation in the industry, we're going to talk about the wind and the waves. I'm Sarah Drasner, and today we're going to talk about the formation of framework waves from the epicenter. So who am I to talk about this stuff anyway? Back in the day, I was a React developer. I came to a React rally in 2016, among some other conferences, and then eventually found Vue and became enamored with it, eventually becoming a Vue core team member. In September of last year, I took a director of engineering job at Google where I run web infrastructure, including but not limited to the JavaScript and TypeScript languages, Sass and CSS, web testing, including Karma, and a few frameworks, one of which is Angular. I don't personally run the Angular team. You can think of me more like Angular's grandma. And although I'm going to focus a lot on Angular today, know that what I'm telling you, know that I could tell you the same story from the perspective of a number of frameworks, as the point is that we all do learn from one another. However, what I think is unique and intriguing about Angular is how well it survived. It's shaped and influenced multiple JavaScript waves in ways that I think few fully realize, and in turn, learns and grows and is continuing to grow from those around it. So basically, when I see other frameworks thriving, I feel very happy for them, too. Which leads me to how did we all get here? And how did Angular play a part? In order to see where it's going, it's helpful to learn from the past and where we came from. But I'll warn you, this is a contentious area, and people might not always agree on some of these points. Remember how I said that innovation was more like a network or a system than a single aha moment? And remember how I said that Angular and others have stood the test of time? Well, none of these frameworks were made from thin air. The first versions of Angular and AngularJS was one of the most modern JS frameworks, and it drew inspiration from its predecessors, Rails and jQuery, neither of which I'd really categorize as a modern JS framework as we know today. From there, we have Ember, also in this first wave, drawing inspiration from Rails as well, Handlebars, which Yehuda Katz worked on previously, and AngularJS Spa capabilities. Then we have Backbone, learning also from Angular, but also MVP approaches, and Knockout, which learned from Handlebars and jQuery, introducing important concepts such as computed properties. In the second wave, we have React, drawing from AngularJS, but dropping the M and the C from MVC and focusing on the view layer only. It was also inspired by Backbone, and Redux, heavily adopted at times for state management, drew inspiration from Elm. The second version of Angular drew inspiration from the first, but also learned from React, and Vue took inspiration from many sources, AngularJS for some template and authoring and binding, React for a view layer only approach, Knockout for computed properties, and Elm and Redux for state management. Svelte simplified a lot of what came before it, drawing from many modern framework concepts, but leading more heavily into the compiler and simplifying some of the previous approaches mentioned with state stores. You'll notice that I haven't told you my bets for this third stage, because I'm not a weatherman. I will note that meta frameworks such as Next and Nuxt have become quite popular, and note that Solid is doing some amazing and potentially industry-shifting things, and, lastly, I will note again that it's impressive that Angular has lasted multiple waves. I mentioned that Angular influenced a lot, and it might be hard to see as sands of time tend to wash these things away. Angular developed Spas, first-class usage of TypeScript, test integration and harness, actually, even today, when you create a new component, you get all of this test infrastructure pre-built for you. Tree shaking, ahead-of-time compilation, and the first compile-time built-in internationalisation with zero run time overhead, and mature CLI-driven updates. That last one is really impressive, especially as I run infrastructure team at scale, those updates being so seamless is really important. That said, Angular does not sit or stay still or sit alone. One of those things that I've noticed in time is that I've spent with the Angular teams how humble and curious and eager to improve the team is. Angular is working on a ton of improvements right now and is currently inspired by Svelte's authoring simplicity, Svelte's approach to SFCs, Svelte's stores and simplified state management, Solid's reactivity, React's unidirectional data flow, Vue's animations, and Aurora, as seen, Aurora is in the Chrome team, they worked with Next.js on an image component. We are also subsequently working with them as well. So you may have noticed that improvements to Angular's external feature set has halted over the last few years, calling into question by many, has Angular stalled? The team has had to pause on some of those features due to Ivy. You may or may not have heard what Angular has been working on for many years. Ivy was a massive ground up rewrite of Angular's renderer. Ivy was our exploration of how to build a framework that can evolve over time, shipped in the last year. You can liken this update to what many of you React OGs will recall, an update called React Fiber many years ago. The team worked on changes to the rig reconciliation algorithm under the hood. And recently, Vue did an upgrade of the internals as well, called Vue 3, rewritten in TypeScript and a complete rewrite of the reactivity system. What do all these under the hood rewrites have in common? Well, they have massive gains but a slight tradeoff that some other work on the framework can slow for a time. However, Ivy brought with it a bunch of great improvements. For instance, we've seen an improved code base organization since tech debt has decreased and the code base is more organized, which makes it much easier to do more improvements coming up. Angular language service has allowed for better integration with IDEs like VS Code and improved syntax highlighting and more informative tool tips. We've seen significant speed improvements as well as bundle optimizations and stricter checks to test as well as improved compilation errors. Here's an example of that last one. Let's say you add a component without fully registering it and there's now more CLI information about what is missing and where so that you can spend less time debugging and more time being productive. Now that these updates are done and Angular's evolving, that brings us to today. We're focusing on two major themes, advanced features and simplifying development. So in that advanced feature set, today we're going to talk about strictly typed forms, advanced styles, resource inlining, updates and error handling and streamlining page title accessibility. First, let's talk about strictly typed forms. One of Angular's nice features is built in form validation. You can see here how easily I write and build in reactive form validation in only a few lines of code with no external library or setup. However, in previous versions of Angular, even as I wrote this validation, the type was cast to any. This is a shame given the strength of TypeScript to do this kind of evaluation. So in previous versions in Angular V13, you can see that that form state is any. You can see how many people have asked for this. We've got almost a thousand thumbs up in this issue in the repo. Oh, no. But have no fear. We just added a feature that is both something that should be improved and something that's way ahead. Angular already has form validation baked in and now we leverage our usage of TypeScript for strongly typed forms and validations as well. It's Angular's most requested feature now shipped in V14. We now get great insights in type checking in our forms, making the debugging and developer experience much more powerful without having to add any external libraries or interrupt with TypeScript. Let's talk about some of the advanced features that Angular has for styles and resources like components. So one great new feature is that you can now add inline Sass styles without a ton of config. For instance, just dropping this into a component. It offers sophisticated effects like this with just a few lines of Sass mixins directly inline. Or we now have built in Tailwind config. You can add a Tailwind config file that will register in the application, allowing for seamless integration with Tailwind's libraries, which enables teams to build UIs with great ease and speed like this one. Which brings us to another feature that's great for performance resource inlining. Let's say we want to add a style sheet to our application. We can do so, but notice that this is render blocking, causing users to wait for everything to load. Similarly, for fonts, we're downloading the font family every time we serve this request. But with this simple addition to our Angular JSON, we can now see critical fonts inlined in a style tag, and our style sheets have now been updated to load asynchronously. Awesome. I already mentioned that Angular has been ahead of its time in terms of updates and migration, but ng-update and ng-schematics has recently been worked on to provide even more detail and useful information. Some of this is due to the fact that Angular runs at scale, and for such projects such as Google Cloud internally, Angular has some of the most sophisticated upgrade functionality in the industry. Within Google, we do what we call LSCs, or large-scale changes, and we use ng-update to transform the codebase seamlessly, providing sophisticated logs and error reporting along the way. That means that Angular can continuously improve over time with smaller risk to its users. We learned about breakage the hard way, and codebases aren't littered with many different ways to do things and write components, which is often the case when upgrades happen in large codebases where people don't have time to update every single component and everything still is backwards compatible. ng-update plugs into the same AST we used for TypeScript, and we've added enhanced template diagnostics which give great error detection, especially for common errors that could potentially be difficult to debug for people first working with the framework. Here we see a binding error that we affectionately call banana in a box, because banana is delicious and arguably the funniest fruit. Other better error messages include nullish-coalescing errors and tree-shakeable error messages. We now have new runtime error codes. These error codes make finding references on how to resolve the errors that you might encounter. This includes, this allows the build optimiser to also tree-shake error messages from production bundles. Angular CLI now offers autocomplete functionality as well, which keeps developers in the flow of their task more readily. Another really important feature is streamlining page title accessibility. This is important in SPA approaches because without intention here, the title of each page would remain the same, which is the first thing a screen reader reads upon root change. As of v13.2, Angular Router now offers a streamlined new title property that helps people using assistive technology understand the content title and purpose of the page. You can also create more complex logic for dynamic and conditional page titles as well by extending the title strategy. Okay, we just talked about a bunch of different improvements and advancement. This brings us to our next subject, simplification of development. Angular's v14 is just the tip of the iceberg in what we're taking on to make the developer experience much more seamless. In it, we're offering standalone components where devs no longer have to worry about writing and update ng modules. For those of you unfamiliar with Angular, you may ask, what does that mean? Here's an example of a lazy loading component. Previously, in ng module, we'd have written our imports and then we'd get to writing our routes and our routing configuration. Today, we remove a ton of that configuration. We just focus on our routes alone, writing our lazy loading component like so. Today, we have a number of these types of improvements rolling out, streamlining the developer experience and removing a ton of overhead for code that people need to write, learn, and build. That brings us to the future. After the Ivy completion this year has been an avalanche of these smaller quality of life features. These improvements are just the beginning. Next year, Angular is tackling larger developer experience gaps. What I presented today is really just the tip of the iceberg and what's under development now are some larger strides forward with this framework that I can't wait for. Next year and the years to come are going to be really exciting. Aside from that, the core team has grown, which enables us to hammer on some outstanding issues and pay down technical debt that this humble and hardworking team is really proud of. Coming up, you'll see a lot of really great improvements, many of which, as I mentioned before, are inspired by the great work of others in the industry. An easier and simplified API, including state management inspired by Vue and Svelte. Revamp of the reactivity system inspired by Solid and Svelte. Improved performance, image components, script loading, working with the Aurora team in Chrome, addressing core web vitals. Better hydration and SSR inspired by so many people in the industry. Better stack traces, better accessibility, more reusable, headless ARIA primitives, and a documentation revamp with new interactive onboarding and examples. Angular both pushes the web framework ecosystem forward and also learns from and is inspired by those around it. And this is how we all evolve. It's never in isolation. It's by learning from each other. Thank you.


Sarah Drasner

TestJS Summit

TestJS Summit 2022

Unit Testing Angular Applications

Hi, everyone. Welcome to my talk about unit testing Angular applications. First, just a quick intro about me. So my name is Filip Voska. I am from Croatia and I'm working at Infinium as JavaScript team lead. Throughout my years, one thing that I've learned is that you really want to be writing tests for your code. Nobody writes perfect code and you want some confidence that it's running correctly, that it's doing what it's supposed to do, and that's what you use testing for. So quickly, to go over the topics, we'll take a look at what are some of the ways to test frontend applications, what are some specifics to testing Angular applications. Then in third part, we will take a look at some best practices which are not really necessarily related exactly to Angular, but they're also concepts that you can apply in other frameworks. And in the end, we will have an overview of some of the things which you should test, which you shouldn't test, and what's the next steps, what are some educational resources. Okay, so let's first take a look at what to test. If you go online, you will probably, and you Google testing, you will probably see something related to the testing pyramid, and it's what describes the ratio between unit integration and end-to-end tests. So in, let's say, the most common version of it, people say that you should have the most amount of unit tests, then a bit less of integration tests, and then even less end-to-end tests. Now there are variations of this where some say that you should have something like this, which is like a testing hourglass, where you should have, let's say, equal amounts of unit and end-to-end tests, but a little less integration tests, and then you will also find this sort of shape, which is some kind of vase where you can put flowers in. And yeah, those are all kind of different philosophies, and that's all a topic on its own. We won't go into details about that. We will just take a look at what matters for Angular. And for front-end applications, you have usually a choice between Jasmine and Jest. Those are two most popular testing frameworks. With Jasmine, you would also use Karma as a test runner. Jest is kind of all-in-one solution. And Angular ships with Jasmine and Karma out of the box, but it's also quite easy to use Jest with it. Then for end-to-end, you have things like Cypress, Selenium, Playwright, and these are all ways to run an automated browser, where it's an actual browser running your code and you're simulating user behavior. So I will be focusing on Jasmine today for unit testing. I will not be covering end-to-end or integration tests. Now integration tests, you can really do them with any of these tools, because the line between end-to-end and integration and unit tests, it's kind of blurry. It depends on what you define as a unit and how many units are involved in a test. So what is a unit in context of Angular? Well, Angular is mostly composed of different classes, and those classes can be like components, directive, pipes, modules, services, et cetera. And then you also have functions like regular helper functions that you might have. So mostly we are talking about testing classes in Angular and creating instances of those classes. So let's take a look at some of the tooling which Angular gives us that makes testing and creating those instances a bit easier. So this is a component which we will be working on. It's quite simple. For those who are maybe not familiar with Angular, Angular consists of a class component that has inputs and outputs, and these are the ways that the component can communicate with parent components. So parent can pass something via input down to the child, and the child can basically emit an event back to the parent using an output. And in our example, we have a really simple component where you can see in the template on line four, we render the amount of time that the button has been clicked. And on line six, we have a button with attached click handler that calls some method, and that method is defined in the class, and it just increments the counter and emits the event to the parent. So this is one of the most basic components that you could have in Angular. So let's take a look at an anatomy of a unit test. And this is really the same in both Jasmine and Jest. There are some other differences between them, but this is really the same, and this is the same in many other languages, I would say, as well. So first you define a test suite. So we are defining a test suite for counter component. We use describe function for that. Then we have some, we usually have before each. Before each is a piece of code which will run after, which will run before each test, each individual test, and here you would set up some state and some initial state. Then between lines four and six, we finally have one individual unit test, and it's usually, it's using function it. It's a bit weird naming, but it's called like that because the way you're supposed to read this is counter component, it should do something. So that's why the function is called it. Okay. So let's expand a bit on this basic scaffolding for the test by adding in some Angular specific things. So here we have component and fixture. Component and fixture are related. So fixture is something that has some extra methods and helpers that make interaction with the component a bit easier in the test, and it allows us to query some stuff as we will see a bit later. And the component is the instance of the component class itself. So that's, we will have references to two of those and we will be using them quite a lot throughout the tests. And then on lines 11 through 13, we set up a testing module. So Angular components are run inside of a module, both in runtime and in tests. So here we are setting up a testing module inside which the application, inside which the component will be running. Here we define any dependencies that the component might have. Here we're dealing with a really simple component which doesn't have any dependencies. So we just import that component. Then on lines 15 and 16, we create the fixture using create component and we get the component instance. Line 17 is something quite specific to Angular where we call detect changes. This is what triggers the re-rendering. So in runtime, when the application is running, change detection which is the process which is in charge of re-rendering when necessary. It is, let's say, automatic, but in tests you have to do it a bit more manually. And now finally between lines 20 and 22, we have our first unit test for our counter component and we simply assert that the component is initialized, that the class instance exists. So it's a truthy value, the component. Now let's test some initial state. So we will use our before each method to query the pre element and to query the button element. And we will store them in some variables in the test suite because we'll be using them in multiple places so it's more reusable. So here we can see that we use fixture debug element query by CSS and we get the pre element. We do the similar thing for the button and for the pre element we also read the native element of it. Then finally on lines, now we have three unit tests, so we check that the rendered pre element exists, we check that the rendered button element exists. Those are the first two tests and in the final test we check that the initial state of the counter is set to one. And that's kind of just the baseline test to see that everything works correctly initially. Now we want to check what gets rendered. It's quite important that you check what actually gets rendered as final HTML because someone could like delete the whole template of the component and if you were only testing the component state like checking the values of class properties, all your tests would still pass even if someone deletes the whole template. So that's why it's important to check what gets rendered and that's why it's important to actually click on elements etc. We'll see more about that. But yeah, here you remember we queried our pre element, it's an HTML element and we just checked that the text content is times clicked one and that's also like the initial state. This is how it relates to the template that we have. Now let's just like we want to check what gets rendered, we also want to check what happens when we do user interaction. And now it's important when doing user interaction testing, you shouldn't be calling handler methods on the class directly. What you have to do is you have to trigger the event handlers for similar reasons as why you want to check what gets rendered. Someone could delete your template, if you're just calling the click handler directly it will still pass. But if you're actually trying to click on the button and the button doesn't exist, the test will fail. Okay, so that's why it's important. So here on line 7 and 8 we assert that the counter is initially one and the times clicked one is the rendered text. Then we click and then we check, so the way we click is we trigger event handler programmatically. This relates to the click handler that we attach. And this test pass. Now we check that the counter is two, but you will see that it seems like I have maybe a typo here. So I checked that the component counter is two, but the test passes and what is actually rendered is that the text is still times clicked one. It's not times clicked two. And this is because as I've mentioned change detection, which is the process for re-rendering, it doesn't run automatically in tests like it does in runtime when the application is actually running. This is why you have to call it manually after some user interaction simulation. So if you trigger some user interaction programmatically you have to call detect changes to re-render. Now the test will fail because times clicked one is not what actually gets rendered. What actually gets rendered is times clicked two. And you can see in the error log you get like a nice message where it says what was the expected value and what was the actual value. Now we just fix it by updating one to two. So now this test is valid. So, two most important things here is you have to kind of know when you have to re-render in tests. It's a bit tedious, but you have to do it. And the second thing is you have to check what gets rendered in order to be fully sure that everything is working correctly. Now we're writing unit tests for our counter component. But let's say we are now looking at the template of a parent component. So we want to test how is our parent component using this child component. And this is now a unit test of a parent component where we can get the component instance of the child component. So here you can see we will use a query by CSS test JS counter. And test JS counter is the selector of our child component. You can see in the template it's being used like that as an element selector. Then we get the component instance and we check that the counter input is set to 100. So we are basically checking that our template is doing what we are expecting it to do, setting counter to be 100 initially. We can test the other way around. So if our parent component wants to react on counter change event, we can write tests for that as well. So let's say that on counter change we just console.log the new value in the parent component. This dollar event, it's a special piece of syntax, but this will be the value with which the event is emitted. So in this case it will be a number that gets emitted on counter change and that's the value that gets passed to the handler method. So here the test is expanded a bit more because we are now using spy on. So spy on is something from Jasmine. It's very similar in Jest as well. So basically you take console.log and you spy that it has been called. So on line three we set up the spy and on line five we expect that it hasn't been called. On line seven we trigger the event handler to let's say emit 101 as the new counter value and then we expect the console.log has been called once with value 101. So it's important to check how many times something was called beforehand, how many times it was called after, and with which value it was called. And it's all kind of nicely, you usually want to check that something was called once and with some value and that's why you have this nice method to have been called once with something. And this is how the event relates and how the event handler name relates between template and the test. Okay, so let's take a look at some of the best practices. Test doubles, so generally if your application depends on some let's say service and services in Angular are just classes that offer methods and they are most commonly used for fetching data. And here our user service is fetching, like making an API call and fetching the list of users. However, when you're unit testing you don't really want to make API calls and if your component depends on user service you want to avoid making API calls. So for that purpose you would create a test double of user service. We usually call it here user testing service, but you could call it something like user service mock or something like that. And here you define all the same methods that the real service has, but it doesn't make a real API call, but it returns some mock data. And this is how it's used in some user table component for example. So Angular uses dependency injection and this component would inject the user service. But when we are writing tests, we provide user testing service under user service. So the component still expects that it will get like user service instance, but when the tests are run, then you get the mock version, the test double, the testing version of the service, whatever you want to call it. And you can do pretty much the same thing for a component. So component also has some methods, it has some dependencies. You can create a testing version of the component for which it's important that it has the same selector, but it doesn't have to have the complex template and it doesn't have to have any implementation logic. It just needs to have all the inputs and outputs. And you do that very similarly. So if your parent component depends on the counter component, in the unit test for the parent component, you would import counter testing component. And that way you don't use the real component, you use a mock. And this is what makes it a unit test, not an integration test. So you're not testing both components at the same time. You're not testing the parent component and the counter component at the same time. You're just testing parent component and using a test double version of the counter. Next topic is harnesses. Now I won't go into harnesses in too many details, but they are something that's provided by Angular CDK. And you can define a harness for some component. And that harness will have some extra methods which are useful for testing. So in example of material checkbox, there you have a harness which makes it easier to like toggle the checkbox in test, etc. But yeah, I won't go into too many details. You can also write harnesses for your own components. Now last topic about best practices is coverage. So coverage is a metric which tells you when you gather all of your tests, like how much of the code has been covered. And you can get a nice looking report like this. And if you'll take a look into one specific file, you can see which parts of the code have been executed, which have not. So this is a good thing, but it's not something that you should really blindly chase because coverage in Angular doesn't include HTML templates, so you won't get that in the coverage. 100% coverage of course doesn't mean you don't have bugs. And depending on the setup, some files might not be even included in the coverage, so you will get actually wrong numbers. And we have some documentation about that. So yes, code coverage, it's often a lie, but that's a number that project managers like to hear about. Okay, so let me conclude some of these topics. So what you should unit test. You should unit test business logic, services, core UI components, sensitive data handling, helpers, errors and loading states, test if something gets re-rendered correctly, and anything really related to date time handling and time zones, because that's really painful to debug. So having good unit tests for those things, that's really nice. But there are also some things which you shouldn't really unit test, and that's like third party libraries, your implementation details. And what I mean by this, you shouldn't test private methods. You shouldn't be calling them directly. You should always test something in a way that it's used. So if you're testing a component, write your unit test as if you were a parent component. Don't go calling private methods. You also shouldn't test complex interaction between units. That's like integration tests. That's like not for unit tests. It's a different kind of test. Complex UI flows are also quite hard to do with unit testing, especially if it's things like swiping, etc. So that's best left to end to end testing. If you have some really trivial code or some code that is here only temporarily, you won't really get too much benefit from unit tests. That code probably won't break. You want to test things which are more complex, which could break, and you want to ensure that those don't break. And again, setting up unit tests can sometimes be quite complex. So if the time it takes to set up unit test is much greater than the feature is worth, then maybe consider skipping it and do some other type of testing. So here, just like in the end, I will leave you with this short list of do's and don'ts. You can run through this. But it's really important to write. I think what I want to stress most here is that you should write tests based on your requirements. So tests in this way will also be a documentation of what your code should be doing. And it's also documentation that can be executed to verify that the code is doing what it's supposed to be doing. So I think that's the most important note to take here. Make sure that your requirements are covered by tests. Here are some additional resources that I have. Official Angular documentation for testing is actually quite good. It covers a lot of ground. We also have Infinium handbook regarding Angular testing. And there we have a lot of different test cases, let's say recipes, how you should test something. You can also find some useful courses online for testing. I'll here link Angular Academy testing course. I'm not in any way related to them. I just think they have good content. And yeah, that's pretty much it. I thank you for your attention. I know this has maybe been a lot, but please, you can go back and look at some certain sections and see if there's something that you maybe want to take a second look at. I'll be in the chat to answer any questions. And yeah, thank you. Bye.


Filip Voska

JSNation Live

JSNation Live 2020

What Does The Angular Say? 🦊

Hello, everybody. I'm Laura. I'm a front-end developer at Swedbank, and today I want to show you the sounds of Angular, or in other words, to answer, what does the Angular say? What do I mean here? We are very used to generate visuals for the code, but are still often surprised that we can do the same thing for the music as well. We can code music. And if we are looking into audio possibility in the web, that is nothing new. We have different ways how we can handle music in the web as well. But today I want to focus on the most sophisticated way to do that nowadays, which is Web Audio API. And why is it so great? Web Audio API not only enables us to play or replay some audio track, Web Audio API enables us to create our own sounds, to modify them and analyze as well. So basically, it enables us to use browsers as synthesizers. How does that work? If we have some application for that, we would need to create the audio context to store the state of audio. And everything's going to happen there. We would create the sources. That can be your microphone, that can be your oscillators, or it can be audio tracks as well. And then we would need to connect that to the destination, which is usually just speakers. If you would like to add some modifications as filters, that would happen in the middle. And of course, there are helpers for that. Because we developers, we love libraries. And there are libraries for that as well. One of them is ToneJS. ToneJS is even recommended if you are reading about Web Audio API in MDM documentation. And today I'm going to show you the quick demo how we can use ToneJS in our web application using Angular. What do I have here so far? I just installed the Tone library, simple with npm install. I as well have the instrument component. So as you understand, we will create our own instrument today. In HTML, I'm just iterating through a bunch of notes. And on click event, I'm calling playNote method. In the component itself, I am taking synth element from the Tone library. And in playNote method, I'm just triggering that exact note with the length of 1 eighth. How does that look and sound like? Amazingly, those few lines of code, we created the instrument, which is capable to play any pitch you want. But we are not stopping here. Because so far, we're using just default sounds. And for that, I thought to add some a bit modifications to make our instrument a bit more unique. What do we have? This is Catiana instrument, which plays cat samples, but still according to the right pitch. And honestly, I was surprised how easy that is to make the ToneJS library. Because my imagination, I thought that I will need to change every sample by myself. And then just to map it to the help of Tone library. But that was way easier than this. Let's look into. We have one more element from Tone library. It is called the sampler. And for sampler initialization, I had to provide the original cat sample, which is here. And then to map it to the right note. So to understand what cat was singing, that was the tough part. But nothing more was needed to provide. All other adjustments were done by the library itself. And you see that in the play note, now I'm triggering sampler and synthesizer together. Now some of you may think, cat sound instrument. Super useful information. But don't judge me too soon. Because for those few of you, I went an extra mile. And I created something else. Something special. This is doggyana instrument. Which plays dog samples according to the right pitch. But not only this. There are many different elements. And I do not want to overheard you with many different details. But just quick overview what you can use with this library. Let's start with different synthesizers. Before I was using synth. Now you see that I have polysynth as well. I can provide different parameters as different oscillators, squares, sines, and so on and so on. Then there is the part. This element which helps you to play predefined notes, predefined instrument. I'm taking, for example, here, chords, even from separate constant files. And then I have the loop on top of everything and so on. Then different element is noise. Noise here, I'm not just playing straightly. I'm adding the filter, auto filter, which makes some waving effect. And then back to basics. I have some audio tracks. I'm playing them randomly. And the general parameters as changing tempo. I can speed up a bit. So there are many different elements which you can use according different user's actions. And usually when we are thinking about front-end development, our full focus is only on visual parts. Sometimes we totally forget that we have audio possibility in the back. But please note that sometimes the right audio can really enrich our visuals. And in this way, we can create the next level of user experience in the web. And with this, I want to finish up. If you want to look into live music coding using JavaScript and Sonic Pi, you can check my previous talks on YouTube. And thanks a lot for listening and have a great conference.


Laura Silvanavičiūtė

The State of Angular

Minko Gechev

#angular