Gain insights into building real-world components using JavaScript. Delve into dropdown menus, auto-validating forms, autocomplete search, infinite scroll, and tooltips to tackle common frontend challenges seamlessly.

Learn to apply your introductory knowledge of HTML, CSS, and JavaScript to build beautiful, real-world components. In this course, you'll go through the process of developing several complex components, including:

- eBay's dropdown menu
- Gmail's auto-validating form
- Google's main autocomplete enabled search
- Twitter's infinitely scrolling list
- Medium's tooltips

You'll learn how to approach common frontend challenges, what questions to ask yourself, how to design solutions once you've thought of them, how to debug and work with mistakes, and more.

The end-goal is to empower you to look at anything you see on a website and be able to say, "I can build that!"

Intermediate JavaScript: Building Frontend Components

## The protocol
A mock server is going to play an important role in this component. Let's talk a little more about client-server communication in regards to how the client consumes APIs.

This is a simplified view of the main issue:

The order is:
1. Blue
2. Green
3. Red

An instance of our web app is running on a client, and it has requested to get the ten most recent tweets with "space" hashtag. The user reads them happily while scrolling. During this time, another client has posted a space-related tweet. When the user in client one scrolls to the point where more tweets should be loaded, how does it reconcile that more tweets have come in? If it does a simple lookup of "get 10th to 20th most recent tweets", it'll get duplicates that client one had received in its original request.

Client X is just there to represent that we have potentially many more clients posting and requesting.

This is a design decision you have to make. For your particular infinite list, would putting something out of order confuse the user?

## Requirements
We're going to step away from how Twitter does things and impose our own set of requirements:
- Everything in our list must be ordered by the date and time at which the Tweet was posted.​
- We do **not** want a client to receive duplicate tweets
- Tweets are loaded ten at a time

Things to keep in mind:
- If there are fewer​ tweets to serve than requested, the server gives a list of tweets available, if any
- We can keep **any** information about tweets that we want, e.g., the date created, unique ID, etc.

The server must use the information given by the client to figure out the right set of tweets to give it. As a baseline, let's say each client makes a request with the following:

```
{
  pageSize: 10, 
  sortOrder: 'recent'
}
```

# The protocol
A mock server is going to play an important role in this component. Let's talk a little more about client-server communication in regards to how the client consumes APIs.

This is a simplified view of the main issue:

The order is:
1. Blue
2. Green
3. Red

An instance of our web app is running on a client, and it has requested to get the ten most recent tweets with "space" hashtag. The user reads them happily while scrolling. During this time, another client has posted a space-related tweet. When the user in client one scrolls to the point where more tweets should be loaded, how does it reconcile that more tweets have come in? If it does a simple lookup of "get 10th to 20th most recent tweets", it'll get duplicates that client one had received in its original request.

Client X is just there to represent that we have potentially many more clients posting and requesting.

This is a design decision you have to make. For your particular infinite list, would putting something out of order confuse the user?

# Requirements
We're going to step away from how Twitter does things and impose our own set of requirements:
- Everything in our list must be ordered by the date and time at which the Tweet was posted.​
- We do **not** want a client to receive duplicate tweets
- Tweets are loaded ten at a time

Things to keep in mind:
- If there are fewer​ tweets to serve than requested, the server gives a list of tweets available, if any
- We can keep **any** information about tweets that we want, e.g., the date created, unique ID, etc.

The server must use the information given by the client to figure out the right set of tweets to give it. As a baseline, let's say each client makes a request with the following:

```
{
  pageSize: 10, 
  sortOrder: 'recent'
}
```

Let's talk a little about the client and the server are expected to interact and what that implies for our implementation

Welcome

Building a Dropdown Menu

Building the Autocomplete Search

Building Tooltips

Building an Autovalidating Form

Building an Infinite List

From Toy Components to Production

Server Client Communication

The protocol