Glossary N–R

N

Node.js

Plain English: A runtime environment that lets JavaScript run on a server (or your laptop) rather than just inside a browser. It is what makes JavaScript usable for building backend tools and running command-line utilities.

Excel equivalent: The difference between running Excel formulas only inside Excel versus running Excel macros (VBA) as standalone programs on your computer — scripts that execute independently of any open spreadsheet. Node.js gives JavaScript that same independence.

In practice: When you run npm run dev, Node.js is the engine executing that command. When you run any CLI tool — git, npx supabase, eslint — Node.js is powering the tool behind the scenes. You do not write Node.js code directly in this program (we use Supabase Edge Functions for server-side logic), but you need it installed for all the tooling to work.

Don't confuse with: npm. Node.js is the runtime (the engine). npm is a package manager that comes bundled with Node.js and handles downloading libraries.

npm

Plain English: Node Package Manager. A tool that downloads, installs, and manages the libraries (packages) your project depends on. One command installs everything your project needs.

Excel equivalent: A centralized add-in store where you can install any add-in by name and it automatically downloads, installs, and configures itself. npm install react-hook-form is equivalent to "search for Power Query in the add-in store, install it, activate it."

In practice: When you first clone a project or start a new one, you run npm install. This reads the package.json file (the list of all dependencies) and downloads them into the node_modules/ folder. You will also run npm run dev to start the development server and npm run build to prepare for production.

Don't confuse with: Node.js. Node.js is the runtime; npm is the package manager that comes with it. Related but different tools. You install Node.js; npm comes along for free.

O

OAuth

Plain English: A standard protocol that allows users to log in using their existing account on another service (Google, GitHub, LinkedIn) without sharing their password with your app.

Excel equivalent: Using your CA Institute credentials to log into a third-party continuing education platform — instead of creating a new account, the platform trusts ICAI to verify who you are. You never give the third-party your ICAI password.

In practice: "Continue with Google" buttons use OAuth. The user clicks it, Google asks "do you want to allow this app to know your name and email?", the user agrees, and your app receives a verified identity without ever seeing the user's Google password. Supabase supports OAuth out of the box for Google, GitHub, and other providers.

Don't confuse with: Authentication. OAuth is one method of authentication. You can authenticate with a username/password (not OAuth) or with Google (OAuth). Authentication is the concept; OAuth is one implementation.

Object

Plain English: A collection of related data stored together under one name, organized as key-value pairs. The fundamental data structure in JavaScript.

Excel equivalent: One row of data in a structured table. A row in a Clients sheet might have: Client ID, Name, Email, Phone, GSTIN, City. All of these fields together describe one client — that collection is an object.

In practice: In JavaScript, an object holds related fields accessible by name. client.name, client.city, client.gstin — each returns the value for that field. Almost everything in JavaScript is an object. Database rows come back as objects. API responses are objects. UI components receive objects as props.

Don't confuse with: Array. An object is one item with named fields. An array is a list of items. An array of objects is a list of rows — exactly like a database table.

P

Package

Plain English: A reusable piece of code, bundled and published to npm's registry, that anyone can install with npm install. Synonymous with "library" in most daily usage.

Excel equivalent: A downloadable Excel add-in template from Microsoft's Office Store. Someone built it, packaged it, published it, and you install it in one click.

In practice: When you add a new capability to your project — say, PDF generation — you find a package that does that, install it, import it in your code, and use it. The package.json file tracks every package your project depends on.

Don't confuse with: Library vs package. These words are used interchangeably. Technically, a package is a published, versioned unit. A library is the code you import. In practice, when someone says "install the package" they mean "run npm install"; when they say "use the library" they mean "import and use the code."

PostgreSQL

Plain English: A powerful, open-source relational database system. The database engine that Supabase uses under the hood.

Excel equivalent: The engine that runs your spreadsheet calculations — think of PostgreSQL as a hyper-powered version of the calculation engine in Excel, but one designed to handle millions of rows, complex relationships, concurrent users, and advanced security rules.

In practice: You will write SQL (Structured Query Language) to interact with PostgreSQL. Simple queries look like Excel filter operations: SELECT * FROM jobs WHERE salary > 30000 is the SQL equivalent of filtering column C to show only values above 30,000. Complex queries join multiple tables, aggregate data, and apply conditions — the SQL equivalent of nested VLOOKUPs, SUMIFS, and pivot tables combined.

Don't confuse with: Supabase. Supabase is the platform built on top of PostgreSQL. PostgreSQL is the database engine; Supabase adds authentication, real-time updates, storage, and edge functions around it. You interact through Supabase's tools but the underlying data lives in PostgreSQL.

PR (Pull Request)

Plain English: A formal request to merge your branch's changes into the main branch. It is a structured process for code review — you share your changes, others review them, discuss improvements, and then the changes are merged.

Excel equivalent: Sending a revised version of an audit workbook to the partner for review — with tracked changes enabled — before it goes to the client. The partner can see exactly what changed, leave comments, request adjustments, and only approve once satisfied.

In practice: The standard workflow: you build a feature on your branch, push it to GitHub, open a Pull Request, Subhash reviews the code on GitHub (leaves comments, approves or requests changes), once approved the branch is merged into main, and Vercel deploys automatically. Every feature in EduTrack goes through this process. PRs are how professional teams maintain quality control.

Don't confuse with: Commit. A commit is saving a snapshot of your work locally. A Pull Request is the formal process of proposing that your commits be merged into the main branch. Multiple commits can be part of one PR.

