while connecting rails local server with the client , if you get this error as mentioned below

	Is the server running on host "10.220.0.15" and accepting
	TCP/IP connections on port 5432? ```
this means your postgres server is not connected to the host at address `10.220.0.15` . In order to see if it is connected or not we need to check the `pg_hba.conf` file.
So that file must be present inside your `postgresql` directory . In order to get the path we can do `ps aux | grep postgres`
it will look like this
```...
user 46455   0.0  0.0 409138608   1248   ??  Ss   13Sep23   0:00.82 postgres: checkpointer
user 46372   0.0  0.0 408998640   2192   ??  S    13Sep23   0:16.79 /opt/homebrew/opt/postgresql@13/bin/postgres -D /opt/homebrew/var/postgresql@13```
So from here we need the path that is present after the `-D` flag. So in my case it my path is `/opt/homebrew/var/postgresql@13`
Now we can cd into the path. Once we do that we need to do `ls` and we can find the file called `pg_hba.conf` . Then we need to run `nano pg_hba.conf`
it will open the file and if you see that there is no host present , we need to write the following lines and press `Ctrl + O` then click `Enter` and `Ctrl +X`
```host  YOUR_DB_NAME  YOUR_USER_NAME  10.220.0.15/32  md5```
then start your postgres server for the desired database and you will successfully connect local rails server with your client.

HTTP/1 (1996) vs HTTP/2 (2015)

1. HTTP/1 req/res are sent sequentially, one after another. This means that if you have several resources (e.g., photos, stylesheets, scripts) to load for a single web page, each resource requires a separate connection, which can lead to latency and slower page loading times. Where as HTTP/2 introduces request multiplexing, which allows several requests and responses to be delivered and received in simultaneously over a single connection and thus minimising the latency and speeds up the loading of multi-resource web pages.
2. HTTP/1 headers are uncompressed. This can result in significant latency in the form of redundant header data being delivered with each request and response. HTTP/2, on the other hand, employs header compression (HPACK) to minimise the size of headers, hence reducing the amount of data delivered and enhancing efficiency.
3. HTTP/1 does not have built-in capability for prioritising requests. All requests are treated identically, which might lead to poor performance for essential resources. Whereas HTTP/2 supports stream prioritisation. This means that more critical resources can be prioritised, resulting in faster loading and a better user experience.
4. HTTP/1 requires the server to wait until the client requests additional resources before sending them. This can result in inefficiencies because the server may be aware of which resources will be required but must wait for the client to request them. HTTP/2, on the other hand, introduces server push, which allows the server to provide resources to the client that it expects the client will need. This minimises round-trip times and speeds up page loading.
5. I checked couple of websites, some use HTTP/1.1 and most of them use HTTP/2. Also HTTP/3 has been introduced in 2022

When your Gemfile.lock says BUNDLED WITH 2.2.4 , but while doing bundle -v or starting your rails server or rails console you get an error saying "You must use Bundler 2 or greater with this lockfile." . We can resolve that by running gem update --system .

There are a couple of performance metrics used to measure the loading and rendering speed of web pages.

1: First paint: It refers to the point in time when the browser starts rendering first pixels on screen. It does not needs to be recognisable. First Paint can include background colors or simple styling changes and doesn't guarantee that any content or text is visible yet.

2: First Contentful Paint (FCP): First Contentful Paint occurs when the browser renders the first piece of content from the DOM (Document Object Model). It can be text, an image, etc usually referring to something meaningful on the screen.

3. First Meaningful Paint (FMP): It refers to the point where a user can identify and understand the content that is loading. Usually includes layout changes the the font are loaded as well. FMP is depreciated.

4. Largest Contentful Paint (LCP): It measures the time it takes for the largest content element (such as an image, text block, or video) within the viewport to become fully visible and rendered on the user's screen. A webpage should have a LCP of 2.5 seconds or less.

5. Speed Index: It simply refers to how quickly the visible content of a web page is painted or rendered during the loading process. It depends on size of the viewport (mobile/desktop). Lower the score, the better it is.

Critical Rendering Path: The critical rendering path refers to the sequence of steps that a browser takes between getting the resources like HTML, CSS and JS and displaying a web page on a user's screen(turn them to pixels). It's crucial for web performance optimisation because it directly impacts how quickly a web page loads and becomes interactive.

The key steps involved are:

1. HTML parsing: The browser constructs the Document Object Model (DOM) tree by converting the HTML into a structured representation of the web page's content.
2. CSS parsing: The browser also parses the stylesheets and create CSS Object Model (CSSOM). The DOM and CSSOM is combined to create render tree.
3. Layout: Based on the render tree, the browser calculates the layout of each element, determining the size and position of each element, also called as reflow.
4. Paint: Finally, the browser paints pixels on the screen as per the calculated layout and it involves converting the elements into actual pixels on the screen.

Headless UI Tab

Headless ui is providing us the Tab component were we have

1. Tab.Group is the parent its wraps all this present inside it.
2. Tab.list in tab list we have defined our tab and we have selected as active tab.
3. Tab.Panels so tabs panels is the parent of all the Tab.
4. Tab.Panel so tab panel is defined under the Tab.Panels Note: if we have 3 tabs in Tab.list then we need to paced all 3 Tab.Panel in the same like we define tabs in Tab.List

example :

    <Tab.List>
      <Tab
        className={({ selected })} => // apply active class
        key="must_pass_unique_key_1"
      >
        Tab Name 1
      </Tab>
    </Tab.List>

</Tab.Group> ```

This website https://www.colorhexa.com/ is pretty good. Given a color, say #E4F6FC, it can explain the color, and also suggest a closest websafe color

Let's say we have an api function

  const response = await axios.get(
    /api/v1/example.json?${stringify(params)}
  );
  return response.data;
};```
the `param` is an object mentioned below , and we are stringifying it before sending the request to backend.
*Note: we are using `stringify` from `qs` npm package.*
const params = {
  key1: "value1",
  key2: "value2",
  key3: ["value3", "value4"],
}
the stringified output will be - > `key1=value1&key2=value2&key_3%5B0%5D=value3&key_3%5B1%5D=value4` i.e `key1=value1&key2=value2&key_3[0]=value3&key_3[1]=value4`
but backend is expecting to receive it without the index values i.e  `key1=value1&key2=value2&key_3[]=value3&key_3[]=value4`
So in order to send the parameters like that , we can just pass a stringify option called `arrayFormat: "brackets"`
```eg: export const getTheResults = async (params) => {
  const response = await axios.get(
    /api/v1/example.json?${stringify(params, {arrayFormat: "brackets"})}
  );
  return response.data;
};```

When using Rails strong parameters feature to permit certain parameters in controller and if any specific param has array values, we need to permit it as an array explicitly

Request: /api/v1/calendar.json?date_from=&date_to=&hotel_id[]=1&hotel_id[]=2

def permit_params
  params.permit(:date_from, :date_to, hotel_id: []) # hotel_id: [] is important
end```

When working with components that have predefined classnames but require occasional overrides based on specific use cases, it's common to encounter scenarios where developers resort to using the !important CSS rule to forcefully apply style changes. However, this approach is considered an anti-pattern as it can lead to specificity conflicts and maintenance issues down the line. A more effective solution to this problem is provided by the Tailwind Merge package, available at https://github.com/dcastil/tailwind-merge.