
When creating services to be used with Angular's *Dependency Injection* system, a provider is needed for each service. 

## Providers in AppModule

By adding services as `providers` in the `AppModule`, the build tools and compilers are unable to know
if that code is actually used in the application. They will always make these services available throughout the application even if they are never used. These services will not be able to take advantage of *tree-shaking*. More on *tree-shaking* down below.

```javascript
@NgModule({
  declarations: [
    AppComponent,
  ],
  imports: [],
  providers: [
    UserService,
    PostService,
    CategoryService, 
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }
```

Rather than adding all of your services into the `providers` array of `AppModule`, as seen above, Angular recommends setting the `providedIn` property of a service's `@Injectable()` decorator. This will make such services *tree-shakable*. The service will still need to be injected where it is used.

## Root application injector

```javascript
import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class UserService { } 
```

By using `root`, we specify that Angular should provide the `UserService` in the root injector. It will be available throughout the application. We've just created a *singleton* service, which is a service for which only one instance exists in an application. 

When using `providedIn` on services, they will only be bundled in the application if they get used. These are called *tree-shakable providers*.

## What is tree-shaking?

Tree shaking is a build process operation that helps with removing unused code from a code base. It's like shaking a a tree and having the dead leaves fall off the tree. Tree shaking only includes the code that is needed for the app to run.

## Feature modules

We can also specify that a service should be provided in a particular `@NgModule`. If we don't want `UserService` to be available unless a `UserModule` is imported, then we can specify that the service should be provided only in the module.

```javascript
import { Injectable } from '@angular/core';
import { UserModule } from './user.module';

@Injectable({
  providedIn: UserModule,
})
export class UserService { }
```

This is the recommended way to provide a service in a feature module. This method enables tree-shaking of the service if nothing ends up injecting it. 



Laravel uses Eloquent, an object-relational mapper (ORM) that makes it very easy to interact with the database to determine if a record exists.

## Using first()

If you need to use the object if it exists and is returned by the database query, you can use `first()`.

```php
$user = User::where('email', $request->email)->first();
if ($user === null) {
  // user does not exist
}
```

## Using count()

If you don't need to use the object, and only need to check if such a record exists in the database, you can use `count()`.

```php
if (User::where('email', $request->email)->count() > 0) {
  // user exists
}
```

## Using exists()

There is also an `exists()` function that can be used to further simplify the query.

```php
if (User::where('email', $request->email)->exists()) {
  // user exists
}
```