Props

Plain English: Short for "properties". The inputs you pass into a React component to customize how it displays or behaves. Like function arguments, but for UI components.

Excel equivalent: The inputs to an Excel function. =VLOOKUP(lookup_value, table_array, col_index_num, range_lookup) — those four arguments are the function's "props". Pass different values, get different results from the same function.

In practice: A Button component accepts props for its label, color, and click behavior. The component reads these props and renders accordingly. Change the color prop from "blue" to "red" and the button turns red — without changing the Button component itself.

Don't confuse with: State. Props are inputs passed from parent to child — they are controlled by whoever uses the component. State is the component's own internal memory — controlled by the component itself. A button's label is a prop (the parent decides it). Whether the button is currently loading is state (the button tracks this itself during an async operation).

R

React

Plain English: A JavaScript library for building user interfaces. It lets you build complex, interactive UIs by composing small, reusable components. Created by Facebook (Meta), now the most widely used UI library in the world.

Excel equivalent: Excel is to spreadsheets what React is to web UIs. Just as Excel gives you the building blocks to create complex spreadsheet applications (formulas, charts, pivot tables), React gives you the building blocks to create complex web applications (components, state, routing).

In practice: Every screen in every web project in this program is built with React. You write components in JSX, manage data with state and React Query, and React handles updating the screen efficiently when data changes. When the job count goes from 45 to 46, React knows to update exactly that one number on screen — not reload the entire page.

Don't confuse with: React Native. React is for web applications (browsers). React Native is the mobile version, using the same mental model but producing native iOS and Android apps instead of webpages.

Repository (Repo)

Plain English: The folder that contains your entire project, tracked by Git. Everything — code, assets, configuration files, documentation — lives here. The repository is the single source of truth for your project.

Excel equivalent: The SharePoint document library for a client engagement. Every relevant file — workpapers, financial models, correspondence — lives here, organized, versioned, and accessible to the team.

In practice: Each project has one repository: udyogaseva, edutrack, your-personal-site. The repository lives on your computer (local) and is backed up on GitHub (remote). When you run git clone, you download a repository. When you run git push, you upload your latest commits to the remote repository.

Don't confuse with: A branch. A repository is the entire project. A branch is one parallel version of work within that repository. One repository can have many branches.

RLS (Row Level Security)

Plain English: A database feature that controls, at the database level itself, which users can read or modify which rows. The security rules are enforced by the database — not by the app code that calls it.

Excel equivalent: Imagine an Excel file where each row of client data is only visible to the CA assigned to that client — enforced by the file itself, not by anyone manually filtering. Even if someone got direct access to the underlying database, they would only see their own rows. The protection is baked into the storage layer, not the display layer.

In practice: This is one of the most important concepts in the program. In Udyogaseva, a candidate's RLS policy says: "A user can only read their own profile row." Even if there is a bug in the React code that accidentally tries to fetch all profiles, the database refuses — it returns only the logged-in user's row. Security enforced at the database level is far more robust than security enforced only in the application code.

Don't confuse with: Application-level authorization. RLS is enforced by PostgreSQL itself. Application-level checks (hiding a button, redirect if not admin) are UI conveniences — they make the UI logical, but they are not the security layer. RLS is the real security layer.

Route

Plain English: A URL path that corresponds to a specific page or view in your application. Routing is the system that maps URLs to the correct component to display.

Excel equivalent: Sheet tabs in a workbook. Each tab name is like a URL path — navigate to "Dashboard", "Clients", or "Reports" by clicking the tab. In a web app, instead of clicking a tab, you navigate to /dashboard, /clients, or /reports.

In practice: In the EduTrack admin panel, /admin/dashboard shows branch KPI cards, /admin/students shows the student management table, and /admin/fee-records/123 shows the details of a fee record. React Router maps each URL pattern to the correct component. Clicking a link updates the URL and swaps the visible component — no page reload.

Runtime

Plain English: The moment code is actually executing. "Runtime errors" are errors that only appear when the code runs — as opposed to errors TypeScript catches before you even run the code.

Excel equivalent: The difference between a formula syntax error (Excel flags it immediately when you type it wrong) and a #VALUE! error (the formula is syntactically correct but breaks when the actual data causes a problem). Syntax errors are caught at "parse time"; #VALUE! errors happen at "runtime" when the formula executes on real data.

In practice: TypeScript catches many errors at compile time — before the code runs. But some errors only appear at runtime: Cannot read property 'name' of undefined means something that should have been an object was undefined when the code tried to use it. Reading error messages carefully — and understanding whether an error is a compile-time or runtime error — is a core debugging skill.

Don't confuse with: Build time. Build time is when Vite compiles your code. Runtime is when the compiled code executes in the browser. TypeScript type errors are caught at build time; data-dependent errors are typically runtime errors.

Runtime Error

Plain English: An error that occurs while the application is running, usually because the code received unexpected data — something was null when the code assumed it existed, or a number came back as a string.

Excel equivalent: #VALUE!, #REF!, #DIV/0! errors — the formula is written correctly, but when it runs on actual data, something unexpected happens. A VLOOKUP might return #N/A because the lookup value is not found. Your code is correct, but reality did not match your assumption.

In practice: The most common runtime error you will see: TypeError: Cannot read properties of undefined (reading 'name'). This means you tried to access .name on something that turned out to be undefined. The fix: add a check before accessing properties. TypeScript and careful coding dramatically reduce these, but they are never fully eliminated.