
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.



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.