Learning Path: Aurelia: Web Development for UI Developers

This video provides you a synopsis of the course.

When working in teams or contributing to existing libraries, it is critical that you adhere to the common naming convention practices. Learn how to format your code and be consistent about your choices.

Strategies of working with variables can help you become a better developer. Know the best tips to work with primitive variables.

It is important to know the differences between functions and variables and how we should name them. Understand the best practices of naming conventions for variables and functions.

Now that we know the naming conventions for functions and variables, let’s have a solid naming convention foundation for OOP coding in JavaScript.

There is no namespace keyword in JavaScript, but it is very easy to create one. Let’s learn what it is.

A variable's value keeps changing, but many a times, you want to store information that never changes. Let’s learn how to define constants in JavaScript and the naming convention that will make it easy for us to treat these variables as constants.

Let’s briefly talk about consistency of our code in general using the unary convention. We will see how to use it to make our code more efficient and improve code performance.

One of the vital parts of building a library, a framework, or original code that interacts directly with the browser is the need to test and validate compatibility with the browser.

The default way in which onload works is that it only allows one onload to occur at a time. But what happens if you don't control the loading process of other applications and wish to enable an onload without breaking the loading process on your end? Learn a great hack that will enable you to create an onload without needing to worry if other onloads exist.

Not every feature is detectable on every browser, and many a times, you will need to come up with creative solutions that can bypass the issues of the ways by which different browsers do different things.

Let’s turn our attention to Modernizr, which makes it easy to write conditional JavaScript and CSS for browser feature supports.

There is a new feature in town called querySelectorAll. Before we can start working with it, we need to filter out and define the browsers that support this feature, while building the foundation for an alternative solution.

In the modern world of HTML5, there are very easy ways to select elements natively using the querySelectorAll method. Learn how to build your application in a way that would recognize that your browser does not support this feature when it does not.

When the browser does not support the querySelectorAll feature, we need to develop a script loader that is cross-browser-compatible.

We see how to load scripts dynamically only when we need them, using the script loader we created in the last video. We will have all of the groundwork ready to start creating our own library.

Namespaces provide a way for us to avoid overwriting code. Most of the times, we use namespaces to provide a structure for our library elements.

JavaScript doesn't support private variables natively as yet. There are ways to create pseudo-private variables, but the problem is that they can still be overwritten by other developers by mistake or on purpose.

We will create a safer global variable definition as we get to know our first design pattern—the Module Design Pattern.

As you start working with your library and it becomes popular, you might get to a situation where it's being loaded more than once. Learn how you can deal with situations like this.

We will take all the scraps of code that we created in previous videos and sections and combine them together into our library.

While interfaces don't exist in JavaScript, the ideas behind them are very relevant for JavaScript. Let’s understand what interfaces are and how to implement the logic behind them in JavaScript.

Learn what an adapter is and why we would want to use them in programing and in JavaScript.

We want our library to always do the same thing, no matter what the underlying library that is enabling it is. Let’s build a jQuery adapter to first check whether the user has jQuery loaded. If it is, we will use the library for our operations.

So far, our focus in the creation of our library was on getting all the elements of our adapters to work the same, as we focused on creating custom queries. We will now piggyback on the jQuery text method as we discover the problem we have in our current architecture.

Our goal is to create a library that is functional and useful. As such, we will take advantage of the strategy that jQuery uses to make it easier to interact with elements.

In this video, we will discover the Facade Design Pattern. Creating a simple constant interface. This interface is going to be sent to the user no matter what library element they are using.

In the last video, we created a Facade Design Pattern, but our solution was not complete. We still need to figure out a way to update the initial values that we configure when we start our application to use the Facade. By the end of this video, we will be fully using the Facade Design pattern.

Want to make your facade a lot more than just a standard Façade? You can do so by incorporating its own methods.

We’ve created our façade pattern, but it can very easily get exposed to the methods and items that we really want to hide from all users. Let’s take our facade design pattern to the next level by exposing only what we want to expose in the library.

We need a global object that is always available for all the elements in an application. Let’s use a singleton, which is a design pattern that helps us create an object only one time.

We will take our singleton from the last video and start building it out, starting from its constructor.

We will continue and build the dictionary usage for our ticker.

Let’s get our ticker to work.

We have a working ticker but it's hidden from users. Let’s expose the ticker to all users, and thus complete the creation of our ticker and our singleton.

An event dispatcher is a type of design pattern derived from the Observer Design pattern that enables the developer’s objects to listen to changes in another object without creating a direct two-directional linkage between the objects. In this video, we will have a working event dispatcher.

In the last video, we created an event dispatcher. It's time for us to really test it by integrating it into the ticker time manager that we created in an earlier section.

We already have a working event dispatcher, but at this stage, we can't remove the events. We need to solve this.

We are done building, and in our last video in this course, we need to dedicate a bit of time to testing our application over time.