
## Do you know (Layouting history)

The first web page went live on August 6, 1991. It was dedicated to information on the World Wide Web project and was made by Tim Berners-Lee. Then came tables in 1993, where we could give layout to pages, but it was very bulky to the DOM. In 1997, Divisions, a.k.a divs was introduced and made the layout more simpler with floats and semantic rich and lighter with DOM. But then alignment was a problem for adjacent divs. In early 2014 flex layout was introduced which is very powerful to do component layout-ing. But then flex was also one dimensional. Either we could layout things horizontally or vertically. But now with css grid, we could leverage a 2D way to layout things.

## Getting started with CSS grid

Even though we have a lot of libraries for layout, they seem to add quite a lot of extra styles which is never required for a regular project. So what if we leverage browser capability to layout with a very few lines of code. And that is where CSS grid comes into picture.

Before diving into what and hows, let us understand a few key concepts for CSS Grid.

## Concepts

- **Container** : Like flex, we define a parent container where all its direct children behave as a grid element. And the container as a grid.
- **Grid item** : Immediate children to the grid container.
- **Grid line** : Separation of the grid cells. You could think of drawing table then the lines that you draw so that you mention the rows and columns.
- **Grid track** : The flow of cells in a direction, could be horizontal / vertical. This defines how the cells are going to be merged.
- **Grid cell** : Each cell in a row.
- **Grid area** : Combinations of cells. You could define a region with a name. A region consists of merged / unmerged cells.

![Concepts](/css-grid-blog-1.png)

## Creating our first grid

```
.container {
  display: grid;
  grid-template-rows: 40px 40px 80px 80px;
  grid-template-columns: 130px 230px 330px;
  // grid-template-columns: repeat(3, 1fr);
  // grid-template-columns: 200px auto 200px;
  grid-gap: 20px;
}
```

Here, we defined our container as grid. This is to tell the browser that this container would behave like a grid. All its immediate children would be the grid elements. Then we define how many rows and colums we would require in the **grid-template-rows** &amp; **grid-template-columns**. We specify the space between the cells with **grid-gaps**. See it is that easy. You could also use repeat and % values as well.

## Making our grid responsive

