Computer Science

 Let’s make it super clear with a real example. You have this: type ShippingFormInputs = { email: string ; age: number ; }; and this Zod schema: const shippingFormSchema = z . object({ email: z . string() . email(), age: z . number() . min( 18 ), }); and this form: const { register, handleSubmit, formState: { errors } } = useForm < ShippingFormInputs >({ resolver: zodResolver ( shippingFormSchema ) }); 🧠 What happens step by step 1. TypeScript ( <ShippingFormInputs> ) — BEFORE running code This only works while coding. Example mistake: register ( "emial" ); // ❌ typo 👉 TypeScript will immediately show error: "Property 'emial' does not exist" ✔ This is ONLY for developer safety. 2. Zod ( shippingFormSchema ) — WHEN user submits form Now user runs the app and enters: email: "abc" age: 10 Then user clicks submit. 👉 Now Zod runs: z . string() . email() ❌ invalid z . number() . min( 18 ) ❌ in...

 Mutable vs Immutable update

 Without z.infer , you must manually create the TypeScript type . Without z.infer import { z } from "zod" ; const UserSchema = z . object({ name: z . string(), age: z . number(), }); type User = { name: string ; age: number ; }; Notice that you're writing the same structure twice: Zod schema (for validation) TypeScript type (for type checking) With z.infer import { z } from "zod" ; const UserSchema = z . object({ name: z . string(), age: z . number(), }); type User = z . infer < typeof UserSchema >; Now you only write the structure once (in the schema), and TypeScript generates the type for you. The problem without z.infer Suppose you add an email field: const UserSchema = z . object({ name: z . string(), age: z . number(), email: z . string(), }); You must also remember to update: type User = { name: string ; age: number ; email: string ; }; If you forget, your schema and type become inco...

 Started to learn zustand got problem in create function of zustand. Problem was weaker concept of callback and nested function . i think i am confident in these topics now.

  The Golden Rule 🏠 Positioning ( top , left , etc.) 👉 Moves relative to the PARENT 🚶 Translate ( translate-x , translate-y ) 👉 Moves relative to ITSELF That’s it. If you remember only this, you’ll never confuse them again. 🎯 Imagine This Real-Life Story Think of a room (parent) and a table (element) . 1️⃣ left-1/2 → Parent Based You tell someone: “Put the table so its left edge is at 50% of the room.” The room decides the position. Room Width = 1000 px 50% = 500 px Table 's left edge is placed at 500px So positioning = 📏 Room measurement 2️⃣ translate-x-1/2 → Self Based Now you say: “Move the table forward by half of its own width.” The table measures itself. Table Width = 200px 50 % = 100px It moves 100px So translate = 📦 Self measurement 🔥 Ultimate Memory Formula Positioning → Parent controls me Translate → I control myself 💡 Why Centering Needs Both When you do: left - 1 / 2 You move the left edge to center. But the e...

  in case of useref no need to deal with vdom directly real dom of browser is updated Venice That's a fantastic observation, and you're touching on the core power of  useRef . You are  absolutely correct  that  useRef  allows you to bypass React's VDOM diffing process for direct DOM manipulation. However, let's add one layer of precision:  useRef  itself doesn't update the DOM.  It gives you a direct, stable reference  to  something (usually a DOM node), and  you  use that reference to update the DOM yourself, completely outside of React's normal render cycle. Let's contrast the two flows. The  useState  Flow (The "Official" React Way) This is the "ask for permission" model. Trigger:  You call  setCount() . Render:  React schedules a re-render. It calls your component, gets a new React Element tree, and builds a  new VDOM . Reconciliation (Diffing):  React compares the new VDOM to the old...