TILs - Fueling Curiosity, One Insight at a Time

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 :

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



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"

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

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.

Managing multiple variants of a component, such as different styles of buttons, can often be a challenging task, especially as the number of variants grows. Traditionally, developers have resorted to using packages like classnames to dynamically apply classes based on different conditions. However, a more streamlined and organized approach is provided by Class Variance Authority (CVA). CVA offers an elegant solution to handling multiple component variants, promoting maintainability and scalability.

One typical example is the "Button" component, which can possess various visual treatments like primary, secondary, with icons, and diverse icon placements. Instead of relying on cumbersome conditional statements and the classnames package, Class Variance Authority presents an efficient methodology through its documentation, available at https://cva.style/docs.

In order to disable pager in postgresql, just use this command \pset pager off. This command is useful for seeing data from tables with huge jsonb data

JSON serialization in API responses omits fields with undefined value to follow the JSON specification. According to the JSON standard, properties with undefined values are not allowed in JSON objects, these are the allowed JSON values: object, array, number, string, true, false, or null.

We need to be mindful while handling the missing data. On the backend, use null or defaults for missing data. On the frontend, ensure data is present before accessing it.