I was attempting to install [Storybook](https://storybook.js.org/docs/angular/) on an Angular 9 application and kept getting the following error when running the `build-storybook` command-line utility: `92% chunk asset optimization TerserPlugin previousExtractedCommentsSource.replace is not a function`.

I tried upgrading the Angular application from Angular 9 to Angular 11 but I noticed that the `build-storybook` error was still occuring on Angular 11.

When I had first used `npx sb init` to install Storybook, I got the following version installed in the `package.json` file of my Angular application. I was not able to get `build-storybook` to work with this version.

```json
"@storybook/angular": "^6.2.9",
```

I then decided to try upgrading my Storybook installation with the latest pre-release version of Storybook by using `npx sb upgrade --prerelease`. This gave me the following version.

```json
"@storybook/angular": "^6.3.0-beta.14",
```

I'm now able to run `build-storybook` from the command-line of the Angular 9 app successfully with this prerelease version of Storybook. I hope this can help anyone else struggling with the same error.



In this post, we'll look at quick and easy ways to remove duplicates in JavaScript from:

- arrays
- arrays of objects

## Removing duplicates from arrays

### Using Set

```javascript
const brands = ['Wilson', 'Babolat', 'Wilson'];

console.log([...new Set(brands)]);
// ["Wilson", "Babolat"] 
```

### Using Filter

```javascript
const brands = ['Wilson', 'Babolat', 'Wilson'];

const filtered = brands.filter((item, index) => brands.indexOf(item) === index);

console.log(filtered);
// ["Wilson", "Babolat"] 
```

The `filter` method will create a new array of elements that meet the boolean condition that we provide to it. If the condition for an element returns true, it will be included in the filtered array. If the condition for an element returns false, it will not be in the filtered array.

The `indexOf` method finds the first index position of the `item`. If the array contains duplicates for an item, the first index position returned by `indexOf` will not match the current (duplicate) item's index position.

We can also get back the duplicates from the array if we need them by switching the condition on `indexOf` to an inequality one rather than an equality one.

```javascript
const brands = ['Wilson', 'Babolat', 'Wilson'];

const filtered = brands.filter((item, index) => brands.indexOf(item) !== index);

console.log(filtered);
// ["Wilson"] 
```

### Using Reduce

The `reduce` function might be one of the hardest to understand in JavaScript. 

`reduce` applies a reducer function to the elments of the array. The `reduce` function's first two parameters are a function and an initial value. The reducer function is called on each element of the array with the `accumulator` as the first parameter. The accumulator starts with the initial value. The return value of each reducer function call becomes the new accumulator.

```javascript
const brands = ['Wilson', 'Babolat', 'Wilson'];

const result = brands.reduce((accumulator, current) => {
  if (accumulator.includes(current)) {
    return accumulator;
  } 
  return [...accumulator, current];
}, []);

console.log(result);
// ["Wilson", "Babolat"] 
```

The initial value for `reduce()` is an empty array `[]`. This is the initial value of the `accumulator`. If the accumulator does not contain the current item, then the current item gets returned along with any items in the accumulator as a new array. If the accumulator already contains the current item, then only the accumulator is returned for the next iteration of the `reduce` function. 

Here is a look at the values of the accumulator during the `reduce()` operation on the brands array.

```javascript
[LOG]: [] 
[LOG]: ["Wilson"] 
[LOG]: ["Wilson", "Babolat"] 
```

## Removing duplicates from arrays of objects

Removing duplicate objects from an array of objects is a bit more complex. 

### Set and filter

We can use a `Set` and the array `filter` method to remove duplicate objects from an array of objects.

```javascript
const brands = [
  { name: 'Wilson' },
  { name: 'Babolat' },  
  { name: 'Wilson' },
];

// a Set to track seen brands
const seen = new Set();

const filtered = brands.filter(brand => {
  // check if the current brand is a duplicate
  const isDuplicate: boolean = seen.has(brand.name);
  // add the current brand to the Set
  seen.add(brand.name);
  // filter() returns the brand when isDuplicate is false
  return !isDuplicate;
});

console.log(filtered);
// [{ "name": "Wilson" }, { "name": "Babolat" }] 
```

### Map

We can also use the JavaScript `Map` object to remove duplicates from an array of objects. `Map` holds key-value pairs and remembers the original order that keys were inserted. `Map` is similar to an `Object`, but the difference is that `Map` allows keys of any type, not just strings.

```javascript
const myMap = new Map();

myMap.set(1, 'foo');
myMap.set(1, 'bar');

console.log(map1.get(1)); 
// bar
```

As we can see from the example above, keys must be unique. The `bar` value replaces `foo` because `Map` can only hold one pair with the key `1`.

Now, let's use `Map` to help us remove duplicates from an array of objects.

```javascript
const brands = [
  { name: 'Wilson' },
  { name: 'Babolat' },  
  { name: 'Wilson' },
];

// brand name is the key for the Map
const map = new Map(brands.map(brand => [brand.name, brand]));
// put unique brand objects in an array
const uniques = [....map.values()];

console.log(uniques);
// [{ "name": "Wilson" }, { "name": "Babolat" }] 
```


Here are ways that you can turn a TypeScript `enum` into an array that you can iterate over. Let's say we have the following enum called `Categories` that has different names for its keys and values.

```javascript
enum Categories {
  AllCategories = 'All',
  ActionAdventure = 'Action/Adventure',  
  Comedy = 'Comedy',
}
```

## Keys

We can get the enum's keys by doing the following.

```javascript
const categoryKeys: Array<string> = Object.keys(Categories);

console.log(categoryKeys);
// ["AllCategories", "ActionAdventure", "Comedy"]  
```

We can iterate over the enum's keys to get it's values.

```javascript
const values: Array<Categories> = categoryKeys.map(categoryKey => Categories[categoryKey]);
// with 'noImplicitAny' disabled in tsconfig.json

console.log(values);
// ["All", "Action/Adventure", "Comedy"] 
```

Without `noImplicitAny` being disabled in `tsconfig.json`, the `Categories[key]` reference will throw an error because we are trying to access a `Categories` property using a `string` key. TypeScript warns that since `key` is a `string`, it can be equal to anything, not just the key names in `Categories`. 

We can fix this error by defining a new `key` variable with `keyof typeof Categories` and casting `categoryKey` to the same type using the `as` keyword. The possible values of `key` will now be limited to only the names of the `Categories` keys. TypeScript will be fine with this adjustment that we've made.

```javascript
const values: Array<Categories> = categoryKeys.map(categoryKey => {
  const key: keyof typeof Categories = categoryKey as keyof typeof Categories;
  return Categories[key];
});

console.log(values);
// ["All", "Action/Adventure", "Comedy"] 
```

## Values

We can also get the enum's values by doing the following.

```javascript
const values: Array<Categories> = Object.values(Categories);

console.log(values);
// ["All", "Action/Adventure", "Comedy"] 
```



Here is how object destructuring is done in JavaScript.

```javascript
const player = {
  firstName: 'Roger',
  lastName: 'Federer',
  age: 36,
};

const { firstName, lastName } = player;

console.log(firstName); // Roger
console.log(lastName); // Federer
```

What about if we want to apply types to this for use in TypeScript? 

```javascript
const { firstName, lastName }: { firstName: string; lastName: string } = player;

console.log(firstName); // Roger
console.log(lastName); // Federer
```

We can shorten and simplify this by creating a `type` or `interface` for what we are destructuring, which are the `firstName` and `lastName` in this case.

```javascript
const player = {
  firstName: 'Roger',
  lastName: 'Federer',
  age: 36,
};

interface PlayerName {
  firstName: string;
  lastName: string;
}

const { firstName, lastName }: PlayerName = player;

console.log(firstName); // Roger
console.log(lastName); // Federer
```



If you'd like to run only one test file with Jest to see the result of that file's tests, here is how you can do that.

Make sure your `package.json` file contains the following.

```json
"scripts": {
  "test": "jest --runInBand --forceExit",
}
```

Then, run the following command.

```bash
npm test -- user.service.spec.ts
```

The `--` marks the end of options. Anything entered after the `--` is passed to the command being run, which is `jest` in this case. Thus, the file `user.service.spec.ts` is passed to the `jest` command to run that file's tests.



The traditional way to delete an object property from a JavaScript object is to use the `delete` command, as seen below.

```javascript
const driver = {
  name: 'Mario',
  color: 'red',
  kart: 'bike',
};

delete driver.color;
```

If we try to `console.log(driver);` after the `delete` command, the result is:

```javascript
{
  kart: "bike",
  name: "Mario"
}
```

Given the `driver` object, we can also delete the `color` property from this object using the following. The result is the same.

```javascript
delete driver['color'];
```

# The Immutable Way

The `delete` command *mutates* or changes the initial object. This is not the best approach when it comes to *functional programming* in JavaScript.

**Immutability** is an important design pattern of *functional programming*. Immutability states that something cannot be modified after it is instantiated. If the value of something needs to change, it should be re-created with the new value.

We can remove a property from an object in an *immutable* way by creating a completely new object that contains copies of all the properties from the old object, except the one property that we want to remove. 

```javascript
const driver = {
  name: 'Mario',
  color: 'red',
  kart: 'bike',
};

const propertyToRemove = 'color';

const newDriver = Object.keys(driver).reduce((newObject, currentKey) => {
  if (currentKey !== propertyToRemove) {
    newObject[currentKey] = driver[currentKey];
  }
  return newObject;
}, {});

console.log(newDriver);
```

By using `reduce` on the result of `Object.keys(driver)`, we are iterating over all the keys of our `driver` object. As long as the current `key` of the iteration is not equal to `color`, that property is copied to a new object, called `newObject`. The object returned will not have the property that contains the key that we want to remove, which is `color`.

```javascript
{
  kart: "bike",
  name: "Mario"
}
```

As you can see, the result is the same as the result we obtained earlier with `delete driver.color`. However, we have now enforced the principle of *immutability*, since the `driver` object is no longer directly modified after being instantiated.

If you are using *React* or *Angular*, the *immutable* way is the proper way to remove a property from an object in a component's state, or in *Redux* or *ngRx* state.

By applying the *immutability* design pattern, we now have programming code that follows the functional programming paradigm more closely.



The **nullish coalescing** operator `??` is a logical operator that allows you to fall back to a default value when dealing with `null` or `undefined`. It returns the right-hand side operand when the left-hand side operand is `null` or `undefined`. Otherwise, it returns the left-hand side operand.

The **nullish coalescing** operator `??` is available in TypeScript as of version 3.7.

## Nullish coalescing example

```javascript
const value = user.value ?? 0;
```

This expression is equivalent to:

```javascript
const value = user.value !== null && user.value !== undefined ? user.value : 0;
```

## When using a default value

The **nullish coalescing** `??` operator is recommended over `||` when using a default value. Consider the following example.

```javascript
const value = user.value || 0.5;
```

When `user.value` is set to `0`, the value from this expression will be `0.5`, which may not be intended. `??` avoids some unintended behavior with `||` where `0`, `NaN` and `""` are treated as falsy values.



The **optional chaining** operator `?.` is for optional property access. Optional chaining allows us to write code that will immediately stop running some expressions if a `null` or `undefined` is found.

The **optional chaining** operator `?.` is available in TypeScript as of version 3.7.

## Cannot read property of undefined

Consider the following example demonstrating object property access on an `undefined` object.

```javascript
let user;
const name = user.firstName;
```

This code will throw a JavaScript error that will say *"Cannot read property 'firstName' of undefined."* Since `user` is `undefined`, no properties can be accessed from the `user` object. The **optional chaining** operator helps us to avoid this error during object property access.

## Optional chaining to the rescue

Let's re-visit this same example, but this time with the **optional chaining** operator.

```javascript
const name = user?.firstName;
```

When `user` is defined, `user?.firstName` will be computed and `firstName` will be accessed from the `user` object. However, when `user` is `null` or `undefined`, the **optional chaining** operator will stop execution and just return `undefined` as the `name`.

```javascript
const user = undefined;
const name = user?.firstName;
console.log(name); // undefined

const user = { firstName: 'John', lastName: 'Smith' };
const name = user?.firstName;
console.log(name); // John
```

## How optional chaining works

Consider the following example to see the same line of code with and without the **optional chaining** operator to gain a better understanding of how it works.

```javascript
// with optional chaining
const name = user?.firstName;
// without optional chaining
const name = (user === null || user === undefined) ? undefined : user.firstName;
```

## Left side checks only

The **optional chaining** operator will only check if the value on the left of it is `null` or `undefined`. It will not check any properties to the right of it.

```javascript
const user = {};
const zip = user?.address.zip;
console.log(zip);
```

This code block throws an error saying *"Cannot read property 'zip' of undefined."* This is because there is no `address` property in the `user` object. Thus, it is `undefined` and a `zip` property cannot be accessed from `undefined`. The **optional chaining** operator only helped us with `null` and `undefined` checks on the `user` object appearing to the ***left*** of it.

## Nested object property access

The **optional chaining** operator can be used several nested levels deep.

```javascript
const user = {};
const zip = user?.address?.zip;
console.log(zip); // undefined
```

This example will not throw the error we saw in the previous example because we have added the **optional chaining** operator to the `address` property. If `address` is found to be `null` or `undefined`, then `undefined` is returned without throwing an error.



If you're looking for a *dictionary* data structure in JavaScript, you can use the `Map` object. It was introduced in ECMAScript 6. It is very similar to the implementation of a dictionary data structure that you would find in other programming languages.

## Getting a value from a Map

A `Map` doesn't contain any keys upon creation. It will only contain what we explicitly put into it using the `set` function.

```javascript
const dictionary = new Map();
dictionary.set("Apple", "A fruit and a brand.");

console.log(dictionary.get("Apple")); // outputs "A fruit and a brand."
```

## Map size

The number of items in a Map can be retrieved from its `size` property.

```javascript
console.log(dictionary.size); // 1
```

## Map entry checking

We can check if a `Map` contains a key using the `has` function.

```javascript
console.log(dictionary.has("Apple")); // true
```

## Deleting from a Map

We can delete an entry from a `Map` using the `delete` function.

```javascript
dictionary.delete("Apple")
console.log(dictionary.size); // 0
```

## Adding objects and arrays to a Map

We can add objects or arrays to a `Map` entry.

```javascript
dictionary.set('Mario', { color: "Red", sibling: "Luigi" });
console.log(dictionary.get("Mario")); // { color: "Red", sibling: "Luigi" }

dictionary.set('Toad', ['Rainbow Road', 'Shy Guy Falls', 'Yoshi Circuit']);
console.log(dictionary.get("Toad")); // ['Rainbow Road', 'Shy Guy Falls', 'Yoshi Circuit']
```

## Map versus regular objects

A `Map` is a JavaScript object with special properties. It tends to perform better in situations that involve the frequent addition and deletion of key-value pairs. Regular objects are not optimized for this.

### Map keys versus object keys

One of the `Map` object's special properties is that the keys of a `Map` can be any type of value, including functions and objects. This is unlike regular objects in JavaScript which cannot have any object as a key. Regular objects can only have string, number, or symbol keys.

```javascript
const driver = { name: "Luigi", color: "Green" };
const kart = { type: "Sport Bike", tires: "Sport" };

const dictionary = new Map();
dictionary.set(driver, "1st place");
dictionary.set(kart, "No damage");

console.log(dictionary.get(driver)); // 1st place
console.log(dictionary.get(kart)); // No damage
console.log(dictionary.get({})); // undefined
```

The last output will return undefined because the empty object `{}` does not reference the `driver` or `kart` object keys that are in the `Map`.

### Map iteration versus object iteration

A `Map` is directly iterable. The `Map` object will iterate entries, keys, and values in the order that they were entered. The items in the `Map` will be output in the order that they were inserted.

```javascript
const dictionary = new Map();
dictionary.set("Yoshi", "2nd Place");
dictionary.set("Toad", "3rd Place");
dictionary.set("Luigi", "1st Place");

dictionary.forEach((value, key) => {
  console.log(`${key}: ${value}`);
});

// Yoshi: 2nd Place
// Toad: 3rd Place
// Luigi: 1st Place
```

You can also iterate over the `Map` using a `for...of` loop to get the same output.

```javascript
for (let [key, value] of dictionary) {
 console.log(`${key}: ${value}`);
}
```

Regular JavaScript objects do not implement an iteration protocol. Therefore, they are not directly iterable using the `forEach` or the `for...of` loops. You could use `Object.keys()`, `Object.values()`, or `Object.entries()` to iterate over a regular object's keys, values, or entries. However, the object itself is not directly iterable like the `Map` is.

## Keys and values of a Map

Just as with regular objects, you can also get the `keys` and `values` of a `Map`.

```javascript
const dictionary = new Map();
dictionary.set("Yoshi", "2nd");
dictionary.set("Toad", "3rd");
dictionary.set("Luigi", "1st");

for (let key of dictionary.keys()) {
	console.log(key); // Yoshi, Toad, Luigi
}

for (let value of dictionary.values()){
	console.log(value); // 2nd, 3rd, 1st
}
```

## Conclusion

You can now confidently use the `Map` object and data structure in JavaScript. If you are using a regular object for the frequent addition and deletion of key-value pairs, you will get better performance by converting that object into a `Map`.



JavaScript allows developers to mix between object-oriented, procedural, and functional programming paradigms. The growing trend lately has been toward functional programming. In JavaScript frameworks such as Angular and React, using functional programming can even result in performance improvements.

Functional programming is about programming with very small and reusable pure functions.

## Pure functions

Just because a program contains functions, it does not mean that the program uses functional programming. Functional programming is based on the concepts of pure and impure functions. Functional programming encourages you to write pure functions. 

Pure functions are functions that accept an input and return a value, without producing any side-effects. No side-effects means that the function does not modify any data outside of its scope. A pure function must return a value. The return value of a pure function must depend on the arguments that are passed to the parameters of the function.

## Properties of pure functions

A pure function must satisfy the following properties to be considered pure:

- **Idempotence:** Given the same inputs, a pure function will always return the same value, regardless of how many times the function is called. This means that a pure function does not depend on any external state that can be mutated during execution.

- **Side-effect free:** A pure function cannot cause any side-effects. Side effects may include I/O (writing to the console or to a log file), modifying a mutable object, reassigning a variable, etc. Pure functions do not mutate any shared state or function arguments. Pure function calls don't result in any observable output, don't throw exceptions, and don't trigger events. They just return a value.

Pure functions are not very likely to cause bugs in other unrelated parts of a program because they do not operate on a shared state, not do they produce side-effects.

If a function is using `void` (it has no return value), it is an impure function. If a function has no return value, then either it's not doing any operations or it's causing some side-effect, and thus, is an impure function. If a function is called but its return value is not used, it may be relied on to do some side-effect, making it an impure function.

## Examples

```javascript
function impure(arg) {
  myObject.key = 90;
  return arg * myObject.key;
}
```

The above function is not a pure function because it modified the state of `myObject.key` outside of its scope.

```javascript
function impure(arg) {
  let f = arg * myObject.key;
}
```

Though it didn’t modify any external state, the above function is also not a pure function because it did not return a value.

```javascript
function impure(arg) {
  return myObject.key * 3;
}
```

Though it didn’t affect any external state of `myObject.key`, the above function is impure because the returned value is not dependent on the input `arg`. Not only must pure function return a value but that returned value must depend on the input.

```javascript
function pure(arg) {
  return arg * 4;
}
```

The above function is a pure function. It returned an output based on the input and did not create side-effects on any any external state.

## Benefits of pure functions

- They are easier to work with and debug because they don't depend on a mutable external state.
- The return value can be *cached* or *memoized* to avoid recomputing it in the future.
- They make it easier to write *unit tests* because there's no dependencies that need to be mocked (such as for logging, database transactions, API calls, etc).
- Replacing procedural loops with pure functions increases code readability.

## Encapsulation

Pure functions provide the same benefits that **encapsulation** does in **Object-Oriented Programming**. Encapsulation is about data-hiding. It's about minimizing connections with outside code to reduce the likelihood of unexpected changes. What can be hidden and self-contained, can be easily changed.

Pure functions follow the encapsulation principles of: 

- Being independent from outside code.
- Allowing the function implementation to change without impacting the rest of the program.
- Allowing the code to be easily moved between files, modules, projects, etc.
- Having a self-documenting public interface (the function signature).
 
## Conclusion

Complex programs usually need to produce an output. Therefore, they cannot be built with only pure functions. However, it is a good programming practice to make functions pure whenever possible. Adhering to functional programming principles can help to achieve this.

Functional programming may require a learning curve if you are coming from an Object-Oriented Programming background. You would need to look out for cases where objects get mutated, where state is shared, where logic extends beyond the function scope, and where side-effects are caused by function calls.



When speaking about functions in programming, it is common to confuse the terms `parameters` and `arguments`. What does each term refer to and which one should you use? Let's find out.

- Function parameters are the names that are listed in a function's definition.
- Function arguments are the real values that get passed to the function.

Parameters are initialized to the values of the arguments supplied. Parameter variables are used to import arguments into functions.

## Example of parameters and arguments

Let's use JavaScript to create a simple example that will help to better understand the difference between parameters and arguments.

```javascript
function divide(numerator, denominator) {
  return denominator > 0 ? numerator / denominator : 0;
}

console.log(divide(10, 5)); // 2
```

The parameters of this function are `numerator` and `denominator` seen in the function definition of `function divide(numerator, denominator)`. The arguments are the values of `10` and `5` that get passed to the function in the function call of `divide(10, 5)`.



When building a React application, iterating over data to display it is a common need. When we know what our data items will be in advance, we can easily hard-code them directly into the HTML like in the example below.

```javascript
export class MyList extends React.Component {
  render() {
    return (
      <ul>
        <li>Mario</li>
        <li>Luigi</li>
        <li>Bowser</li>
      </ul>
    );
  }
}
```

However, when we are dealing with dynamic data, we don't know in advance what the value of our data items will be and so we cannot hard-code them. This dynamic data could be returned from an API that we are fetching from. Let's look at two approaches for iterating over and rendering dynamic data.

## 1. Iterate and render in the return statement

When dealing with dynamic data, the first approach is to use the JavaScript `map` method to render the data items directly in the return statement of the *render* function.

```javascript
export class MyList extends React.Component {
  render() {
    const usernames = ['Mario', 'Luigi', 'Bowser']; // let's mock data from an API
    
    return (
      <ul>
        {usernames.map(username => {
          return <li key={username}>{username}</li>
        })}
      </ul>
    );
  }
}
```

>  Use the *key* attribute to ensure that each looped element is uniquely identified. This helps React to identify which items have changed in the list. Always add keys when rendering items in an iterable list. A key should [uniquely identify a list item](https://reactjs.org/docs/lists-and-keys.html) from other list items.

## 2. Iterate and render an array of JSX elements

When dealing with dynamic data, the better approach is to loop over that data to add *JSX* elements to an array that can then be rendered separately. The first approach that we saw above is fine for a simple component. However, as components grow in size, it's best to keep return statements as simple as possible.

```javascript
export class MyList extends React.Component {
  render() {
    const usernames = ['Mario', 'Luigi', 'Bowser']; // let's mock data from an API
    const listItems = [];

    for (const username of usernames) {
      listItems.push(<li key={username}>{username}</li>)
    }

    return (
      <div>
        {listItems}
      </div>
    );
  }
}
```

With the looping code that builds the *listItems* now out of the *return* statement, we can easily extract this logic to a separate file that can be re-used across multiple components.

You have now become an expert on how to iterating and render data in React. Go forward iterating and rendering with confidence!



JavaScript array and object destructuring allows us to break up arrays and objects into their individual pieces. Arrays and objects are the two most used data structures in JavaScript. Therefore, it will be very useful to know how to destructure them.

JavaScript objects make it easy for us to create a single entity that stores our data by key. JavaScript arrays help us to gather data into an ordered collection. The destructuring assignment syntax is useful for *unpacking* arrays or objects into the variables that we need from them. 

## Array Destructuring

Here is an example of a function that destructures an array into variables.

```javascript
function printName(fullName) {
  const [firstName, lastName] = fullName;
  console.log(firstName); // John
  console.log(lastName);  // Smith
}

printName(['John', 'Smith']);
```

The destructuring assignment does not modify the original array. It just copies the array items into variables. It provides us with a quicker way of writing the following:

```javascript
function printName(fullName) {
  const firstName = fullName[0];
  const lastName = fullName[1];
}

printName(['John', 'Smith']);
```

### Skipping over elements 

We can skip over elements that are not needed during destructuring.

```javascript
const [firstName, , title] = ["John", "Smith", "President"];

console.log(firstName); // John
console.log(title); // President
```

### Object properties on the left side

We can use object properties for the left-hand side of the destructuring syntax.

```javascript
const person = {};
[person.firstName, person.lastName] = "John Smith".split(' ');
console.log(person.firstName); // John
console.log(person.lastName); // Smith
```

The `split` function broke up our string wherever a space was found. Since there was a space between *John* and *Smith&*, the string was broken up into an array of two elements containing *John* and *Smith*.

### Array Destructuring with Sets

Array destructuring also works with JavaScript sets.

```javascript
const [firstName, middleName, lastName] = new Set(['John', 'James', 'Smith']);
console.log(firstName); // John
console.log(middleName); // James
console.log(lastName); // Smith
```

### Array Destructuring with the spread operator

We can use JavaScript spread syntax to get the remaining values of an array while destructuring.

```javascript
const [firstName, middleName, ...data] = ['John', 'James', 'Smith', 'President'];

console.log(firstName); // John
console.log(middleName); // CaJamesesar
console.log(data[0]); // Smith
console.log(data[1]); // President
console.log(Array.isArray(data)); // true
console.log(data.length); // 2
```

### Array Destructuring with default values

We can set a default value for any missing elements during destructuring.

```javascript
const [firstName, lastName, title = 'No Title'] = ['John', 'Smith'];
console.log(firstName); // John
console.log(lastName); // Smith
console.log(title); // No Title
```

## Object Destructuring

The destructuring assignment also works with objects. On the right side will be an existing object and on the left side will be the properties that we want to extract from it.

```javascript
const car = {
  brand: 'Ford',
  model: 'Mustang',
  year: 1967
};

const { brand, model, year } = car;

console.log(brand); // Ford
console.log(model); // Mustang
console.log(year); // 1967
```

### Object Destructuring with default values

We can also set default values while destructuring objects. It's similar to what we did while destructuring arrays.

```javascript
const car = {
  brand: 'Ford',
  model: 'Mustang',
};

const { brand, model, year = 1995 } = car;

console.log(brand); // Ford
console.log(model); // Mustang
console.log(year); // 1995
```

If we have a complex object, we can destructure it into only the specific property that we need from the object.

```javascript
const car = {
  brand: 'Ford',
  model: 'Mustang',
  color: 'Red',
  year: 1999,
};

const { brand } = car;

console.log(brand); // Ford
```

The default values can also be function calls. This also works for destructuring arrays.

```javascript
const car = {
  brand: 'Ford',
};

let { brand = prompt("Enter Brand:"), model = prompt("Enter Model:") } = car;

console.log(brand); // Ford
console.log(model); // (Whatever the user enters in the model prompt)
```

### Customizing destructured names

If we want to assign a property to a variable with a name other than the name of the object property, we can set a new name with the colon operator.

```javascript
const car = {
  brand: 'Chevrolet',
  model: 'Corvette',
  year: 1967
};

const { brand: b, model: m, year } = car;

console.log(b); // Chevrolet
console.log(m); // Corvette
console.log(year); // 1967
```

The colon tells us what value goes where. For example, it allows the value for the variable `brand` to go into variable `b`.

### Object Destructuring with the spread operator

If an object has more properties than we need variables, then we can assign the *rest* of the properties using the spread syntax. This is similar to what we did while destructuring arrays.

```javascript
const options = {
  brand: 'Ferrari',
  model: 'Testarossa',
  year: 1984
};

const { brand, ...data } = options;

console.log(brand); // Ferrari
console.log(data.model);  // Testarossa
console.log(data.year);   // 1984
```

### Abbreviated Destructuring

We can shorten the destructuring assignment syntax by not using `let` on the left-hand side and wrapping the expression in round brackets.

```javascript
({ brand, model } = { brand: 'Ford', model: 'Mustang' });

console.log(brand); // Ford
console.log(model); // Mustang

model = 'Taurus';
console.log(model); // Taurus
```

Notice that `brand` and `model` will not be read-only references like we get with `const`.

## Nested Destructuring

In this last example, the `car` object is comprised of other nested objects and arrays. We can use more complex left-side destructuring patterns to extract the deeper properties of the `car` object that we need.

```javascript
const car = {
  type: {
    brand: 'Ford',
    model: 'Mustang',
    year: 1990,
  },
  attributes: {
    doors: 2,
    horsepower: 400,
  }
  features: ['Sunroof', 'Mags'],
  sold: true,
};

const {
  type: {
    brand,
    model,
  }, // get only the needed properties
  features: [featureOne, featureTwo], // assign features individually
  owner = 'John Smith' // not present in car (set a default value)
} = car;

console.log(brand);  // Ford
console.log(model);  // Mustang
console.log(featureOne); // Sunroof
console.log(featureTwo);  // Mags
console.log(owner);  // John Smith
```


With the arrival of ES6 came the addition of `let` and `const`. These are useful for variable declaration. In this post, we'll see why they are different from `var`.

## Variable declaration with var

Before ES6 arrived, `var` declarations were the way to go in JavaScript. Variables declared with `var` can have problems. This is why ES6 introduced new ways to declare variables. It will help to know more about `var`, we'll get a better understand of why `let` and `const` were created to replace `var`.

### Var declarations

Variables declared with `var` can be re-declared and updated without an error. This can make `var` messy to work with. 

With `var`, we can redeclare a variable by repeating the `var` keyword right before it. No error will be thrown.

```javascript
var car = "Toyota";
var car = "Ford";
console.log(car); // Ford
```

We can also update the variable that we declared with `var`.

```javascript
var car = "Toyota";
car = "Ford";
console.log(car); // Ford
```

Variable re-declaration with `var` can be problematic. If we deliberately want to redefine a variable defined with `var`, this is not a problem. However, if we do not realize that a variable has already been defined with `var`, and we redefine it, we can get unexpected results when our code runs. Here is an example of this problematic scenario.

```javascript
var car = "Impreza WRX";
var horsepower = 350;

if (horsepower >= 350) {
  var car = "Corvette"; 
}

console.log(car) // Corvette
```

When we get to the `if` statement scope, we can forget that `car` was already previously defined with `var`. We can end up using the same variable name `car` with `var` in this scope. It will not throw an error, but instead quietly redefine our original `car` variable. While we may be expecting to see `Impreza WRX` as the output of the `console.log()` statement, we will actually get `Corvette` due to the accidental `var` re-declaration.

> When a `var` variable is declared outside of a function, its scope is global. The outer `car` and `horsepower` variables are globally-scoped since they exist outside of a function. 

### Var Hoisting 

JavaScript does something called hoisting. Hoisting is the behavior of moving variable and function declarations to the top of their current scope before execution. The current scope can be the top of a script or the top of a function. Declarations are *hoisted* to the top. `var` variables are hoisted to the top of their scope and are then initialized with an `undefined` value.

```javascript
console.log (car); // undefined
var car = "Porsche";
```

Hoisting actually causes these lines to be interpreted as:

```javascript
var car;
console.log(car); // undefined
car = "Porsche";
```

Variables that are defined with `let` and `const` solve the hoisting problem that exists with `var`. `let` and `const` variables are hoisted to the top of a code block, but they are not initialized. The code block knows about these variables but cannot use them until they are declared.

```javascript
car = "Acura"; // variable usage
let car; // variable declaration
```

In the example above, using a `let` variable above before it has been declared results in the following console error: `Uncaught ReferenceError: Cannot access 'car' before initialization`.

```javascript
car = "Nissan"; // variable usage
const car; // variable declaration
```

In the example above, using a `const` variable above before it has been declared results in a syntax error in the console that says `error: unknown: Unexpected token`. 

## Variable declaration with let

`let` is meant for variables that we want to reassign a value to. We `let` that variable be reassignable. There are some instances where this is helpful. Let's look at a simple case.

```javascript
let total = 0;

[{ total: 1}, { total: 2}].forEach(item => {
  total += item.total; // reassign a new value to 'total'
});

console.log(total); // 3
```

`let` variables can be re-declared but they cannot be re-declared, which helps us to avoid the re-declaration issue that we encountered with `var`.

```javascript
let car = "Maserati";
car = "Lotus"; // this is fine
    
let car = "Mazda";
let car = "Hyundai"; // error: unknown: Identifier 'car' has already been declared
```

Since `let` is block-scoped, you can define the same variable name in different scopes and not encounter an error for doing so.

```javascript
let car = "Opel";
if (car) {
  let car = "Mitsubishi";
  console.log(car); // Mitsubishi
}
console.log(car); // Opel
```

There is no issue with this because both instances of `car` are seen as different variables because they have different scopes. 

## Variable declaration with const

`const` is meant for variables that will maintain a constant value. The value of a variable declared with `const` will not be allowed to change within its scope.

Every `const` variable declaration needs to be initialized at the time it is declared.

```javascript
const car; // error: unknown: Unexpected token
const car = "Car"; // this is fine
```

Variables declared with `const` cannot be updated or re-declared.

```javascript
const car = "Buick";
car = "BMW"; // error: Uncaught TypeError: Assignment to constant variable.

const car = "Mercedes";
const car = "Renault"; // error: unknown: Identifier 'car' has already been declared
```

Objects that are declared with `const` cannot be updated, but their properties can be updated.    

```javascript
const car = {
  brand: "Honda",
  model: "Civic",
  year: 2020
};

car = {
  horsepower: 200,
} // error: Uncaught TypeError: Assignment to constant variable.

car.horsepower = 300; // this is fine
```

We can add or update a property within a `const` object, such as `horsepower`, but we cannot update the `car` object itself.

## Conclusion

### var

- `var` variables can be updated and re-declared 
- `var` variables are automatically initialized with undefined. 
- `var` variables can be declared without being initialized. 
- Don't use `var`.

### let

- `let` variables can be updated but not re-declared
- `let` variables are not automatically initialized.
- `let` variables can be declared without being initialized.
- Use `let`if you want the variable to be reassignable.

### const 

- `const` variables cannot be updated or re-declared.
- `const` variables are not automatically initialized.
- `const` variables need to be initialized when declared.
- Use `const` whenever possible. It's added protection in your code since it guarantees that a value cannot be reassigned to it.



In JavaScript, we can use the *spread* operator combined with *short-circuit evaluation* to conditionally add keys to an object.

Let's say that we wanted to build a JavaScript object for querying based on some filtering parameters that don't always exist. We would usually write something like this.

```javascript
function buildQuery(filters) {
  const queryObject = {};

  if (filters.firstName) {
    queryObject.firstName = filters.firstName;
  }

  if (filters.lastName) {
    queryObject.lastName = filters.lastName;
  }

  if (filters.age) {
    queryObject.age = filters.age;
  }
  
  return queryObject;
}
```

The *spread* operator combined with *short-circuit evaluation* help us to simplify our `buildQuery` function.

```javascript
function buildQuery(filters) {
  return {
    ...filters.firstName && { firstName: filters.firstName },
    ...filters.lastName && { lastName: filters.lastName },
    ...filters.age && { age: filters.age },
  };
};
```

We could also write the `buildQuery` function using an *arrow function*.

```javascript
const buildQuery = query => ({
  ...filters.firstName && { firstName: filters.firstName },
  ...filters.lastName && { lastName: filters.lastName },
  ...filters.age && { age: filters.age },
});
```

This technique can also be used outside of a function. Let's say we wanted to conditionally gather **React** `props` into an object. We can achieve this quite easily using the *spread* operator combined with *short-circuit evaluation*.

```javascript
const filters = { 
  city: this.props.city, 
  ...this.props.cuisine && { cuisine: this.props.cuisine },
  ...this.props.category && { category: this.props.category },
};
```

This technique can help to simplify your **JavaScript** or **TypeScript** code for conditionally building and manipulating objects.



Let's say we have an array of objects in JavaScript and we would like to sum the values of similar keys. What would be a simple way to do that? Let's take a look.

```javascript
const kartRacers = [
  { name: 'Toad', score: 150 },
  { name: 'Mario', score: 100 },
  { name: 'Luigi', score: 50 },
  { name: 'Wario', score: 250 },
  { name: 'Mario', score: 50 },
];
```

## Using the JavaScript reduce function

Now that we've defined our array of Mario Kart racer objects, we can use the `reduce` function. JavaScript's `reduce` function
applies a reducer function that we give it, to each element of the array.

```javascript
const racerScores = kartRacers.reduce((acc, { name, score }) => {
  acc[name] = acc[name] || { name, score: 0 };
  acc[name].score += score;
  return acc;  
}, {});
```

The first reducer function parameter is a *callback* function. This is the function that we want to execute on each element of the array. The first parameter of our callback function is the `accumulator`. The second parameter is the `currentValue`. It is the current element that is being processed in an iterative manner from the array.

The second reducer function parameter is the *initialValue*. It is the value that we want to use as the `accumulator` for the first call of the callback function. If we supply no *initialValue*, the first element in the array will be used as the initial accumulator value and *currentValue* will skip it.

We will use the *initialValue* of the `reduce` function to set our `accumulator` to an empty object. 

```javascript
acc[name] = (acc[name]  || { name, score: 0 });
```

With the first line of the callback function, we will accumulate elements by the `name` key. 

For the first iteration of the callback function, `acc[name]` will be set to `{ name, score: 0 }`. 

```javascript
acc[name] = { name: 'Toad', score: 0 };
```

The same will happen for iterations two through four because the left side of the logical OR clause `||` will be `undefined`. Thus, the right side will be used.


For the fifth iteration of the callback function, `acc[name]` will be set to `acc[name]` because we have already iterated over an element with the name `'Mario'`.

```javascript
acc[name] = { name: 'Mario', score: 100 };
```

With the second line of the callback function, `acc[name].score += score`, we will sum the score of a `name` that we already iterated over with the *currentValue* of a new element with the same `name`.

The `reduce` function that executes our callback function will give us the following object structure containing a sum of Mario's scores. Mario's score is now `100 + 50`.

```javascript
{
  Toad: {
    name: "Toad",
    score: 150
  },
  Mario: {
    name: "Mario",
    score: 150
  },
  Luigi: {
    name: "Luigi",
    score: 50
  },
  Wario: {
    name: "Wario",
    score: 250
  }
}
```

## The result

We can then use `Object.values` to extract only the *value* portion from the nested objects.

```javascript
const result = Object.values(racerScores);
```

The result can be seen below. This gives us the original structure we started with, but with one `Mario` entry containing the sum of both scores present in the original array of objects.

```javascript
[
  { name: 'Toad', score: 150 },
  { name: 'Mario', score: 150 },
  { name: 'Luigi', score: 50 },
  { name: 'Wario', score: 250 },
];
```



In JavaScript, the spread syntax is an ellipsis of three dots `...` used to expand an iterable object into a list of its arguments. The spread syntax ***spreads*** array and objects into separate arguments.

The spread operator is quick and easy to use for adding items to arrays, combining arrays or objects, and spreading an array or object out. The spread operator was added to JavaScript in ES6 (ES2015), just like the rest parameters, which have the same syntax - an ellipsis of three dots.

## Spreading an array

Let's look at an example use case of the spread operator using the `Math.max()` function. This function expects separate numbers. Trying to pass an array to it will give us a `NaN` (not a number) error.

```typescript
Math.max(1, 3, 5); // 5
Math.max([1, 3, 5]); // NaN
```

Let's fix this `NaN` error by using the spread operator.

```typescript
Math.max(...[1, 3, 5]); // 5
```

The spread operator placed before the array has spread out our `[1, 3, 5]` array into separate values of `1`, `3`, and `5`.

## Copying an array

The spread operator makes it easy to copy an array.

```typescript
const brands = ['honda', 'audi', 'toyota', 'mazda'];
const brandsCopy = [...brands];

brands[0] = 'nissan'; // only element 0 of the brands array is changed
console.log(brands); // ['nissan', 'audi', 'toyota', 'mazda'] 
console.log(brandsCopy); // ['honda', 'audi', 'toyota', 'mazda'] 
```

## Combining an array

The spread operator makes it easy to combine or concatenate arrays.

```typescript
const brands = ['honda', 'toyota', 'nissan'];
const luxuryBrands = ['acura', 'lexus', 'infinity'];

console.log([...brands, ...luxuryBrands]); // ["honda", "toyota", "nissan", "acura", "lexus", "infinity"]
```

## Adding items to an array

The spread operator makes it easy to add items to an array.

```typescript
const techBrands = ['apple', 'microsoft', 'google'];
const allBrands = ['sony', 'samsung', ...techBrands];

console.log(allBrands) // ["sony", "samsung", "apple", "microsoft", "google"]
```

## Combining objects

The spread operator makes it easy to combine objects.

```typescript
const product = { name: 'apple', color: 'red' };
const cost = { price: 1.99, sale: 0.99 };
const item = { ...product, ...cost, quantity: 10 };

console.log(item); // {name: "apple", color: "red", price: 1.99, sale: 0.99, quantity: 10}
```



The rest parameters syntax provides an easy way to pass an indefinite number of arguments to a function as an array. Rest parameters syntax allows a function to be called with any number of arguments, no matter how it was defined. Rest parameters syntax was added in ES2015 or ES6.

Let's define a function that uses rest parameters.

```typescript
function sum(...values) { 
  let sum = 0; 
  for (let value of values) { 
    sum += value; 
  } 
  return sum; 
}

console.log(sum(1)); // result is 1
console.log(fun(1, 2)); // result is 3
console.log(fun(1, 2, 3)); // result is 6
```

## Rest parameters at the end

A function can have its first parameters as variables, and gather only the rest using the rest parameters syntax. The rest parameters must be the last entry in a function's parameters because they gather all remaining arguments.

```typescript
function getFullName(firstName, lastName, ...titles) {
  console.log(titles[0]); // CEO
  console.log(titles[1]); // CIO
  console.log(titles[2]); // COO
  console.log(titles[3]); // undefined
  console.log(titles.length); // 3

  return `${firstName} ${lastName} - ${titles.join(', ')}`;
}

const fullName = getFullName('John', 'Smith', 'CEO', 'CIO', 'COO');
console.log(fullName); // John Smith - CEO, CIO, COO
```



One of a developer's duties is to manage a project's technical debt. Technical debt, also known as tech debt, refers to the amount of technical work remaining on a project. 

## Quantifying tech debt

Technical debt is hard to quantify. Developers working on a codebase are able to identify the technical debt. They must figure out how to communicate this technical debt to management. Management will likely ask for an estimate of how long it will take to eliminate the technical debt. 

A codebase is never really technical debt-free. Every technical decision that's made comes with some sort of tech debt that gets created. Deadlines don't always coincide with the amount of time that is needed to complete a task. Thus, technical compromises must be made made along the way, leaving traces of tech debt.

## Short-term and Long-term solutions

There is a short-term solution and a long-term solution to every problem or feature request. There is a tradeoff that is made for every short-term solution. Short-term solutions have a limited lifespan. Developers must keep in mind that they will have to re-visit the short-term solution and modify it into a more long-term solution.

Some may consider short-term solutions to be the result of laziness or sloppy coding. While short-term solutions are what cause tech debt to accumulate, they are also what allow products and features to be released by their deadlines.

## Tech debt and product roadmaps

Tech debt does not show up on product roadmaps. Product roadmaps show stakeholders a timeline of the delivery of new user-related features. Managers don't exactly want their stakeholders to know about tech debt. Also, most managers don't like the idea of spending time on tech debt because, in their mind, it does not result in any new features for the end user. Good managers know the importance of addressing tech debt and will buy the developers time for it. 

## Accumulation of tech debt

The lack of planning for tech debt causes developers to try to address it as they are working on features. It's difficult to juggle between features and tech debt without delaying the feature. The typical result is that tech debt is put on the back burner while the feature is developed.  

Tech debt can accumulate to the point where the codebase becomes unmaintainable. Just like financial debt, tech debt must be dealt with before it gets out of hand. 

## Code hygiene

Every codebase needs good code hygiene. If we don’t go to the dentist for five years and then finally decide to go, we will probably be in for an unpleasant surprise. Tech debt is like tartar. Left unaddressed, it builds up like plaque and creates problems. Keeping on top of tech debt is like going to the dentist regularly. It means regularly going into the codebase to address issues with the time that is available. 

Good code hygiene can consist of:

### 1. Removing unused code

If a developer suspects that a block of code is not being used, they should verify this assumption and then delete it if their assumption is correct. Adding it as a to-do item for later will only create more tech debt. If you have the time to do it now, do it now. We should always aim for having the least amount of code possible within a codebase. Less code means there is less to go wrong with the application. It also meansfaster build times and faster deployments.

### 2. Refactoring/restructuring code

When is the best time to refactor code? As soon as you notice it needs refactoring! Bad code has a way of spreading throughout a codebase without notice. When new developers join the team, they will end up copying the bad code and the practices that come with that bad code. You will then have more tech debt than you had initially. If a new feature will be built off of existing code, be sure to account for the time needed for refactoring when you estimate that new feature.

### 3. Rewriting code

Re-writing something from scratch sounds painful, but sometimes it is necessary. When refactoring a code block is not working out well, it means that this code block needs to be re-written. 

Good code can last for years without needing to be re-written. Bad code should be re-written as soon as possible.

## Tech debt and features

Always try tying in good code hygiene practices to a new feature. This will allow tech debt to be addressed sooner rather than later and make for more robust feature deliveries. It will also provide everyone with more realistic estimates. More realistic estimates can get you the time that you need from management to spend on code hygiene.

## Conclusion

Technical debt is a part of every codebase. Everyone involved with a codebase, managers included, needs to better understand tech debt and how it impacts the product. With a better understanding of it, there are greater chances tech debt will be addressed sooner rather than later.

In every release, take the time to apply good code hygiene practices so that tech debt does not get out of hand. 

If you're working in an Agile environment, create tasks and/or stories that address tech debt. Come to an agreement with your team on how many tech debt tasks or stories should be taken during each sprint.


> "They should have spent more time dogfooding that app! It's so bad!" - Techies

The term "dogfooding" is slang in the world of Information Technology (I.T.) for a company using its own products to find and resolve bugs.

## History of dogfooding

The term originated from a popular 1976 TV spot for Alpo dog food, starring Lorne Greene. Lorne fed Alpo dog food to his own dog in the commercial. Since then, "dogfooding" or “eating your own dog food” was adopted as the term that refers to trying a product internally before it goes to market. It is a widely accepted practice of most organizations.

## First use of dogfooding

The first use of "dogfooding" was in 1988, when Microsoft executive Paul Maritz was desperately searching for users to test a new product. Paul e-mailed a colleague saying, “We are going to have to eat our own dogfood and test the product ourselves.” They then created an internal server called “dogfood” and sent the product out to staff.

## A recent example

A more recent example of "dogfooding" comes from the on-demand ride app, Lyft. They take their dogfooding efforts seriously. All corporate employees, including executives, are required to spend at least 4 hours as a Lyft driver every quarter. This puts them in the driver's seat and allows them to test out the Lyft app as if they were an actual user of it.

## Benefits of dogfooding

Teams that don't engage in "dogfooding" may end up building a product that they only think a user wants. The product can become a solution that was looking for a problem to solve rather than a solution to an actual user need. If a solution solves a real user need, employees should naturally want to use it. 

Dogfooding shows that a team or company is confident about its products. Dogfooding is a good opportunity to view your own product from the perspective of an end user, allowing you to validate that the user experience is exactly what you want it to be.


Tools like React, Angular, and Vue provide us with a component-based architecture. We can build complex user interfaces from smaller pieces called components which are easier to manage. If we design our components properly, we can take advantage of the benefits of components. One of those benefits is reusability.

When building components, they should be decoupled, focused on a single responsibility, and well-tested. This can be difficult when we hurry to meet deadlines.

We should avoid doing the following:
- building big components with many responsibilities
- building tightly coupled components
- building components with no unit tests. 

Avoiding these bad practices will help us reduce technical debt. Once technical debt accumulates, it makes it hard to modify existing functionalities or create new functionalities.

Good components should apply the following principles:

1. Single Responsibility
2. Loose Coupling
3. Encapsulation
4. Composition
5. Reusability
6. Testability
7. Categorization
8. Readability

## 1. Single Responsibility

The single-responsibility principle (SRP) is a programming principle that states that every module, class or function in an application should have responsibility over only a single part of that application's functionality.

For web components, this means that a component has a single responsibility when it implements one responsibility, or  when it does one thing. This gives the component only one reason to change.

Some examples of a component's responsibility could be to render a list of items, to make a HTTP request, or to draw a chart. A component should pick only one responsibility and implement it. When modifying the way a component implements its responsibility, it has only one reason to change. If the component's responsibility is to render a list of items, then it's one reason to change could be when the limit to the number of items rendered needs to change.

When a component has only one responsibility, it makes it easier to code, modify, reuse, and test. The size of the component is reduced and the component is given a laser focus.

Components with many responsibilities should be split by individual responsibility into separate components.

When a component has multiple responsibilities, it is fragile, and has many reasons to change. This is risky because changing the component for one reason can affect how other responsibilities are handled by that same component. We want to avoid unintentional side effects because they are hard to predict and handle. We want the modification of our component to happen in isolation so that it doesn't inadvertently affect anything else.

The worst case scenario of building a component with multiple responsibilities is creating a God component. This is an anti-pattern (a counterproductive pattern). God components tend to know too much and do too much. God components should be broken down by their individual responsibilities into separate easy to manage components.

## 2. Loose Coupling

Coupling defines the degree of dependency between two or more components. Loose coupling happens when an application's components have very little or no knowledge about other components. 

On the contrary, tight coupling happens when an application's components know many details about each other and depend on each other. Tight coupling makes it difficult to modify a component because it is highly dependent on other components. Just one small change in one component could break several other components or require that they also be updated. Therefore, we want the relationships between our components to be loosely coupled.  

The benefits of loose coupling are:

- Making changes to one component does not affect the other.
- Components can be replaced without impacting other components.
- Components are reusable across the application.
- Testing is made easier.

## 3. Encapsulation

A components should not know about or rely on another component's internal implementation details. Components that are well encapsulated hide their internal structure from other components. This isolates the component. However, components still need to communicate with each other. To accomplish this in React, we can provide props to change the behavior of a component. To accomplish this in Angular, we can provide inputs. Inputs and props should be as plain and raw as possible.

An example of broken encapsulation is when a component's internal structure spreads across an application. If a child component is permitted to directly update the state of the parent component, encapsulation is broken. This is because the child component knows too many details about its parent. 

What details does the child know about its parent in this example?

- The child knows that its parent is a stateful component.
- The child knows the parent's state object structure.
- The child knows how to update the parent's state.

## 4. Composition

Composition refers to combining components to create a bigger component. Composition is like playing with Legos. It refers to taking a set of small pieces, combining them, and creating something bigger. 

The Single Responsibility Principle we saw earlier described how to split responsibilities into components. The Encapsulation Principle that we just saw described how to organize components in isolation. The Composition Principle describes how to glue the whole system of components back together.

An example is having an `<App>` component that has had its responsibilities divided into four sub-responsibilities, creating four new components: `<AppHeader>`, `<AppFooter>`, `<MainContent>` and `<Sidebar>`.

Composition then glues back `<App>` from these four specific components. The `<App>` component becomes responsible for rendering the `<AppHeader>`, `<AppFooter>`, `<MainContent>` and `<Sidebar>` components. Composition has helped us to make the `<App>` component adhere to the Single Responsibility Principle by allowing each of its children implement  sub-responsibilities.

Composition has helped us build our application with a very clean and simple organization. Components that are built with composition in mind are able to reuse common logic. This helps us to achieve the next principle, reusability.

## 5. Reusability

The Reusability Principle allows us to write a component once and use it many times. We want to make things work and reuse their functionality, not reinvent how they work.

The **Don't repeat yourself (DRY)** principle can help us achieve reusability. It states that every piece of information should have one single representation within an application.

A lack of reusable components will make the application harder to maintain without providing any benefits. Without reusability in place, a piece of application logic will not be self-contained in one place. This means that an update to that logic will mean updates to many parts of the application.

Components that have only one responsibility are the most reusable ones. However, when a component has many responsibilities, reusing it becomes complicated. You may want to reuse only one of its responsibilities, but you will be forced to accept all of its other responsibilities along with what you need.

## 6. Categorization

Part of having a good component architecture involves properly categorizing components. Our application should make a distinction between Smart and Dumb components, or Container and View components. Smart or Container components focus on how things work. Dumb or View components focus on how things look.

Smart components:

- Manipulate data: fetching, manipulating, and passing down data.
- Are stateful: managing application state (Redux, etc) and re-rendering needs.
- Do not include styling.

Dumb components:

- Focus solely on the styling and presentation of elements.
- Accept inputs/props to allow them to be dynamic and reusable.
- Have no dependencies.
- Have no application state.

Examples of dumb components are inputs, modals, buttons, dropdowns, etc. A dumb component may have local state for handling user interactions, but it will not know about the state of the application's data.

By making this distinction between smart and dumb components evident in how we name them and organize them within our file hierarchy, we will have a better designed application. Presentation responsibilities will be organized in dumb components. Stateful and business logic responsibilities will be organized in smart components.

## 7. Testability

A testable component is one that is easy to test. We should test that a component returns the expected output for a given input. We should aim for component purity because it makes components easier it is to test. A pure component is like a pure function, it will always return the same same output for the same input.

It's very difficult and time-consuming to manually verify that each component is working as expected every time we make a change. Bugs are inevitable without proper unit tests for each component. Unit tests allow us to automate the tedious task of component testing. Every time we modify a component, we can re-run it's unit tests to verify that they still pass.

Unit tests don't only help us reduce bugs, they also help us to have a good component architecture. If a component in our application is not testable or difficult to test, it means that the component has not been designed properly. 

One of the main reasons that developers do not write tests for their components is because their components are not testable. When a component does not adhere to the principles mentioned in this article, testing it becomes very difficult and frustrating. As a result, the developer gives up writing unit tests for it.

## 8. Readability

A readable component is one in which it is easy to understand what it does. A readable component has readable code within that component. This allows developrs to quickly understand the responsibility of a component when looking at its code.

- Aim for clarity over brevity when naming things.
- Name components by their responsibility.
- Include code comments in components.

When naming components, be specific. Consider what their responsibility is. Instead of `<Posts>`, consider `<FetchPosts>`, `<FeaturedPosts>`, `<PostsContainer>`, `<PostsPage>`, etc.

## Conclusion

In conclusion, the eight principles for a good component architecture that we covered are: single responsibility, loose coupling, encapsulation, composition, reusability, testability, categorization, and readability. By applying these principles when designing components, you can ensure a robust and effective component architecture in your applications.



Single-page Apps (SPAs) are named this way because there is only one single HTML document that is served to a client via the browser. While you may be navigating away from a particular page and the link in the address bar is updated accordingly, you are still on the same root page (index.html). The  browser doesn’t refresh the page and there’s no actual new page that gets loaded. 

When a user navigates to a new page in a Single-page App, the DOM is used to update portions of the current page, as specified by the JavaScript code of the SPA. SPAs do not require page reloading during use. Examples of SPAs are Gmail, Google Maps, Facebook, Twitter, or GitHub. 

SPAs request a page's markup and data independently and render the page directly to the browser. JavaScript frameworks such as Angular, and JavaScript libraries such as React and Vue allow us to easily build a SPA.

SPAs are different from Multi-page applications (MPAs) which use a client-server architecture. With MPAs, a server needs to re-serve a page's resources (Ex: HTML, CSS, scripts, data) with every page refresh or page navigation. When loading a new page, the browser will need to download all resources for that page from the server, even if the page contains components that are repeated on several pages (Ex" header, footer). This can decrease a website's speed and performance.

## Pros of SPAs

- Since SPAs don’t update the entire page, but only specific sections of a page, they improve a website’s speed.
- They are fast. Most resources (HTML, CSS, Scripts) are typically only loaded once during the user's session. 
- Development is simpler because you don't need to use a server or write server-side code in the front-end application.
- They are easy to debug with modern browsers like Chrome. Network operations can be monitored for data retrieval, and web components injected in the DOM can be inspected.
- A SPA serves as a good base for future mobile app development. Example: If you build a SPA in React, you can easily transition it over to React Native for a mobile app.

## Cons of SPAs

- The first launch of a SPA takes a bit longer to load compared to traditional multi-page applications (MPAs). The SPA typically downloads all the HTML, CSS and JavaScript files on first page load. After this initial load, the following actions occur almost instantly.
- Dealing with browser history in a SPA can be difficult due to soft navigation, where a URL changes in the browser but it doesn't actually re-load an entire page. The History API in HTML 5 (ex: pushState) helps to solve this.
- SPAs aren’t search engine friendly by nature. Most search engines don’t like JavaScript. 

## SPAs and Search Engines

Googlebot, Google's crawler has gotten better at indexing JavaScript-based websites and SPAs. Search engine crawlers typically visit a URL and parse the HTML response, expecting it to contain all the content of a page. With SPAs, the initial HTML does not contain the actual content. Googlebot needs to execute JavaScript before being able to see the actual page content that JavaScript generates. 

With Server-Side rendering (SSR), all of the HTML content of a page is present in its source code. This means that the search engine can request, crawl, and index it immediately. SSR can be achieved with [Next.js](https://nextjs.org), [Angular Universal](https://angular.io/guide/universal), and others.

> Keep in mind that not all search engine bots today can run JavaScript effectively to properly index a  SPA without Server-Side rendering (SSR). 

Let's take a brief look at the traditional rendering approach of SPAs called Client-Side > Rendering (CSR) and then compare it with Server-Side Rendering (SSR).

## Client-Side Rendering (CSR) steps

Here are the steps taken when a SPA is rendered on the Client-Side.

1. User's browser sends a request to a URL.
2. Browser receives the `index.html` file from the server as a response.
3. Browser sends requests to download any remote links or scripts.
4. Browser waits for any scripts to be downloaded.
5. Browser makes any API requests via AJAX to fetch a site's dynamic content and processes it.
6. SPA library/framework renders the component passed to it and its content in the client's browser.

Because of the fetching and processing data on the Client-Side, this form of rendering is called Client-Side Rendering. 
Until the above piece of code executes, the user will just see a blank screen. This is not a problem but can be frustrating when a web server is experiencing latency or for users with a slower internet connection.

## Server-Side Rendering (SSR) steps

Here are the steps taken when a SPA is rendered on the Server-Side.

1. User's browser sends a request to a URL.
2. A node server responds by running code that rendering the requested component into a string.
3. The rendered component is injected into `index.html`.
4. The `index.html` file is sent back to the browser.
5. The browser renders the `index.html` file and downloads all the site's dependencies.
6. Once all the site's scripts are loaded, the component is rendered to the DOM of the client's browser and any needed event handlers are added.

This type of rendering is called Server-Side because all the work of getting dynamic content, converting it to HTML, and sending it to the browser is done on the server. SSR renders the complete HTML in advance. This uses memory and processing power on the server. This can increases page load times compared to Client-Side Rendering.


Have you ever written Angular code like this?

```typescript
<div *ngIf="movies">
  <div *ngFor="let movie of movies">
    <h2>
      {{ movie.title }}
    </h2>
  </div>
</div>
```

Or, like this?

```typescript
<div *ngFor="let movie of movies">
  <h2 *ngIf="movie.id">{{ movie.title }}<h2>
</div>
```

The reason the code is written this way is because we cannot combine `*ngIf` and `*ngFor` on one `<div>` element in Angular. We are unable to use multiple structural directives on a single host element in Angular. 
Thus, we need to introduce a hierarchy of `<div>` tags. 

The code blocks above work fine but they introduces several extra empty `<div>` tags in the DOM. As the elements in the DOM start to grow, this can get problematic. Elements might have event listeners attached to them which will still be there in the DOM listening to events even when they are not needed.

The worst part of these code blocks is the level of nesting that you will have to deal with when applying CSS styling to elements.

## ng-container to the rescue

Angular's `<ng-container>` is a grouping element that Angular does not put in the DOM. This means that it will not interfere with styling or layouts. 

If you simply need to apply multiple structural directives, such as `*ngIf` and `*ngFor` to a code block, use `<ng-container>` to avoid introducing an extra element in the DOM.

```typescript
<ng-container *ngIf="movies">
  <div *ngFor="let movie of movies">
    <h2>
      {{ movie.title }}
    </h2>
  </div>
</ng-container>
```

The `<ng-container>` element will not render to the page. The only content that will be added to the DOM will be what is inside of the `<ng-container>` element.



Though these are both comparison equality operators, the triple equals, `===`, is what is called a strict equality operator, while the double equals is a loose equality operator.

## Strict equality

Strict equality compares both the value and type of the values on both sides of the `===` operator. 
If the value is the same but the type is not, the equality check will evaluate to false. The values will be considered unequal if one of the values has a different type. With `===`, you are ensure that the values are strictly equal or identically equal because it never does type conversion.

```typescript
4 === "4" // false
```

This expression will evaluate to `false`. Though they appear to be of the same value, the left operand is of type `number` while right operand is of type `string`.

## Loose equality

The double equals operator `==` performs type conversion on values if their types differ and then compares them for equality. If the types differ, either or both operands are first converted to a common type. The conversion rules are complex and depend on the types of the values compared. 

```typescript
4 == "4" // true
```

Why are these two deemed to be equal? This is because the `==` operator first converts the values before comparing them for equality.

```typescript
4.toString() = "4" // first step: conversion
"4" == "4" // second step: comparison
```

Here is another example.

```typescript
"0" == 0  // true because ToNumber("0") === 0
```

Using `==` can seem easier because type conversion is built-in, but be aware that it can give you unwanted results.

```typescript
console.log(11 == "11"); // true
console.log(0 == false); // true
console.log(' \n\n' == 0); // true...really?
console.log(' ' == 0); // true...really?
```

## Inequality

When writing a not-equals-to expression, the same rules above apply. However, instead of triple-equals (`===`) versus double-equals (`==`), it's a double-equals (`!==`) versus a single equal (`!=`).

Here are some examples with `!=`.

```typescript
console.log(11 != "11"); // false
console.log(0 != false); // false
console.log(' \n\n' != 0); // false (misleading)
console.log(' ' != 0); // false (misleading)
```

Here are some examples with `!==`.

```typescript
console.log(11 !== "11"); // true
console.log(0 !== false); // true
console.log(' \n\n' !== 0); // true
console.log(' ' !== 0); // true
```

## Conclusion

The recommended approach is to stick to the Strict Equality operator `===` when possible. This will help maintain data type integrity throughout the project's codebase.

Keep in mind that these comparison operators are only for comparing primitive types. For comparing the deep equality of objects or arrays, a different approach will be needed.



`null` and `undefined` may seem to be the same value, but they actually have subtle differences in JavaScript.

## JavaScript primitive values

In JavaScript, there are six primitive values. Both null and undefined are two of them. The primitive values are:

- Boolean
- Null
- Undefined
- Number
- String
- Symbol

All other values besides these are objects (objects, functions, arrays, etc.).

## Falsy values

In JavaScript, there are six falsy values. Both null and undefined are two of the six. The list of falsy values are:

- false
- 0 (zero)
- "" (empty string)
- null
- undefined
- NaN (Not A Number)

All other values in JavaScript are considered truthy.

## What is null?

null is an empty or non-existent value. It literally means nothing.

```typescript
const a = null;

console.log(a); // null
```

Null must be assigned. If `const a` was not assigned to null, it would be `undefined` and not `null` when we `console.log()` it.

## What is undefined?

Undefined usually means that a variable has been declared, but not defined.

```typescript
let b;

console.log(b); // undefined
```

We can also declare a variable to be undefined.

```typescript
let c = undefined;

console.log(c); // undefined
```

If we try looking up the non-existent properties in an object, we will receive undefined.

```typescript
const user = {};

console.log(user.name); // undefined
```

## Equality checks

`null` does not strictly equal `undefined` because they are not of the same type. As we saw above, they are two different types of primitive values in JavaScript.

```typescript
console.log(null !== undefined); // false
```

However, `null` loosely equals `undefined`.

```typescript
console.log(null == undefined); // true
```

### Triple Equals

Triple equals `===` tests for strict equality. This means that both the type and the value that we are comparing have to be the same.

### Double Equals

Double equals `==` tests for loose equality and preforms type coercion. It compares two values after converting them to a common type.

## Function parameters

Consider the following function that prints out the name that is passed to it as a paramter.

```typescript
function sayHello(name = 'John') {
  console.log(`Hi ${name}!`);
}
```

Passing `undefined` will cause the function to use the default value of the parameter.

```typescript
sayHello(undefined); // Hi John!
```

Passing `null` will not make use the default value of the parameter.

```typescript
sayHello(null); // Hi null!
```



Here are three JavaScript functions that can help you check for a value in an array. Keep in mind that they are all case-sensitive. 

## Using includes()

<div class='filename'>includes.js</div>

```javascript
const fruits = ['apple', 'banana', 'peach'];

fruits.includes('apple'); // true

fruits.includes('mango'); // false
```

## Using indexOf()

`indexOf()` will return `-1` when the item is not found. 

<div class='filename'>index-of.js</div>

```javascript
const fruits = ['apple', 'banana', 'peach'];

fruits.indexOf('apple'); // 0

fruits.indexOf('apple') !== -1; // true

fruits.indexOf('rasberry'); // -1
```

## Using some()

<div class='filename'>some.js</div>

```javascript
const foods = ['pasta', 'pizza', 'chicken'];

foods.some(food => food === 'pasta'); // true

foods.some(food => food === 'fish'); // false
```

`some()` can also be used with an array of objects.

<div class='filename'>some-objects.js</div>

```javascript
const foods = [{ name: 'beef' }, { name: 'chicken' }];

foods.some(item => item.name === 'beef'); // true

foods.some(item => item.name === 'fish'); // false
```


In JavaScript, there are three ways to create strings, or string literals.

We can use single quotes:

```typescript
const hello = 'Hello, World!';
```

We can use double quotes:

```typescript
const hello = "Hello, World";
```

We can use a pair of backticks, which permits string interpolation.

```typescript
const hello = `Hello, World!`;
```

## String Interpolation

String interpolation consists of replacing placeholders with values in a string.

String interpolation in JavaScript is done by using template literals or template strings. These are strings with placeholders within the backticks.

```typescript
const value = 10;
const message = `The value is ${value}.`;
console.log(message); // The value is 10.
```

## The Placeholder

The placeholder can contain string variables.

```typescript
const hello = 'Hello';
const world = 'World';
const message = `${hello}, ${world}!`;
console.log(message); // Hello, World!
```

The placeholder can contain operators.

```typescript
const first = 2;
const second = 3;
const message = `The sum of ${first} and ${second} is ${first + second}.`;
console.log(message); // The sum of 2 and 3 is 5.
```

The placeholder can contain function calls.

```typescript
function sum(first, second) {
  return first + second;
}

const first = 2;
const second = 3;
const message = `Sum: ${sum(first, second)}.`;
console.log(message); // Sum: 5.
```

## Placeholder String Conversion

The expression in a placeholder is implicitly converted to a string.

A number in a placeholder is transformed into a string:

```typescript
const value = 11.2;
const message = `Number is ${value}.`;
console.log(message); // Number is 11.2.
```

The expression in the placeholder `${value}` is transformed into a string and inserted into the interpolation. 

If the placeholder contains an object, the object is converted to a string as well. The `toString()` method of the object is called to get the string representation of the object.

What if we insert an array into a template string?

```typescript
const myArray = [2, 4, 6];
const message = `The array values are ${myArray}.`;
console.log(message); // The array values are 2,4,6.
```
The `toString()` method on an array will do a `join(',')` on the array when it is converted to a string.

## Escaping placeholders

Since the placeholder `${}` holds a special meaning in interpolated strings, if we want to use a sequence of characters with `${}`, they must be escaped.

```typescript
const mySymbol = `Symbol ${xyz}`;
console.log(mySymbol); // ReferenceError: xyz is not defined
```

Using `${xyz}` directly will throw an error because `${xyz}` is expected to be a placeholder. Adding a backslash `\` before the placeholder will treat it as a sequence of characters instead.

```typescript
const mySymbol = `Symbol \${xyz}`;
console.log(mySymbol); // Symbol ${xyz}
```

The same is true for the following sequences of characters.

```typescript
const mySymbols = `Symbols \${xyz} \${xyz \${`;
console.log(mySymbols); // Symbols ${xyz} ${xyz ${
```