By setting the minimum and maximum values we could let our grid decide when to break to the new line. You could see an example [here](https://jagatjeevan.github.io/css-grid/2.html).

```
.container {
  display: grid;
  grid-template-rows: 40px 40px 80px 80px;
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
}
```

## Positioning our grid elements

One of the biggest advantage of having grid is that we could position our grid cells anywhere in the layout and other auto-adjust accordingly. This is done by specifying where to start and where to end. So without changing the html, you could now change the position of the cells. You could see an example [here](https://jagatjeevan.github.io/css-grid/3.html) and [here](https://jagatjeevan.github.io/css-grid/5.html). This can be generally used to do a quick mockup or change to showcase / validate your idea.

Note : The grid lines start with 1 and not 0. -1 refers to the last grid line.

```
.aside {
    grid-col-start: 1;
    grid-col-end: -1;
}
```

Aligning the content inside the grid cells, are same as of flex. I would cover it in a next blog to keep it short.

## Creating your own grid system

We could define a grid system for our project with a very few lines of code.

```
.container {
    display: grid;
    grid-template-columns: repeat(<no. of cols>, 1fr);
}
```

If you are using sass, them you could write a function for this

```
    @for $i from 1 through 12 {
      .col-#{$i} {
        grid-column-start: 1;
        grid-colimn-end: #{$i};
      }
    }


    @for $i from 1 through 11 {
      .push-#{$i} {
        grid-column-start: #{$i};
      }
    }
```

See a working example [here](https://jagatjeevan.github.io/css-grid/4.html)

## Bonus

We could create a image gallery using [css-grid](https://jagatjeevan.github.io/css-grid/image-gallery.html). Earlier we used to use a plugin to create the gallery. But now you could use css grid for the same. You could see the source code.

Hope you enjoyed reading and learning.


Layout your pages leveraging browser support with lesser lines of code. No need to use a bulky framework

Css Grid


## Sections of work that a frontend developer do

![Area of work](/area-of-work.png)


Understanding what Frontend developers do

Frontend: Area of work


## Manage Github profiles for different projects

We all have been working on different projects on our machines. It is important to keep the GitHub profiles separate and use them appropriately. In this blog we would make switching the profiles w.r.t. repositories easy.

The first step in the journey is to have folders segregated so that we know where to use a particular Github profile. You could use folders like personal, work, open-source, etc. The intention is to understand where to use a certain identity.

Then we would require a global git configuration that would channelise/map the folder structure and the respective identities. Since you are using GitHub repositories, a global file would already be in the machine. The filename would be `.gitconfig` at the root directory.

A sample git-config would look like this

```
[user]
  email = jagatjeevans@gmail.com
  name = Jagat Jeevan Sahoo
```

Now we create conditions to refer to some profiles. We can do this like the below code.

```
[includeIf "gitdir:~/personal/"]
	path = ~/.gitconfig-personal

[includeIf "gitdir:~/work/"]
	path = ~/.gitconfig-work
```

Thirdly, we would create profiles that we have mapped in the git-config file. Now we create config files and update the configuration like below. The below code is minimalistic. You could add more configurations depending on your requirement/project.

```
[user]
  email = kanhajeevan@gmail.com
  name = Jagat Jeevan Sahoo
```

Finally, we need to verify the changes that we have done. Check the file is present in the home directory.

```
l | grep '.git*'
```

You should see all the git profiles you created from step 2. Then we should check if you get their respective profiles in the project folder. For that, we dive into the folder and type the following command.

```
git config --list
```

The above command shows the configuration you could have just configured in your config file.


It is quite important to manage your github profile while contributing to your project, may it be your personal repo, office repos or open source. Let us look to manage profiles like pro.

Manage github profiles for projects


## Legends
*mfe: Micro-frontends
## Why do we need *mfe?
As the application grows, the modules grow, and so do the teams. The teams take ownership of specific features. To scale up the application and reduce the time to market is most important for the team to be autonomous. And this is where *mfe comes into the picture. With *mfe, we would have 
- `Functionality context` expertise with the team.
- Better `team management`.
- `Testing` individual functionality is easy.
- `Resilient`: Failure in one module does not affect other modules
- `Independent tech stack`: Teams can choose their tech stack
- `Independent deployment`: Teams can choose when they can go to deployment.
- `No extra code`: Only code required for the functionality is present.
- Easier to `upgrade` and check on the `performance`
- `Scaling` the feature with ease.
- Looking at the `bigger picture` while creating some functionality.
- It is a `tested way of working`. It follows the micro-services ways of things.

A few questions that need to be thought through before doing *mfe are:
- **Slicing**: How to break the application into multiple repositories or sections.
- **Compose**: How to compose these broken-down pieces together to run the application as one.
- **Communication**: How do these separate applications communicate with each other?
- **Testing**: How to test individual *mfe and also together as an application.

### Slicing
The first thing to think about is how to break the application. There is no right or wrong in which way you want to break the application. It all depends on how an architect thinks. Few of the ways people split the application are:
- **Routes**: Each route is a separate *mfe 
- **Functionality-based**: Each *mfe has a domain/functionality associated
- Keeping critical functionality separate

### Composing
Mostly there are four types of composing techniques used. Those are (Code Bundling + Composing technique):
- Build time + App shell 
- Build time + Reverse Composition
- Run time + App shell 
- Run time + Reverse Composition

**Build time**: The code is bundled when the code is compiled.
![build time composing](/micro-frontend/buildtime.png)

**Run time**: When the bundled code is fetched during the run time.
App shell Composition: When there is an application shell and content is rendered inside the app shell.
![run time composing](/micro-frontend/runtime.png)

**Reverse composition**: The application is sliced w.r.t routes. The commonly used modules are included in each of the *mfe.

### Communication
Generally, there are two ways of communication among *mfe. 

**Using a global object to communicate**: Each mfe uses a global object to transfer data to other *mfes. Here the global object is the window object. *Mfe uses window object, localStorage, sessionStorage, indexedDB, cookies, etc.

**Event-based communication**: Using custom events and event bubbling to communicate with other *mfe for communication. 

### Testing
**Unit testing**: There would not be any change in unit testing. It becomes easy for testing as there would be lesser codes in the *mfe.

**Integration testing**: There would not be much of a change here as well. 

**E2E testing**: The testing is very much needed. Since the application is broken into *mfes, it is very much required to make sure the test is well written and thoroughly tested.

Other necessities to take care of
- Team formation
- Authentication
- Cross mfe communication
- State management
- Logging
- Performance
- Feature toggles
- Release management
- Maintain ADRs

## Do we want MFE or not?
- It is highly recommended not to think of *mfe from scratch but keep the code modular.
- Moving the code from monolithic code to *mfe is a journey. 
- Have domain boundaries clearly stated. 
- Check on the pattern you would like to use in your application.
- It adds complexity. Look at the complexity vrs advantages before trying out.
- Play a devils advocate to be sure the problem statement is solved by microfrontend.

## References
- https://martinfowler.com/articles/micro-frontends.html
- https://www.thoughtworks.com/en-in/about-us/events/webinars/microfrontend
- https://www.youtube.com/watch?v=iZ-wIViaefc
- https://livebook.manning.com/book/micro-frontends-in-action/micro-frontends-in-action/

## Code
`https://github.com/jagatjeevan/xconf-mfe`

There are branches where we are moving the spa to various *mfes


Manage a huge mono repo with dividing the code into smaller repos. Managing the project with splitting the team with different functionality. Scale the application with ease. Micro-frontend is a tested way to scale up application.

Micro frontend


## Mono Repos

While it is a very good idea to break the application to smaller chunks and independent repositories wrt functionality, views or libraries, individual pages, etc, to deploy separately, manage independently. It becomes very difficult to know or manage things without absolute sync of the code. This is where mono-repo comes into play.

In short keeping all the different UI components in one repo may it be library, features, web applications, etc is what mono-repo is all about. Few of the benefits for mono repos are

- **Visibility**: Since all the feature and other libraries are in one repo, it is easy to refer and change.
- **Simpler dependency management**: This is the feature why mono-repo has evolved.
- **Consistency**: Enforcing various teams to be consistent wrt the design standards.
- **Atomic commits**: Feature wise commit. Since all the parts are inside one repo, it becomes easier to track to commit to central repository(git) in one go. It helps in understanding the code and commit by others.
- **Implicit CI**: Continuous integration is guaranteed as all the code is already unified in one place.
- **Unified CI/CD**: One can use the same CI/CD deployment process for every project in the repo.
- **Unified build process**: One can use a shared build process for every application in the repo.

While these are good using monorepo, there are some caveats as well. Those are:

- **Bad performance**: These are difficult to scale up. Commands like git blame may take unreasonably long times, IDEs begin to lag and productivity suffers, and testing the whole repo on every commit becomes infeasible.
- **Broken main/master**: A broken master affects everyone working in the monorepo. This can be seen as either disastrous or as a good motivation to keep tests clean and up to date.
- **Learning curve**: The learning curve for new developers is steeper if the repository spans many tightly-coupled projects.
- **Large volumes of data**: Monorepos can reach unwieldy volumes of data and commits per day.
- **Ownership**: Ownership of files is more challenging, as systems like Git or Mercurial don’t feature built-in directory permissions.
- **Code reviews**: Notifications can get very noisy. For instance, GitHub has limited notifications settings that are not best suited for a snow slide of pull requests and code reviews.

Before we dive deep into other things lets discuss about the concepts of it.

### How is module resolved ?

We can refer any functions by calling that function. If the function is in the current file, then it is just mapped. But if the function is in another file, we have to import. Node resolves this by 2 methods:

- Relative path with a period(.) to refer in the same folder or double period(..) to move up the folder
- Using the package name (loadash, react, react-datepicker, etc). Here node would search in the node_modules in the current directory. If the package is found, then the module is resolved, else it would go to the parent directory and search for node_modules there and if not found, then one more up in the parent directory. This way is called as the node_modules package resolution strategy.

### Linking a node_module

Symlink / Symbolic link / shortcut link to a file or directory. It is supported in Windows, Linux, MacOs and available in Npm and Yarn.
To link a particular module and register, we can go to the respective folder and run `npm link` or `yarn link` When we run the command, we could see there is a node_module folder and there is a copy of the directory inside where we run the command. If you are using VSCode, you could see the symlink symbol against the directory.

While going to respective folder and running npm link might be tedious for the development, npm and yarn have come up with workspaces to ease development.

### Workspaces

To create workspaces, we can tell node to create a symlink by adding `workspace` in package.json in the root folder. Below is an example for creating workspace in a mono repo. Here we are creating packages from the packages directory. Whenever we do a `yarn install` or `npm install`, symlinks are automatically created and linked. We have to do a force install whenever we are adding the workspaces. And once the symlinks are created, it should automatically be updated on change of the files.

```
File structure:
|- <monorepo_project_name>
|--- packages
|----- package-1
|----- package-2
|--- web-application-1
|--- web-application-2
|--- package.json
```

```
package.json
{
  name: 'monorepo project name',
  ... other things
  workspaces: {
    packages: ['packages/*]
  }
}
```

Since the symlinks are created in the parent folder node_modules, we might not require to hoist all the modules of any workspace to the parent. In that case we need to have a way to make sure we do not dump every module to the parent. This is also helpful in terms of dependency version management. For that we can use a `nohoist` key in the package.json like below:

```
{
  …
  workspaces: {
    …
    nohoist: [‘**/loadash’]
  }
}
```

`Note: There is a little difference between npm and yarn with hoist. Do check with increasing versions of npm and yarn.`

### Making executables

Though this is not the part of mono repo as such, thought to include it here as we are discussing about npm hoisting. You might have seen we could execute some of the cli command. Ever thought of how it is been done. Any executable module would be there in the ‘.bin’ folder inside the node_modules. This is where any executable is run from. If the module is installed globally then it would work in the terminal, else we have to create npm scripts and run them there.

#### How to create an executable

Add the executable file that need to run when the name of the package is executed. Then do a `npm install —force` to create a bin directory / update the bin directory if already present. Note force is required when there is no change in package-lock.json for npm install to work. And to work in the below example: my-executable would work in the script tag.
We need to make sure the index.js is run from node env. And for that we have to add a line in index.js as below:

```
Inside index.js
#!/usr/bin/env node
…. Code follows
```

```
Inside package.json
{
  …
  name: “my-executable”,
  bin: “./index.js”
}
```

Another module where my-executable is installed and want to execute it.

```
Inside package.json
{
  …
  name: “my-consumable”,
  script: {
    start: “my-executable”
  }
}
```

Inorder to name our executable, we could change our bin property from string to object.

```
Inside package.json
{
  …
  name: “my-executable”,
  bin: { <name_of_executable>: “./index.js” }
}
```

### Some syntaxes to keep it handy

Want to run a script for a specific package :

```
cd to that package and run the script
Or run from the parent folder: npm --workspace=package-name run <script_name>
Ex: npm --workspace=package-1 install react --save
```

Want to run a common script present in all packages:

```
npm --workspaces run <script_name>
```

Ignore missing script:

```
npm --workspaces --if-present run <script_name>
```

### Some of the tools for monorepo

- [**Lerna**](https://github.com/lerna/lerna): monorepo manager for JavaScript. Integrates with popular frameworks like React, Angular, or Babel.
- [**Yarn Workspaces**](https://classic.yarnpkg.com/en/docs/workspaces/): installs and updates dependencies for Node.js in multiple places with a single command.
- [**ultra-runner**](https://github.com/folke/ultra-runner): scripts for JavaScripts monorepo management. Plugs in with Yarn, pnpm, and Lerna. Supports parallel building.
- [**Monorepo builder**](https://github.com/symplify/monorepo-builder): installs and updates packages across PHP monorepos.


A single repositories to hold all the independent deployable projects/libraries and other parts of the project.

Mono Repos for micro-frontend


## Production Readiness

After checking the code locally and being confident of the code to move to production give much more satisfaction when it goes through the QA lane of the agile board. Then a go-ahead from client team is just icing on the cake.

Client would also want to check the best practices you would have implemented in the code. Incase you would like to check some of the list, you could check it [here](/blogs/project-setup). In this blog, we would like to cover the things beyond the code or the last leg before moving to production so that we could track and make sure we could handle the user request, have fail safe mechanism and threat modeling. Below are the few of the checks we could have it.

**Note:** Each of the category requires a detailed discussion, I would have a separate blog on each of the category. This blog only covers a high level topic to look at and understand it importance.

### Security

Making sure the security of the application is on top priority, always make every interaction secure. Frontend has been the first gate to interact with the user, so make sure the gate is properly secured from unwanted access. Similarly, the apis and databases should also be secured without relying on the previous gates. Below are the things to look at:

- Authentication and Authorisation of the pages, apis, and resources whenever they are asked.
- Avoid vulnerable keywords like 'document.write', 'window.open', etc
- Make sure the code is minified and uglified in the production
- White-listing the required domains and setting the CORS header.
- Make sure the sensitive data is not exposed and other PII details are not stored in browser.

### Availability

It is equally important for your product to be available to your users all the time, except during the maintenance. Also try making the downtime as minimum as possible. The application could be down for a number of reasons. One of the reason could be a hacker could bombard the apis programmatically to bring it down, which again funnels down to security. If the user base increase, then is the application flexible enough to handle such increase in request. Is the application scaling up easily.

### Performance

A lot of time, the user drops because of increased waiting time to respond to any request. It could be the webpage loading time, the webpage takes long time to respond, the apis are slow and takes long time to fetch, etc. It is important to have things under check and ways to measure performance of the webpage, apis, read/write operations to database, etc.

### Data consistent

While internet is world wide and the user can fetch data and update data from anywhere, it is equally important to check that the data that is shown to the users are consistent. With the data-heavy application, where data is money to the users, it becomes crutial to show the correctness of the data and handle any inconsistent data gracefully. Also with the cloud in place, and multi-servers in action, making data consistent across servers have become very crutial.

### Monitoring / Alerting / Metrics / Logging

While the application is in production, it is important to monitor the health of the application. Which are the apis are running good and which needs to be looked at.

While we figured out of the apis about which areas needs to be looked at, needs to be automated and alerted as we would not be able to always check on the apis manually everytime.

Once these are in place, in getting a record of data from the past history, it is always good to see how the application is performing over a period of time. And incase there is some suspicion over a part of the application regularly, metrics would be a good start to relook at the area.

While the application runs smooth most of the time, in some cases, it behaves badly for various reasons and things might fail. In order to find the exact root cause of the issue, it is important to log the transactions. And if the clients are working on financial where every paise matters, it becomes very crutial to check where it failed. And for this, Logging is a must.


Checklist on a very high level for moving the code to production.

Moving the code to production


# Why do we care ?

Experts say it is the future of e-commerce. [Here](https://www.pwastats.com/) are some stats.

In today's digital world, you would be either using a website or a mobile app to search, shop, socialize, learn, news, etc. For few of the use cases, websites would be more appropriate while some other cases, mobile apps would be more appropriate.

# When to choose mobile apps over creating a website

- Security : Man in the middle can not tweak code.
- Offline access
- Re-engaging : Notification

# When to choose creating a website rather than apps

- Easy access : No need to install and search in play store / app store
- No installation or down time : Deployment is easy, always get updates instantaneously. Use in mobile browser / web browser in device
- No permissions required
- Shareable : You could copy paste the url to someone.
- Easy Debugging / logging for the developers
- One searches web rather than mobile apps.
- Cost effective

The most important factor to consider while developing from the clients' end is costing while getting the best of both worlds. And this is where PWA comes into picture. Web has been evolving constantly and the way user wants to interact is also changed drastically. Let us have a look what [web can do today](https://whatwebcando.today/).

Now that we understand that web is very powerful today and could leverage a lot from the device capability. See it in action [here](https://whatpwacando.today/). It becomes very important to maintain the hygiene and sanity. You could have a checklist while creating a PWA project [here](https://web.dev/pwa-checklist/).

# When not to use PWA ?

- High Battery usage : https://clutch.co/app-developers/resources/pros-cons-progressive-web-apps
- Pwa components might not be fully supported like background-sync, notification. PWA community is growing fast.
- Graceful degradation and cost.
- Browser support compatibility : Check it [here](https://caniuse.com/)

# Few gotchas of components from PWA

While implementing the components of PWA, do make sure to check the gotchas.

- Cache-ing : One of the important feature of PWA is to cache and serve it from the cache for better performance and offline support. While you do cache-ing, make sure to invalidate the cache. For cache-bursting, you can check for the eTag, max-age, last modified date. Do check for the cache-ing stratergies for the specific requirement. Those are
  - network only : Used for sensitive data / where we would like to have live records like score of a live match, account statement of a bank account holder, etc.
  - cache only : Used for static data which generally do not change
  - Network first : When you want all live data but want to fallback on the cache if network not present.
  - Cache first : Checks the cache first and then checks the network.
  - Stale while revalidate : Triggers both network and cache and then updates the cache with the network data. These are the content which rarely changes.
- Background Sync : For flaky internet, how to roll back or maintain the state of how far it is synced. Offline first approach is the best way to check for background sync. Check for time to refresh the data. Various strategy for syncing for types of data like email, chats, photos and videos, etc.
- Push Notification : According to stats, more than 75% of the customer re-engage with the app by push notification. And stats also say that more than 14% of users stop the push notification becuase of too much of notification. So we need to make sure we are catious about

  - Timing : When to send notification
  - Content : Web Push Notification title, description, call to action
  - Target : User context to send a push notification i.e do not do a Notification bombarding
  - Relevancy & Setting : Where to land and the right time to go live. Get context of the user’s geolocation, device, etc
  - Intuitive for unsubscribe

- Add to homepage
  - Check for logo in various contrast. It might not be too evident in dark background or image background.
  - Default homepage, for PWA makes it installable.



Leveraging mobile device capability in web like offline, accessing device features, etc. Harnessing the power of both moblie and web world

Progressive Web Applications


## Project Setup

With the CLI(Command Line Interface) available for all projects now to setup / scaffolds the entire project with all the best practices, do we want to care of other things we might require in future ?

The CLI generally create a project on a framework and do not add extra things to keep things simple and cater to majority. I generally have some checklist which I use it as a default thing whenever I start a frontend project apart from what CLI provides. In this blog, I would share them with you.

- **Update Readme file** : This is the first thing that would come in github and anyone would see. So I generally have the following sections which help fellow contributors as well as others to know what this repository would do and how they use it. I generally have the following section.

  - Badges : Build status, Coverage, Dependable bot. Dependable bot alerts of security concern used in node_modules. You could check from github repo > settings > security and analysis
  - What does it do
  - Installation : How to run it and see
  - Tech Stacks Used
  - Some Practices followed in the repo
  - TODO / Fixme : This would give the fellow developers see what are the things they can contribute. This is not the features / delivery things as such. This is more in terms of setup / adding some good practices.

- **Node** : It is always better to mention the node version so that developer do not have to worry for your compatibility. Check the [end-of-life for node](https://nodejs.org/en/about/releases/) while choosing the version. It becomes very difficult to have more than one node version in a system and manage it. I generally use [nvm](https://github.com/nvm-sh/nvm) to manage my node versions and shift from project to project. Create a `.nvmrc` file and mention the version you are using.

- **.gitignore** : We only push the source code and other files and folder which would be required to build the project. We do not put any other files and folder which can be generated like node_modules folder. Any CLI would have these things already in place. Add other files and folder which can be generated.

- **Prettier** : Having a standard of writting code and making a default for all the editors so that the code looks decent, while committing the code, developer should not override each others' way of writting. Either we can use [editorconfig](https://editorconfig.org/) / [prettier](https://prettier.io/) for this matter. I feel prettier has a wider support.

- **Linters** : Linters enforces the best practices and should be present in a project. Most CLI would already include it. If you add any other enablers like typescript, sass, etc do add respective linters. There are few obvious ones which could be fixed without manual intervention. These can be fixed by the linter itself. So you sould put it some helpful command in the `package.json` under `scripts` section to have handy for anyone to contribute.

- **Testing and Coverage** : It is by default now that we need to have unit tests and coverage for our code. Unit tests make sure you do a basic sanity of your code is done before pushing the code. Coverage gives a understanding of the parts of the code we have not tested.

- **Pre-commit hooks** : While having all the good practices is not enough and we need to enforce all to practice to continue. This makes sure that we follow all coding standards before pushing the code to github.

- **Editor Settings** : Now a days, the editors have a good intellisense to point you errors while writing the code depending on the linters present in your project code. It becomes easy to understand and fix them while coding rather than while pushing the code.

- **Mock server** : With UI being a separate repo now, to run your code you might require some dummy data (API contract) to see something and test. If it is already set, people might find easy to see the features they are working on and define what should be the response API gives.

- **Multi-language support** : As most of the wants to global, it becomes very evident that the requirement might come for the support of multiple languages. It becomes very difficult to change the hard-coded values later. So if multilanguage support is already in place, it is just a matter of following it.

- **Localisation** : Every project deals with the date and currency in their project. It is better to localize these values. Set it up so that it becomes easy to deal with it. Check for other formatters you would like to add in the starting of the project.

- **Dockerfile** : If you are working on a large team, it would be quite obvious that the project would use Docker to run your project. And if so creating a optimised version of it would help others integrate your code with the complete set.

- **License** : Every project should have a license for their project which tells the user if they could leverage from their project.

- **Bookmarks** : It is always important to have your bookmarks segreggated. It makes it handy to access the resources and refer.

- **Github settings** : Since you would be contributing to a project, it is always better to make sure you update the code with the github profile associated. To create one, read [here](/blogs/manage-github-profiles). You can add the ssh-key to avoid typing the username and password all time while pushing the code to the repository.

You might also want to look into the checks for moving the code to production. You could check it [here](/blogs/moving-the-code-to-production).


While setting up a project, we tend to miss some obvious defaults which might take a bit more time than usual if not setup earlier. In this, we would see some of the sensible defaults web has evolved and we should have it in the start of the project.

Project Setup


## Philosophy
- Data-driven way of creating react forms from JSON structure. 
    - The JSON structure is referred to as the schema here.
- It has quite a lot of variety for UI handling, to customise look and feel, beyond themes.
    - This is done by passing “uiSchema” 

## Installation and usage
```
npm install @rjsf/core --save
import Form from "@rjsf/core";
```
**Note :** 

Latest Reactjsonformschema version require 16+ for React.  For React 15, use 1.x version of reactjsonformschema.

**Sample Code :** 
```
import Form from "@rjsf/core";

const schema = {
  title: "Test form", // Title of the form
  description: "Exploring React json schema form", // Description of the form
  type: "string", // type of the field
  enum: ["one", "two", "three"], // Values the field can have
};

<Form
	schema={schema}
	uiSchema={uiSchema}
	formData={formData}
	onChange={(e) => setFormData(e.formData)}
	onSubmit={onSubmit}
	onError={onError}
/>
```

## Schema
It is the segregation of the individual form elements in a json format. The global level is in the parent level and the individual element configuration is inside the element property.

```
const schema = {
	title: “Here goes the title of the form”,
	type: “object”,
	properties: {
		name: {
			type: “string”,
			enum: [“name”, “age”, designation]
			enumNames: [“Name”, “Age as on 01/01/2020”, “designation in the current company”]
		},
		age: {
			type: “number”,
			enum: [1,2,3,4,5,6,7,8,9]
		}
	},
	required: [“name”],
	additionalProperties: {
		type: “number”,
		enum: [1,2,3]
	}
};

const uiSchema = {
	classNames: “custom-css-class-for-form”,
	name: {
		classNames: “custom-class-for-name-element”
	},
	“ui:title”: “This is going to override the title value”,
	“ui:description”: “This would override the description value”,
	“ui:order”: [“age”, “name”], // This is the order in which the elements comes
};

<Form schema={schema} uiSchema={uiSchema} />
```
Each property has a specific functionality
- The `type` can have values: string, object, array, number, integer, boolean, null. If the type is an object, then you have properties. The form element can have multiple types of values. Those are represented by an array.
const schema = { type: [‘string’, ‘number’] }
- The `properties` would have the types of the input form elements. Each item inside properties would have an element described.
- The `enum` have the selected values for the specific field.
- The `enumNames` is the custom names to be shown on UI for a better experience 
- The `uiSchema` key holds the UI configuration like classnames. The values can override the schema values like ui:title and ui:description can override values of title and description in the schema. ui:enumDisabled: This can disable the enum values.
- The `required` key defines the keys which are mandatory to be filled.
- The `additionalProperties` allows setting arbitrary keys and values to the form. This is like adding keys and values on the fly. There would be a button given by the library to add the type of values. Override the expandable value in `ui:options` inside uiSchema. If the value is set to false, the button would not be shown.	

## Form Data : Initialisation of a form
This is helpful in initialisation of the form. 
```
const schema = {
	type: “object”,
	properties: {
		title: { type: “string” },
		done: { type: “boolean” }		
	}
};

const formData = {
	title : “String value for title key”,
	done: true
}

<Form schema={schema} formData={formData} />
```

**Note: **
- If the form has a single field, then the formData would be just the value like formData = “Charlie”.
- If the parent component re-renders, make sure to listen to the `onChange` method and update the data in formData.
- Make sure the structure of the schema and the form data is same.

## Form Events
There are events such as “onChange”, “onError”, “onSubmit” and “onBlur” on the form component.

By default, form is an uncontrolled component, to make it controlled, we have to pass onChange method like below.
```
const [formData, setFormData] = useState(props.data);
<Form formData={formData} onChange={e => setFormData(e.formData)} schema={schema} />
```

## Schema definitions and references
We can have reusable structures which can be used to represent the structures of similar form sections like below. This uses JSON pointer.
```
const schema = {
	definitions: {
		address: {
			type: object,
			properties: {
				street_address: { type: “string” },
				pincode: { type: “number” }
			},
			required: [“street_address”, “pincode”]
		}
	},
	type: “object”,
	billing_address: { “$ref”: “#/definitions/address” },
	permanent_address: { “$ref”: “#definitions/address” }
};
```

# Dependencies
Jason schema form can define dependencies of fields
```
Const schema = {
	type: “object”,
	properties: {
		relation: { type: “string”, enum: [“father”, “mother” ]}
		gender: { type: “string”, enum: [“male”, “female”, “other” ]}
	},
	dependencies: {
		“gender”: [“relation”],
		“relation”: [“gender”]
	}
}
```

There could be bi-directional dependencies. In that case, have it under dependencies. The library also provides a section of the form to be changed depending upon what is selected.

Modifying some parts of the form depending upon some change in other fields
```
Const schema = {
	type: “object”,
	properties: {
		name: { type: “string” },
		credit_card_number: { type: “number” }
	},
	dependencies: {
		“credit_card_number”: { 
			properties: { “billing_address”: { type: “string” } },
			required: [“billing_address”]
		}
	}
}
```

More variety
```
Const schema = {
	type: “object”,
	properties: {
		“Do you have any pets ?”: { type: “string”, enum: [“none”, “one”, “more than one”], default: “none” },
		required: [“Do you have any pets ?”]
	},
	dependencies: {
		“Do you have any pets ?”: {
			“oneOf”: [
				properties: { 
					“Do you have any pets ?” : { enum: [ “none” ] },
				},
				properties: {
					“Do you have any pets ?” : { enum: [ “one” ] },
					“How old is your pet”: { type: “number” }
				},
				properties: {
					“Do you have any pets ?” : { enum: [ “more than one” ] },
					“Do you want to get rid of any”: { type: “number” },
					required: [“Do you want to get rid of any”]
				},
			]
		}
	}
}
```

## Validation
React JSON schema form uses “ajv”  validator by default. By default, the form is validated only when the form is submitted, if we want liveValidation, we have to use the attribute “liveValidate” on the form component. This is an expensive strategy. The form uses html5 validation. This again depends on the browser support. We can disable html5Validation with “noHtml5Validate”.

- Live Validation
```
<Form schema={schema} liveValidate />
```

Custom validation rules
```
Const validate = (formData, errors) => {
	if(formData.pass1 !== formData.pass2) {
		errors.pass2.addError(“Password do not match”)
	}
	return errors;
}

Const schema = {
	type: “object”,
	properties: {
		pass1: {type: “string”, minLength: 3},
		pass2: {type: “string”, minLength: 3}
	}
}

<Form schema={schema} validate={validate} />
```

**Note: **

The validate method always return errors.

### Custom Error functions
Some default error messages are provided. In case we want to change the messages, we can use the `transformErrors` function. We can have a check on `error.name` or `error.property`. error property would have the object name.

```
Const transformErrors = errors => {
	return errors.maps(error => {
		if(error.name === “pattern”) { error.message = “only digits allowed” }
		return error
	})
	return errors;
}

Const schema = {
	type: “object”, 
	properties: { name: { type: “string”, pattern: “^\\d*$” } }
}

<Form schema={schema} transformErrors={transformErrors} />

Custom Formats
Const customFormats = { ‘phone-us’: /$?\d{3}$?[\s-]?\d{3}[\s-]?\d{4}$/ };
<Form schema={schema} customFormats={customFormats} />
```

### ExtraErrors
This is used for handling async errors. Suppose errors are sent on form submit.
```
const extraErrors = {
	foo: { __errors: ["some error that got added as a prop"] },
	candy: { bar: { __errors: ["some error that got added as a prop"] } }
};
```

## oneOf, anyOf, allOf
This is generally used in validations where the following conditions are true.
- oneOf : exactly one schema is valid
- anyOf : at least one schema is valid
- allOf : all the sub-schema are valid
```
oneOf
Const schema = {
	type: “object”,
	oneOf: [{
		properties: { typeOf: { type: “string”, enum: [“none”, “oneOf”] } }
		required: [“typeOf”]
	}, {
		properties: { name: { type: “string”}, age: { type: “number” } },
		required: [“name”]
	}]
}
```
Similarly, we have anyOf and allOf in the same fashion

## Widgets
The “ui:widget” property in “uiSchema” tells which component to render.
```
const schema = {
	type: “object”,
	properties: { done: “boolean” }	
}

const uiSchema = {
	done: { ui:widget: radio }
}
```
List of data types and ui:widgets available
### Boolean:
- Radio with values true and false
- Select with true and false
- By default, the checkbox is used/shown.
To set the labels on the fields, use enumNames in the schema. The order is always [true, false]


### String:
- Textarea
- Password
- Color
- By default, <input type=“text” /> is used
Formats: To get formats given by the browser, we can use the format property in the schema. Below are the formats supported
- Email 
- Url
- Data-url
- Date
- Date-time
```
Const schema = {
	type: object,
	properties : { email: { type: “string”, format: “email” } },
	required: [“email”]
}
```

### Number and Integer:
- updown : [input type=“number”] with up-down selector
- Range
- Radio: The values are provided in the enums
- By default, the value would be <input type=“text” />
Note: If the minimum, maximum and multiple are specified, then the “min”, “max” and “step” values are taken.

### Hidden:
Mention in the uiSchema to have hidden values in the form. Hidden values are supported for boolean, string, number and integers

### File:
This is basically <input type=“file” /> It would propagate the file contents to the data-urls
2 ways to declare:
- Type is string, and format is “data-url”
- Type is string, and ui:widget: file
And for multiple files, 
Schema would be 
```
Const schema = {
	type: array,
	items: { type: “string”, format: “data-url” }
}
const uiSchema = {
  "ui:options": { accept: ".pdf" }
};
```

## Custom widgets and custom fields
Majorly we would require our component rather than just HTML elements. In such cases, custom widgets would come into the picture. 
- Widget: That represents HTML tags like input, select, etc.
- Field: This usually wraps one or more widgets and handles the state of the widgets.

```
Const CustomCheckbox = props => {
	const {options, value} = props;
	return (
		// Component code.
		<button>{String(value)}</button>
	)
}

CustomCheckbox.defaultProps = { options: { background: “blue” } };

Const schema = { type: “boolean”, default: true };
Const uiSchema = { “ui:widget”: “checkbox” };
Const widgets = { CheckboxWidget: CustomCheckbox }

<Form schema={schema} uiSchema={uiSchema} widgets={widgets} />
```
Likewise, each of the widgets can be mapped. Below is the default widget that can be overridden like the above code.
- AltDateTimeWidget
- AltDateWidget
- CheckboxesWidget
- CheckboxWidget
- ColorWidget
- DateTimeWidget
- DateWidget
- EmailWidget
- FileWidget
- HiddenWidget
- PasswordWidget
- RadioWidget
- RangeWidget
- SelectWidget
- TextareaWidget
- TextWidget
- UpDownWidget
- URLWidget

In the widgets, the below props are passed by default by the library. 
- Id: generated dynamically
- Schema: subschema of the field
- uiSchema : uiSchema for the field 
- Value: the value of the field
- Placeholder, Required
- Disabled, read-only, autofocus
- onChange, onKeyChange, onBlur, onFocus
- Options: along with other props, we can send options.
- Options.enumOptions
- formContext: Sending the context object.
- rawErrors: Generated errors encountered by the widgets

In Field props, the below props are passed by the library
- Schema, uiSchema, idSchema
- formData
- errorSchema
- Registry
- formContext

## Resources
- https://react-jsonschema-form.readthedocs.io/en/latest/


Data driven way for creating and managing React forms

React json schema form. v3.2.1


## Introduction to React Query and its purpose

While React is good with client-side data handling like

- storing the data in the state, context API, etc
- form handling
- state management for views, etc

React-query targets server-side data handling like

- side-effects for API calls
- throttling of API calls
- cache-ing of the data
- updating loading and loaded states along with error states
- Refetching and pre-fetching data at intervals / Polling.
- fetching data on window focus
- manage sequential calls / dependent calls.
- Network calls when the network is back / Offline support
- Garbage collection
- Window focus prefetching API
- Handling infinite scroll getting data

This is type-safe and typescript enabled.

## Installation

While `@tanstack/react-query` is the only package that is required, few other packages go very well with react-query.

- Eslint: `@tanstack/eslint-plugin-query`
- Devtools: `@tanstack/react-query-devtools`

For using CDN, we could use the following script at the end of the body.

```
<script type="module">
  import React from 'https://esm.sh/react@18.2.0'
  import ReactDOM from 'https://esm.sh/react-dom@18.2.0'
  import { QueryClient } from 'https://esm.sh/@tanstack/react-query'
</script>
```

### How to use the dev tools

```
import { ReactQueryDevtools } from '@tanstack/react-query-devtools'

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      {/* The rest of your application */}
      <ReactQueryDevtools initialIsOpen={false} />
    </QueryClientProvider>
  )
}
```

Other options for dev tools

- initialIsOpen: boolean
- buttonPosition : "top-left" | "top-right" | "bottom-left" | "bottom-right" | "relative"
- position: "top" | "bottom" | "left" | "right"
- client: QueryClient
  While for other options follow [here](https://tanstack.com/query/latest/docs/framework/react/devtools)

## Core Concepts

- Queries: useQuery or useInfiniteQuery
- Mutations
- Query Invalidations

The library is built on when API calls are made. The calls are made only when the data is stale. The user can set the time as to how long the user wants the cached data on a global level or the individual level. Below are the scenarios when the calls are made

- New instances of the query mount
- the window is refocussed
- the network is reconnected
- Query is optionally configured with a refetch interval

React Query keeps the key as a marker to cache the records.

```
useQuery({ queryKey: ['todos’, todoId], queryFn: fetchAllTodos }
```

Note: While query can be used for both GET and POST, mutations are used when there is a change in server data like add/delete actions.

React Query gives a set of statuses for UI to check on the value like

- isPending or status === “pending”’
- isError or status === “error”
- isSuccess or status === “success”

There are other variables as well to give more information

- error: While in error state, we could check the error type and more details
- data: While in success, we can access the data sent by the server
- isFetching: While the query is fetching an API.

## Making Parallel, Dependent, Paginated & Infinite Queries

### Parallel Querires

For parallel queries, the developer can write as separate statements.

```
const usersQuery = useQuery({ queryKey: ['users'], queryFn: fetchUsers })
const teamsQuery = useQuery({ queryKey: ['teams'], queryFn: fetchTeams })
const projectsQuery = useQuery({ queryKey: ['projects'], queryFn: fetchProjects })
```

While the above parallelisation is good for a known set of calls, sometimes it might be required to call on dynamic instances. For those scenarios, follow the below code.

```
const userQueries = useQueries({
  queries: users.map((user) => {
    return {
      queryKey: ['user', user.id],
      queryFn: () => fetchUserById(user.id),
    }
  }),
})
```

### Dependent Queries

If there is some dependency on an earlier call before a call is being made, then use the below code. The key is `enabled` which makes sure the call is only made when it is true.

```
const { data: user } = useQuery({
  queryKey: ['user', email],
  queryFn: getUserByEmail,
})

const userId = user?.id

const {
  status,
  fetchStatus,
  data: projects,
} = useQuery({
  queryKey: ['projects', userId],
  queryFn: getProjectsByUser,
  // The query will not execute until the userId exists
  enabled: !!userId,
})
```

### Paginated Queries

While working with useQuery for pagination, it would work fine, but there would be a jumping off the records because of fetching the data and change of status from pending to idle. To avoid jumping off the data, we could use “keepPreviousData”. This would keep the old records till the new data is replaced. For the initial page load, the data would not be there, so the loading state would show, but for later calls, there would not be a jumping of data.

```
import { keepPreviousData, useQuery } from '@tanstack/react-query'

useQuery({
  queryKey: ['projects', page],
  ueryFn: () => fetchProjects(page),
  placeholderData: keepPreviousData,
})
```

### Infinite Queries

While there has been a general pattern for adding more data to the list to show more as we scroll, react-query has it covered. We just have to change from “useQuery” to “useInfiniteQuery”. There would be few noticeable checks

- data is an object now
- data.pages is the array of data per page
- data.pageParams array containing the page params used to fetch pages.
- fetchNextPage and fetchPreviousPage functions are available
- initialPageParams option is now available
- hasNextPage: a boolean specifying if there are no further pages.
- hasPreviousPage: a boolean specifying if there are no previous pages.
- isFetchingNextPage and isFetchingPrevious page for loading, error and success states.

```
import { useInfiniteQuery } from '@tanstack/react-query'

function Projects() {
  const fetchProjects = async ({ pageParam }) => {
    const res = await fetch('/api/projects?cursor=' + pageParam)
    return res.json()
  }

  const {
    data,
    error,
    fetchNextPage,
    hasNextPage,
    isFetching,
    isFetchingNextPage,
    status,
  } = useInfiniteQuery({
    queryKey: ['projects'],
    queryFn: fetchProjects,
    initialPageParam: 0,
    getNextPageParam: (lastPage, pages) => lastPage.nextCursor,
  })

  return status === 'pending' ? (
    <p>Loading...</p>
  ) : status === 'error' ? (
    <p>Error: {error.message}</p>
  ) : (
    <>
      {data.pages.map((group, i) => (
        <React.Fragment key={i}>
          {group.data.map((project) => (
            <p key={project.id}>{project.name}</p>
          ))}
        </React.Fragment>
      ))}
      <div>
        <button
          onClick={() => fetchNextPage()}
          disabled={!hasNextPage || isFetchingNextPage}
        >
          {isFetchingNextPage
            ? 'Loading more...'
            : hasNextPage
              ? 'Load More'
              : 'Nothing more to load'}
        </button>
      </div>
      <div>{isFetching && !isFetchingNextPage ? 'Fetching...' : null}</div>
    </>
  )
}
```

## Configurations

While the configurations can be global, each query can be configured by the options provided. Below are a few options:

- staleTime : (in ms): This is a flag when the user to fetch data.
- refetchOnMount
- refetchOnWindowFocus
- refetchOnReconnect
- refetchInterval
- gcTime: garbage collection time: default -> 5s
- retry: <number | false>: number would be the number of retries, false would be no retry
- retryDelay: in ms

Inactive queries are garbage collected after 5s.

## Links & References:

- [Official Website](https://tanstack.com/query/latest)
- [Series on useQuery](https://www.youtube.com/watch?v=xoPguAXJmiE&list=PLC3y8-rFHvwjTELCrPrcZlo6blLBUspd2&index=19)
- [Crash Course](https://www.youtube.com/watch?v=r8Dg0KVnfMA)
- [React DevTools options](https://tanstack.com/query/latest/docs/framework/react/devtools)


TanStack Query (FKA React Query) is becoming popular library in handling data-fetching for web applications with ease. It makes fetching, caching, synchronizing and updating server state in your web applications a breeze.

Maximizing Efficiency: How React Query Can Revolutionize Your API Calls


## React Testing library(RTL)

React testing library is built on `DOM Testing Library` by adding APIs working for React Components.
Generally we write test on the implementational level which is very difficult to maintain in the long run. If we test a functionality in a way the user would use the application, the test would be very effective. This means we are not testing the implementation.

### Phillosophy

- Write the test user (user along with screen readers) would see the application. It does not care about what is written inside the code.
  - Do not test the implementational details. Test the behaviour.
  - This would give a maintainability of the test cases.
  - Refactor becomes easy.
- Find elements by accessibility. This is how screen readers would read the page. You are testing the accessibility as well.

### Cons

RTL believes the pros over weigh the cons and gives more confidence to moving the code to production.
It is built on top of `react-dom` and `react-dom/test-utils` and provides light utility functions to encourage better testing practice.

## Installation:

It comes with `create-react-app` but if you want to install separately to a project,

```
- npm install --save-dev @testing-library/react
- yarn add --dev @testing-library/react
```

This library has a peer dependency on `react` and `react-dom`
Optional : You can install `@testing-library/jest-dom` so you can use the custom jest matcher.

### Some Issues faced:

- Incase you have a dependency on 16.8, there would be a warning, `component not wrapped in act`, can be suppressed.
- While running coverage, Error was `Nothing was returned from render`, while test was working fine.
  - Upgraded testing-library/react 10.0.4, testing-library/user-event 10.1.0, testing-library/jest-dom 5.5.0
  - Added jest-environment-jsdom-sixteen to 1.0.3
  - https://github.com/facebook/jest/issues/9723

## How does RTL work under the hood

For testing, RTL

- Creates a virtual DOM before each test case.
- Finds elements in the virtual DOM using a global object called “screen”
- `screen.debug` would give the DOM construct in the console.
- Interacts with the virtual DOM for the test case scenarios
- It uses “src/setupTests.js” where it initialises jest-dom for test cases to use jest matchers.

**Note:**

Test only fails when the test matcher throws an error. Test would still pass if there is no test written inside a test case.

## Selecting Elements

In order to assert, we need to select elements first. There are 3 ways :

- queryBy\* : returns element or null if element not found
- getBy\* : returns element or throw error if not found
- findBy\* : used when there is asynchronous element

**Note**
To select multiple elements, use `All` in the query method like, queryAllBy*, getAllBy*, findAllBy\*

Variants of elements and selecting ways

- Text : <p>Some text</p>
- LabelText : <label>Some text</label>
- PlaceholderText : <input type="text" placeholder="some text" />
- AltText : <img alt="some text" />
- DisplayValue : <input value="some value" />
- TestId : <div data-testid="some-value"></div>

```
// Component
import React from 'react';
function App() {
  return (
    <div>
      <label for="search">Search:</label>
      <input type="text" id="search" />
    </div>
  );
}
export default App;

// Testing
import {render, screen} from '@testing-library/react';
... All the import statements

describe('App', () => {
  test("Find the search text", () => {
    render(<app />);
    expect(screen.getByText(/Search:/)).toBeInTheDocument();
    expect(screen.getByRole('textbox')).toBeInTheDocument();
  });
});
```

## Assertion

All the assertion are from jest. However, RTL extends from jest to give more meaningful assertion. Full list [here](https://github.com/testing-library/jest-dom).

## Testing User Events

RTL has `fireEvent` to trigger user interaction. FireEvent takes a node and the event. We could use it in either ways : `fireEvent(node: HTMLElement, event: Event);` or `fireEvent(EventName)(HTMLElement, EventProperties);`

```
import { screen, render, fireEvent } from '@testing-library/react';
... All the other imports goes here

describe("testing the earlier label and text", () => {
  test("expect the input to be in the document", () => {
    render(<App />);
    expect(screen.queryByLabelText(/some label/)).toBeInTheDocument();
    expect(screen.queryByPlaceholderText(/search here/)).toBeInTheDocument();
    expect(screen.getByRole(/Search Button/)).toBeDisabled();
    fireEvent.change(screen.getByRole('textbox'), {
      target: { value: "the changed text" }
    });
    expect(screen.getByRole(/Search Button/)).toBeEnabled();
  });
});
```

**Note**
Find the full set of events that can be used are [here](https://github.com/testing-library/dom-testing-library/blob/main/src/event-map.js).

### UserEvents

`User-event` is a companion library for Testing Library that provides more advanced simulation of browser interactions than the built-in `fireEvent` method.

```
// Installation
npm install --save-dev @testing-library/user-event
// or
yarn add @testing-library/user-event --dev
```

```
//Testing
import React from 'react'
import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'

test('click', () => {
  render(
    <div>
      <label htmlFor="checkbox">Check</label>
      <input id="checkbox" type="checkbox" />
    </div>
  )

  userEvent.click(screen.getByText('Check'))
  expect(screen.getByLabelText('Check')).toBeChecked()
})
```

### Creating an event

To get a reference of the event triggered, use 'createEvent'.

```
const myEvent = createEvent.click(node, { button: 2 })
fireEvent(node, myEvent)
// myEvent.timeStamp can be accessed just like any other properties from myEvent
```

To create a custom event

```
// simulate the 'input' event on a file input
fireEvent(
  input,
  createEvent('input', input, {
    target: { files: inputFiles },
    ...init,
  })
)
```

Mocking a event

```
import axios from 'axios';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
...Other imports
jest.mock('axios');
describe('App', () => {
  test('fetches stories from an API and displays them', async () => {
    const stories = [
      { objectID: '1', title: 'Hello' },
    ];
    axios.get.mockImplementationOnce(() =>
      Promise.resolve({ data: { hits: stories } })
    );
    render(<App />);
    await userEvent.click(screen.getByRole('button'));
    const items = await screen.findAllByRole('listitem');
    expect(items).toHaveLength(1);
  });
});
```

## Mocking Service Worker

- Install msw : `npm i msw` or `yarn add msw`
- Create handlers : Create a file `src/mocks/handlers.js`
- Create test servers : Create a file `src/mocks/server.js`
- Make sure test is listening to all tests
  - Reset after each test

```
// Server.js
import { setupServer } from 'msw/node’;
import { handlers } from './handlers’;

export const server = setupServer(...handlers);
```

```
// handlers.js
Import { rest } from ‘msw’;
const responseHandler = (req, res, ctx) => { … code goes here };

const handlers = [
	rest.get(‘/url-to-mock’, responseHandler),
	rest.post(‘/som-other-url’, rejectHandler)
];

export default handlers;
```

```
// SetupTests.js
import { server } from './mocks/server.js’;
// Establish API mocking before all tests.
beforeAll(() => server.listen());

// Reset any request handlers that we may add during the tests,
// so they don't affect other tests.
afterEach(() => server.resetHandlers())

// Clean up after the tests are finished.
afterAll(() => server.close())
```

```
// For multiple Ajax calls :
test(“clicking button calls multiple Ajax calls”, async () => {
	render(<App />);
	const btn = getByRole(“button”, { name: “Fetch data” });
	expect(btn).toBeEnabled();
	userEvent.click(btn);

	await waitFor(async () => {
		const dataContainer = await screen.findByRole(‘alert’);
		expect(dataContainer).toBeInTheDocument();
		expect(dataContainer).toHaveLength(2);
	});
});
```

## Context Provider Testing

Create a file called as test-utils.js

```
import React from 'react'
import { render } from '@testing-library/react'
import { ThemeProvider } from 'my-ui-lib'
import { TranslationProvider } from 'my-i18n-lib'
import defaultStrings from 'i18n/en-x-default'

const AllTheProviders = ({ children }) => {
  return (
    <ThemeProvider theme="light">
      <TranslationProvider messages={defaultStrings}>
        {children}
      </TranslationProvider>
    </ThemeProvider>
  )
}


const customRender = (ui, options) =>
  render(ui, { wrapper: AllTheProviders, ...options })

// re-export everything
export * from '@testing-library/react'

// override render method
export { customRender as render }

Inside a test
import { render } from ‘test-utlis’;
```

## Resources

- Udemy Course : https://thoughtworks.udemy.com/course/react-testing-library/learn/lecture/24450844#overview
- Jest getting started : https://jestjs.io/docs/getting-started
- Different types of roles from W3C : https://www.w3.org/TR/wai-aria/#role_definitions
- Jest DOM matchers : https://github.com/testing-library/jest-dom
- Testing user events : https://testing-library.com/docs/ecosystem-user-event/
- Api queries : https://testing-library.com/docs/queries/about/
- Cheatsheet : https://testing-library.com/docs/react-testing-library/cheatsheet/
- Order of priority to use one over the other : https://testing-library.com/docs/queries/about/#priority
- Mock Service Worker :
  - https://github.com/mswjs/msw
  - https://mswjs.io/docs/getting-started/install


Testing an application the way user would see and interact with the pages. Making the test more maintainable.

React Testing library


## Business Context

Consumers today rely on digital devices to manage banking, healthcare, shopping, and communications. Customers expect to be able to do business safely and securely online, without their PII or payment information being stolen.

Since the user would interact with the application in the client-side / frontend more, thus it is very much important to check and secure all the vulnerabilities at the first gate itself.

Below are some of the checklist to have it ticked before going to production.

**Code Readiness**

- Pipeline/Project configuration

  - Uglify and minify code for performance, removal of dangerous comments marked by developers to understand the code.
  - Whitelist trusted website and block all other websites’ content.

- HTML/JS templating

  - Avoid dangerouslySetInnerHTML in React, bypassSecurityTrust in Angular, or v-html and v-bind in Vue. Check for similar vulnerability for setting script tags for input values in your framework used.
  - Do not store keys and secrets in code. Fetch it from API (Fetching configurations run time). This helps in hiding the secrets and keys of environment.
  - Do not use encryption/decryption logic in client side. This would expose everything also the key has to be stored or used in JS which is exposed.
  - Be careful in showing and storing PII info and other secrets in browser’s context like localStorage, sessionStorage, cookie, session etc. Avoid storing or validate more often to check if it is tampered.
  - Avoid vulnerable keywords like document.write, setInnerHTML, etc

- CSS

  - Do not hide sensitive content using CSS. Remove the content from page itself.

- Forms
  - Disable browser’s auto-complete on sensitive form elements like login password, etc.
  - Add rel='noopener noreferrer' to external links
  - Do not use static ids to forms.
- Setting Headers. Set appropriate flags in cookies, headers
  - Enable https
  - Set cookie, header and resources expiry
  - Check for domains to be allowed and domains from where cookies sent from
  - Always use signed and encrypted cookies
- Prevent CSRF attack by
  - Implement same-site cookie
  - Implement CSRF token by nonce tokens.
- Prevent critical resources by path traversal. Restrict / authorise download of business critical assets.

**Network**

- Implement CSP (Content Security Policy)
  - Do not allow all domains with an \*
  - Be careful about using 'unsafe-inline', 'unsafe-eval', 'strict-dynamic', 'unsafe-hashed-attributes'
  - Use sub-resource integrity which can be easily set in CSP
- Add Security headers
  - X-Frame-Options
  - Strict transport Security
  - Access-Control-Allow-Origin
  - X-Content-type-options
- Dont use mixed content, http and https
- Add http to https redirection
- Disable CORS to support local development
- Disable cookie security flags for local development

## Some helpful tools/practices

- Setup monitoring and logging tools
- Dependency checker : npm audit, Synk, etc
- SAST and DAST for static and dynamic checker
- Secrets scanning tools like sonarqube
- Security checks should be done at intervals and not the last minute.

## To read more

- [Security Trails](https://securitytrails.com/blog/frontend-security-best-practices)
- [OWASP Cheat sheet series](https://cheatsheetseries.owasp.org/)
- [OWASP ASVS](https://owasp.org/www-pdf-archive/OWASP_Application_Security_Verification_Standard_4.0-en.pdf)
- [Front-End-Checklist](https://github.com/thedaviddias/Front-End-Checklist#security)
- [CSP Cheatsheet](https://scotthelme.co.uk/csp-cheat-sheet/)


Consumers today rely on digital devices to manage banking, healthcare, shopping, and communications. Customers expect to be able to do business safely and securely online, without their PII or payment information being stolen.

Frontend Security


## CSS in JS.

I am assigned to a (NEXTJS)project which uses a styled component for styling the components in the project. I have been liking CSS(scss) way till now and have a good grasp on it. I know how to get things done and have a solid grip on SCSS.
But then I decided to try it out and read about it. Here is my experience with styled components. Moving away from scss.

## Motivation

- Automatic Critical CSS: Only CSS which is required is loaded.
- No class name bugs: No spelling mistakes, class names overlap
- Easier Deletion of CSS: It moves along with the code. It is easy to delete when the component is not required.
- Simple dynamic styling: adapting to the style of the component via props or global theme
- Automatic vendor prefixes: Though the majority of the browsers are up to date with the styling, there could be some recent behaviour that is being used it the website for aesthetics which the programmer need not worry about.

## Background

The styled component generates a simple React component. Let us see how things work in the background. Let us split our understanding into various parts:

### Template literals/strings:

These are great with concatenations and good with reading.

```
// Template strings
const string = `I am a template literal`;
// Template expression
const expressions = 'dynamic values';
const string = `I can contain ${expressions}`;
```

### Function invoking:

The two ways of invoking a function are the traditional way and using a Tagged Template.

```
function printMessage() { return `This is a simple message`; }
// Function calling
printMessage();
// Tagged Template
printMessage``;
```

### Function invoking with params in a tagged template:

```
const printArguments = (...args) => { console.log(...args); }
const var1 = "my";
const var2 = "message"
printArguments`This is ${var1} custom ${var2}!`;
//   ["This is "," custom ","!"],
//   "my",
//   "message"
```

The tagged template would take arguments in a string and variables which get replaced and returned as a string. In some cases, the function would return another function rather than a plain string. This is achieved using currying.

```
const multiply = (multiple) => (num) => parseInt(num[0]) * parseInt(multiple[0]);
const double = multiply`2`;
const result = double`4`;
console.log(result);  // >>> 8
```

### Summing up all these to React Component:

```
const withGreeting = ([greeting]) => ({ name }) => <h1>{greeting}, {name}!</h1>;
const Greet = withGreeting`greeting`;
// Render component
<Greet name="Chris" />
// Renders in DOM
<h1>Greetings, Chris</h1>
```

Let us see a sample styled-components

```
const Greet = styled.h1`
	background: blue;
`;
<Greet>Some text</Greet>
```

On a high level, this is how styled components would work.

## Getting started

### Installation

```
npm install styled-components
npm install babel-plugin-styled-components // This is used for using it with babel.
```

```
.babelrc {
 "presets": ["next/babel"],
 "plugins": [["styled-components", { "ssr": true }]]
}
```

It has a peer dependency on react 16.3. So make sure you are using the correct version of React and React-dom. Since I am using NextJs I have the preset as "next/babel". You could use relevant presets for your project.

### A simple styled component

```
const Title = styled.h1`
font-size: 1.2rem;
color: #435;
`;
<Title>Here goes the title</Title>
```

### Variation of the component using props

Styled components are simple React components and can accept props for variations.

```
const Button = styled.button`
	background: ${ props => props.primary ? “red” : “white” };
	color: ${ props => props.primary ? “white” : “red” };
`;
```

### Additional props and inheriting

```
const Input = styled.input.attrs(props => ({
  type: "text",
  size: props.size || "1em",
}))`
  margin: ${props => props.size};
  padding: ${props => props.size};
`;

const Password = styled(Input).attrs(props => {type: 'password'})`
  border: 2px solid aqua;
`
```

### Extending styled-components

```
const TomatoButton = styled(Button)`
  background: tomato;
  color: #369;
`;
```

### Replacing a tag

```
<Button as "a" href="http://www.google.co.in">Link to Google</Button>
```

Sometimes we need a different tag and should have the same styles. The above example cites how to use styled-components for the same.

### Creating a global style

While in a project, you would require some global styles used across pages. In that case, you need to create global styles. You could create like the below example.

```
import { createGlobalStyle } from 'styled-components';
export const GlobalStyle = createGlobalStyle`
:root {... css variables}
html, body { ...style goes here }
`
On the entry-level component, we import GlobalStyle.
<GlobalStyle />
```

### Pseudo selectors and "&"

Much like scss, it has nested rules. We use '&' to refer to the parent in the nesting rules.

```
const Para = styled.p`
  font-size: 16px;
  &::selection { background: #369; color: #fff; }
  .currency { font-family: unicode; }
  .something-else & { padding: 10px; }
`;
```

### Animations

```
const rotate = keyframes`
  from { transform: rotate(0deg); }
  to { transform: rotat(360deg); }
`;
const Rotate = styled.div`
  animation: ${rotate} 2s linear infinite;
`;
```

### Keyframes

Keyframes are inserted lazily into DOM and hence required "CSS helper" to have styles attached.

```
import styled, { css, keyframes } from 'styled-components'
const animation = keyframes`
  0% {
    opacity: 0;
  }
  100 {
    opacity: 1;
  }
`
const animationRule = css`
  ${animation} 1s infinite alternate;
`
const Component = styled.div`
  animation: ${animationRule};
`
```

### Media queries and nesting

```
const ColorChanger = styled.section`
  background: papayawhip;
  color: palevioletred;

  @media(min-width: 768px) {
    background: mediumseagreen;
    color: papayawhip;
  }

  div {
    padding: 10px;
  }
`;
```

### Overriding styles

```
const MyStyledComponent = styled(AlreadyStyledComponent)`
  &&& {
    color: palevioletred;
    font-weight: bold;
  }
`
// Output would be
.MyStyledComponent-asdf123.MyStyledComponent-asdf123.MyStyledComponent-asdf123 {
  color: palevioletred;
  font-weight: bold;
}
```

This would just increase the specificity of the style to get implemented.

### For overriding inline styles

```
const MyStyledComponent = styled(InlineStyledComponent)`
  &[style] {
    font-size: 12px !important;
    color: blue !important;
  }
`
```

### Creating a theme

Using the Context API from React, styled-component provides customizing the theme with the "ThemeProvider" component.

```
const Button = styled.button`
  font-size: 1em;
  margin: 1em;
  padding: 0.25em 1em;
  border-radius: 3px;
  color: ${props => props.theme.main};
  border: 2px solid ${props => props.theme.main};
`;

Button.defaultProps = {
  theme: {
    main: "palevioletred"
  }
}

const theme = {
  main: "mediumseagreen"
};

render(
  <ThemeProvider theme={theme}>
    <Button>Themed</Button>
  </ThemeProvider>
);
```

## Resources

- https://styled-components.com
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
- https://rangle.io/blog/styled-components-styled-systems-and-how-they-work/


CSS in JS. Use the best bits of ES6 and CSS to style your apps without stress. Get the vendor prefixes without worring about the class name conflict and give a short and meaningful name to classes to every component.

Styled Component


## What do we mean by making the web for all?

While building the software, we forget people with a variety of disabilities like :

- For everyone including developers who like the keyboard more than the mouse
- With disability: Motor disability, etc
- Vision Impairment: Color, Visual
- Deaf/hearing impairment: Rely on captions.
- Cognitive disability: Learning disability, grasping/focussing on a lot of information, distractibility,
- People using assistive technology: Screen readers
- Changing ability: Ageing

The web is changing and so are the rules. There are various standards for accessibility like A, AA and AAA. Accessibility (a11y) has become a default for making a website. Companies are sued for not complying with the rules.

So the question is what we need to do?

## What do I do for making my website accessible?

Accessibility is based on 4 major categories or guiding principles. These are:

- **Perceivable:** Available to the senses (vision and hearing primarily) through the browser or through assistive technologies (e.g. screen readers, screen enlargers, etc.)

- **Operable:** Users can interact with all controls and interactive elements using the mouse, keyboard, or any other assistive device.

- **Understandable:** Content is clear and limits confusion and ambiguity.

- **Robust:** A wide range of technologies (including old and new user agents and assistive technologies) can access the content.

## Designs

Accessibility starts with the design system. May it be creating a ramp for people on a wheelchair near a staircase, or an extended rod to hold while walking for age-ing people or people who need support while walking. The same goes for the websites as well. We have to make our website accessible to all kind of age-group, people who uses a variety of assistive technology, etc. and that starts with designing.

## Layout

Below are a few guidelines which we could follow while laying out our web pages.

- More contrast to background and foreground colours.
- Give more contrast between colours used side-by-side.
- Avoid a busy layout of the webpage. Make a simple layout and give more spacing to logically segregate areas.
- Make sure your layout is colour blind accessible.
  - Red / Green Deficiency
  - Blue / Yellow Deficiency
- Responsive Design is a must for all the designs so that the user is able to access your webpage on all the devices.
- Use semantic markup. If CSS is removed, the layout should give a logical flow of data. This would help screen readers and bots to read the page.
- Typography
  - Proper scaling of fonts
  - Body text should be readable
  - Avoid "justify text-align" for alignment. This becomes very difficult to read with a variety of spacing between the text.
  - Use rems appropriately.

## Forms

Forms are an important part to collect data from your users. This has to be more accessible and seamless while we present. Below are the few pointers that could be used followed while implementing.

- Labels should be clear
- Help text should be upfront so that the user should not guess the field validation.
- The placeholder should not disappear if no label present.
- Make sure the user is able to submit the form and recover from errors.

## Touch targets

The major interaction of any user journey is through clicks/touch targets. So if the touch targets are not very effective, the user might not want to continue with the page. Let us see what we can do to make it a better user experience.

- Touch targets should be bigger enough
- Enough space between the touch targets so that the user finds it easy to click the desired one.
- Give visual indication and differentiation for various states

## Focus, hover and active states

Majorly we disable all the states for better UX. This hampers the accessibility of the webpage. Let us see some best practices from the industry.

- Give proper CSS class and styles
- Do not remove focus and active styles. It gives a visual mark where the user is currently present.
- Give proper contrast in style wrt the background
- Allow disable animation
- Make sense of the animation wrt the context.

## Design for crisis

Sometimes things do not go as per plan and there are errors on the page. We should be able to revive from it. Design for error scenarios as well.

- Give info to the user on what happened if possible.
- Give options for the users to revive from the crisis like go home, go back the form, etc.

## Assets

We have various visual representations on the page. We also need to make it accessible by the following.

- Images
  - Give alt text
  - Use JPEGs over PNG. The compression quality for jpg is good.
  - Use image optimisation tools
  - Try using SVGs.
  - For long description, use longdes="longtext.txt"
- Audio / Video
  - Use captions and transcripts for people/bots who find it difficult to get the video/audio
  - Have controls to video/audio

## Resources

https://webaim.org/

https://www.a11yproject.com/


Creating digital platfor for all users. While developing a digital platform, we forget our users with various kind of disablity. And only look at the aesthetics given by the visual designer team. It is equally important to increase our reach to all.