Forem: Dhokia Rinidh

Summary of insights into traditional CSS Grid & Flexbox

Dhokia Rinidh — Sun, 08 Mar 2026 18:14:15 +0000

Hello folks. Many CSS layout properties are interdependent and behave differently depending on how they are combined. A practical way to remember them is to mentally group properties based on the direction they control and whether they apply to the container or the items.

Inline Direction (left → right in most writing modes)

Properties beginning with justify- generally control alignment along the inline axis.

justify-content

Used on the container to align tracks (in grid) or flex items (in flexbox) along the inline axis when extra space is available.
justify-items

Used on the grid container to define the default alignment of grid items inside their grid cells along the inline axis.
justify-self

Used on a grid item to override justify-items for that specific item.

Block Direction (top → bottom in most writing modes)

Properties beginning with align- generally control alignment along the block axis.

align-content

Used on the container to align grid tracks or flex lines along the block axis when there is extra space.
align-items

Used on the container to set the default alignment of items along the cross axis.
- In grid, the cross axis equals the block axis.
- In flexbox, the cross axis depends on flex-direction.
align-self

Used on an individual item to override the align-items value for that item.

Restrictions / Differences

justify-items does not work in flexbox. It only applies to grid containers.
align-content works in both grid and flexbox, but in flexbox it only has an effect when there are multiple flex lines (e.g., when flex-wrap: wrap).
With grid-auto-flow: row
- Columns are determined by grid-template-columns.
- If there are more items than available cells, new rows are automatically created.
With grid-auto-flow: column
- Rows are determined by grid-template-rows.
- Extra items create new columns instead.
grid-template-columns / grid-template-rows

Define the explicit grid (the tracks you explicitly declare).
grid-auto-columns / grid-auto-rows

Define the size of implicitly created tracks when extra items require new rows or columns.

Dynamic Layout Patterns

These are common responsive grid patterns.

grid-template-columns: repeat(auto-fill, 200px)

Creates columns of fixed width (200px).
The browser fits as many columns as possible in the container.
Extra space may remain at the end of the row.

grid-template-columns: repeat(auto-fill, minmax(200px, 1fr))

Each column is at least 200px but can grow.
Remaining space is distributed using 1fr.
When there is enough space for another 200px column, the browser adds a new column automatically.

Other Useful Notes

grid-template-areas: '. . .' '. . .'

Each string represents a row, and each value represents a column cell.

Example:

grid-template-areas:
'. . .'
'. . .';

This creates a 3-column × 2-row grid, but unlike grid-template-columns / grid-template-rows, it is mainly used to name layout areas, not just define track counts.

Track Sizing Keywords

When defining columns or rows:

min-content

Shrinks the track to the smallest size possible without overflowing. Text wraps as needed, typically down to the longest unbreakable word.
max-content

Expands the track so all content fits on one line (no wrapping). It does not grow further even if the container expands.
fit-content(200px)

Allows the track to grow to fit its content but never exceed 200px.
auto

Sizes the track based on content and available space. It behaves somewhat like minmax(min-content, max-content) but can also stretch when free space exists.

Conclusion

These random cheat-sheet style bullets can be handy for quick recall while coding, instead of revisiting a long article and forcing your brain through lots of context switching.

As usual, feel free to add more insights, point out mistakes, or share your own mental models for remembering CSS layout rules.

Test Isolation vs. Mocking Mechanics in Express

Dhokia Rinidh — Fri, 30 Jan 2026 18:25:01 +0000

Hello everyone,

It’s been a while since I last shared something—back when I was deep into React Hook Form. After wrapping up my frontend, I shifted focus to gluing all pieces together and building full MERN stack applications (more on that another time...).

While writing unit tests for the backend of one of these apps, I ran into a subtle but important realization: mocking dependencies and clearing mock state alone is not always enough to guarantee proper test isolation—especially when testing Express routing logic.

The scenario

Consider the following Express router:

// product.route.ts
import express from "express";
import {
  createProduct,
  deleteProduct,
  getAllProducts,
  updateProduct,
} from "../controllers/product.controller.js";

const router = express.Router();

/**
 * Endpoint: /api/products
 */
router.get("/", getAllProducts);
router.post("/", createProduct);
router.put("/:id", updateProduct);
router.delete("/:id", deleteProduct);

export default router;

Suppose our goal is simple: verify that each HTTP method is correctly wired to its corresponding controller. We are not interested in the controller logic itself, so mocking the controllers is a perfectly reasonable approach.

Since my project used Typescript and ESM, I preferred Vitest for testing. We can mock the controllers like this:

vi.mock("../controllers/product.controller.js", () => ({
  getAllProducts: vi.fn((req, res) =>
    res.status(200).json({ message: "getAllProducts called" }),
  ),
  createProduct: vi.fn((req, res) =>
    res.status(201).json({ message: "createProduct called" }),
  ),
  updateProduct: vi.fn((req, res) =>
    res.status(200).json({ message: "updateProduct called" }),
  ),
  deleteProduct: vi.fn((req, res) =>
    res.status(200).json({ message: "deleteProduct called" }),
  ),
}));

And before each test, we typically clear mocks:

vi.clearAllMocks();

This does reset:

call counts (.mock.calls)
recorded arguments
mock results (.mock.results)

However, this is where a common misconception appears.

What clearing mocks does not reset

Clearing mocks does not reset the runtime state of your application. Particularly, it doesn't:

Recreate the Express app or router instance
Reset Express’ internal routing stack
Undo mutations to req, res, or app objects made by previous tests
Reset middleware side effects
Reload cached modules from Node’s module system

Note that Express routers are stateful objects. Once a router is created and attached to an app, its middleware stack and handlers persist for the lifetime of that app instance.

Why this matters in tests

If you reuse the same Express app across tests, subtle state can leak:

A previous test may mutate req.headers, req.body, or res.locals
Middleware may attach data to req that subsequent tests unexpectedly inherit and misuse
Order-dependent behavior can emerge when tests rely on shared app state

This can lead to tests that:

Pass or fail depending on execution order
Fail intermittently
Give false confidence about route behavior

Mock isolation alone cannot protect you from this class of problems.

The correct approach: reset runtime state

For modules with stateful dependencies (such as Express apps) the solution is twofold:

Reset mock state (call counts, return values, spies)
Recreate the runtime environment (new app instance per test)

import express, { type Express } from "express";
import router from "./routes";

describe("Product routes", () => {
  let app: Express;

  const createTestApp = () => {
    const app = express();
    app.use(express.json());
    app.use("/api", router);
    return app;
  };

  beforeEach(() => {
    vi.clearAllMocks();
    vi.restoreAllMocks();
    app = createTestApp();
  });

  // tests go here
});

By constructing a fresh Express app for each test, you guarantee:

No shared routing or middleware state
Predictable request/response objects
True test isolation

Takeaway

Mocking is about behavior substitution. Test isolation is about state control.

When testing Express routes, clearing mocks addresses only half the problem. To achieve reliable and deterministic tests, you must also reset—or recreate—the application runtime itself.

Feel free to drop your own experiences and lessons below.

Happy testing guys👋

Building Forms with React Hook Form (Part 2)

Dhokia Rinidh — Sat, 29 Nov 2025 19:03:15 +0000

Hey guys!

I kept exploring React Hook Form (RHF) over the past week, and something became very clear: it’s one of the most performant and thoughtful form libraries in the React ecosystem. After sharing a set of beginner-friendly lessons in my previous post, I’m back with more discoveries that will hopefully save you from some debugging headaches.

If you haven’t read the first article, you can find it here:

➡️ Building Forms Using React Hook Form #1

Now—on to the juicy bits.

More Lessons & Tips

1. `useWatch()` and re-renders

useWatch() lets you track field values without re-rendering the entire form, but only if you watch fields narrowly and intentionally. Watching a large object, an array, or a whole form node can cause your component to re-render far more often than needed.

Bad example — watching the entire array:

const fieldGroupsArray = useWatch({
  name: "fieldGroupsArray", // ❌ triggers re-render whenever anything changes in the array
});

Better — watch only what you need:

const conditionalValue = useWatch({
  name: "fieldGroupsArray.0.conditionalField", // ✅ only reacts to this field
});

Note that:

watch() re-renders the form where useForm() lives
useWatch() re-renders only the component calling it

Use the second option for large form structures or repeated field groups. Your CPU will thank you.

2. Subscribing to formState can be expensive

Accessing formState is powerful, but it has consequences. Some values trigger re-renders more often than others:

dirtyFields updates on every change while typing → constant re-renders
touchedFields updates when a user focuses on the fields
errors changes when validation runs. Not a problem unless your validation runs endlessly

Access only what you need. If you destructure everything because of "why not"—you might introduce performance issues blindly.

3. When using Zod with dynamic fields, be cautious with `shouldUnregister`

Like me, if you’re a user of Zod + RHF's dynamic conditional fields, think twice before enabling:

useForm({ shouldUnregister: true }) // ⚠️ Caution

Unregistered fields get completely removed from the form state, meaning you may lose default values that are still relevant for validation. This can lead to unexpected Zod validation failures, especially when showing/hiding fields conditionally.

The shouldUnregister flag immediately removes fields from RHF's internal state if it is not registered to any form input. In dynamic schemas, keeping fields registered helps preserve data consistency.

4. About using `<Controller>` / `useController()` when the standard `register()` isn't enough

Scenarios where it is suitable:

External UI libraries with no direct ref, value, or onChange props exposed.
Controlled inputs (e.g. Chakra UI <Select />) which possess their own separate internal state
Complex custom components where you want granular control over which elements receive {...field}

Example:

// You may bind only <input> to form state instead of rerendering label + error
<CustomField>
  <label>Username</label>
  <input {...field} />
  <p role="alert">{errorMessage}</p>
</CustomField>

This reduces noise, unnecessary renders, and keeps the field logic predictable.

Wrapping Up

Not all of this may be new to you — maybe you nodded through every section, maybe some of it made you open your project and fix things immediately. Either way, if we both improved our understanding today, that’s already a win.

Feel free to drop suggestions, corrections, or even healthy criticism in the comments.

More experiments coming soon 😉

Building forms using React Hook Form

Dhokia Rinidh — Fri, 21 Nov 2025 18:35:28 +0000

Hey folks!

While taking my online React course, I quickly discovered something: forms are everywhere. Whether you’re buying groceries online, booking a table, signing in, paying fees, or typing questionable prompts into an AI model at 2 AM — you’re dealing with forms.

Since I wanted my portfolio to look a little less “junior developer on day 3,” I decided to learn a solid form library alongside React. The first one on my list: React Hook Form (RHF).

After going through the docs and doing a healthy amount of trial-and-error (emphasis on error), here are some useful insights I picked up. Hopefully they help you skip a few of my mistakes.

Lessons Learned (a.k.a “Things I Wish Someone Told Me Earlier”)

1. `getValues()` gives you a snapshot, not a subscription

getValues() returns the current form data at the exact moment you call it.

Use it in:

event handlers
async functions
useEffect() callbacks
anywhere that gets triggered by something happening

Just don’t expect it to magically stay updated. It’s a snapshot, not a live feed.

2. `watch()` gives you real-time updates

If you need a piece of form data that always stays in sync, use watch().

It re-renders your component whenever those watched fields change. Perfect for features like:

showing live previews
enabling/disabling buttons
updating UI based on input

Just remember: watching many fields can cause extra re-renders, so use it intentionally.

3. Handling errors the proper way

Form errors can be accessed in two main ways:

by inspecting formState.errors
by using the second callback of handleSubmit(onValid, onError)

Both are useful, depending on whether you want to react to errors during submission or check them after validation.

4. Custom validators can be stacked (and async!)

When using the validate option inside register():

validate: {
  validator1: value => value.length > 3 || 'Must be longer than 3 characters',
  validator2: async value => await checkUsername(value)
}

You can:

define multiple validator functions
return true (valid) or a string (error message)
even write async validators that call APIs or servers

RHF will run them all and aggregate the results.

5. `reset()` behavior depends on whether defaultValues exists

If you did not pass defaultValues to useForm(), then calling:

reset({firstName: "John" })

will update both the current values and the internal “default values”.

If you did specify defaultValues, you can still override them by intentionally passing the values option:

reset({
  values: { firstName: "John" }
})

This makes that object the new default state of your form.

Final Thoughts

These are just a few tips that helped me understand React Hook Form better as a beginner. The library is incredibly lightweight, ergonomic, and fast — once you understand what each function is doing behind the scenes.

If you spot anything interesting or want to add your own insights, feel free to drop a comment. And don’t worry, more posts are on the way (yes, even the embarrassing discoveries).

Thanks for reading — and happy form-building!

Content consumption: Real world Development vs Big Tech Hype

Dhokia Rinidh — Fri, 04 Jul 2025 19:26:07 +0000

Intro

I would like to share my thoughts on a burning topic amongst most beginner-level engineers today. Most content these days creates excitement basing on FAANG companies (where one may never work, or need to work), cutting-edge frameworks (which one may never leverage / need to leverage), CS heavy content (for large scale apps), brain-boggling algorithms etc. But some of us really don’t need to wreck our minds to know about such things, at least not most of them if we are to thrive.

Confusion & Burnout

I know you have heard about the “imposter syndrome” which is a mandatory stage in the life of every developer. Bleeding-edge tech is released almost daily and thanks to our brain—which is not an input box to feed info into easily—cannot become a legendary coder by switching gears all the time. It has to go slow, enjoy the goodness of specialization, and leverage it to better solve real-world problems.

Emerging developers often keep feeling dissatisfied even with their excellent portfolio just because it still uses older tech stacks 😢 hence leading to learning burnout and decision paralysis as well on whether the career is even meant for them. Specialization and focus is key 🔑 😉

What SMEs care about

Most of them always prioritize more maintainable code over complicated new tech stacks, simplicity & reliability of code over “coolness” of the framework, and pocket-friendly approaches that keep consumer comfort first.

I am based in Uganda, East Africa, and I made a big mistake recently of creating a highly complex React-ChakraUI-based web application for a firm that simply needed a good hero-section for advertisement, a decent collection of beautifully styled HTML pages with instant loading that worked on the poorest network & oldest low-end devices, and what I did was completely disappointing. I don’t completely blame the tech-hype for this.

Stay focused on your needs, not on trends!

You need to know your exact market, actual skills that you will need the most and where to acquire them from. I personally avoid YouTube channels, blogs or newsletters emphasizing only on new tech (I don’t even understand well the jargon in it 😂). Rather, I follow up with people focused on real-world implementation of software skills, great communities, articles on status of SMEs & startups and project-based learning paths

Outro

I don’t criticize those acting contrary to the above terms. They may be fully focused on big tech standards & excellence in software development with the new tech. I just beseech you to understand your actual needs well. Updating yourself on modern trends occasionally is fine as these technologies are what come down to SMEs later on. It can also be quite motivating as well to see the future prospects of the industry you work in

As usual, please feel free to criticize, appreciate or share what you think about this.

My Web Development Journey - The New Maze

Dhokia Rinidh — Fri, 27 Jun 2025 18:59:12 +0000

My Absence

It’s been quite a while since I last posted on DEV or any tech community. It wasn’t a vacation, and I definitely didn’t plan to ghost all the awesome, collaborative folks here. The truth is—I hit a serious wall. A full-on maze of confusion that stalled my workflow.
I used to think going the self-taught route in web development was the ultimate shortcut for beginners. No degrees—just online resources, free courses, and a bit of hustling. Sounded like the magic formula. Well, yes..., but not entirely.

What I Realized

Unless you’ve got endless hours to figure out what to learn, the stamina to dive deep, and a secret potion to fight off imposter syndrome, self-teaching can hit really really hard.
Most of us are juggling jobs, studies, life... and trying to stay motivated feels like carrying water uphill in a basket. I’m working 8–9 hours a day, trying to protect my health and make time for hobbies. That’s when I made a tough call: go back to school for a degree. (Yeah, I cried a little too 😢 but the fog started lifting.)
But why? Get direct access to tutors, a structured curriculum, and a community to grow with. But wait—in a discourse with a great Uber engineer, I confirmed that even with a degree, I’ll still need to do a ton of self-learning, build projects, and contribute before I can really collaborate.

The Fear Factor

Here’s the kicker: I was afraid my online certifications wouldn’t hold much weight in interviews. It’s a huge concern for self-taught devs. That’s why I started looking for credible, recognized certifications alongside a degree—something with real validation behind it.

The Plan for the Game Ahead

So here’s where I’m at: I’m grinding toward the Meta Front-End Developer certification and pursuing a legit Computer Science degree to build credibility. But even with that, success means sticking to the grind—researching, pushing through bugs, building that portfolio from the ground up.
As usual, feel free to comment, criticize & share your opinion because in this maze, there’s no single path. Just your hustle, your code, and your courage.

Chronicles of Supermarket website #2: responsive design

Dhokia Rinidh — Fri, 31 Jan 2025 17:23:14 +0000

From #1 and moving ahead:

I previously posted my journey into building a simple (no fuss or perplexity; for beginners) supermarket website. I had only used HTML & CSS to construct a straight forward, unornamented website. As per the modern craze in web development, all websites should appear dazzling on however small of a screen it may be viewed. I therefore persuaded my brain to review my code and add a couple of media queries as well as beautify the previous code to achieve my goals.

However, this section also never went by without upskilling my brain-content.

Key lessons

Prefer using absolute units eg cm, mm, in, pt, px etc. for content to be printed to hardcopy. Avoid them to the most in responsive layouts.
Try to avoid setting fixed width in px, in etc. especially for large elements e.g. large banner images, <section>s or whatever forces a user to scroll horizontally. It may be tempting to initially satisfy your design by this, but always remember to replace with relative units such as ---%, rem, em, vw, vh.
Either set specific height & width (in relative or absolute units) to the parent flex_container, hence the nested_divs occupy space variably (I call this technique ‘fixed-container’), or height and width of containers as auto (flexible upto even zero) and hence fixed sizes of nested_divs determine the resultant size of the flex_container (I call this techique ‘fixed-nested-divs’). Most used is ‘fixed-container’.
Always design mobile-first (unless majority of audience are desktop users). Write default styles for small screens first, and use media queries for larger screens. Avoid extra fluff in headers, navbars… for mobile screens. Use media queries to modify very few properties for larger screen sizes (@media only screen and (min-width: 600px) applies styles for screens’ width of 600px and above).
Use (min-device-width: 400px) instead of (min-width: 400px) to check for device actual screen size instead of web document size. Styles under this are not affected by changing window size or by rendering another html file inside an html file by<iframe>s.
Use different images on different screen sizes using <picture>, more so the same image but of different resolutions as well ot reduce load bundle e.g. can use url('../assets/flowers-lg') on large screens and url('../assets/flowers-sm') on phones.
--em when set on font-size means relative to parent element while em in other properties s e.g. width: 3em means relative to font-size of current element.
Use em when you always want text to be certain size according to its immediate parent. Use rem in deep nesting scenarios when you want the size relative to fontsize of the root element (stays unchanged).
Properties commonly set with em and rem: font-size, margin & padding.
Properties commonly set with %, vw and vh: width, height, postioning (fixed & absolute), flex-basis, margin and padding.
Classifications of design technqiues (can use any one or combine):
- Link diff stylesheets OR
- Media queries within CSS OR
- Flexible grids & css column + Relative values & calc() + min & max

Please don’t hesitate to criticize and suggest edits 😘

Regular this, Arrow this (Tersely bulleted)

Dhokia Rinidh — Wed, 22 Jan 2025 19:44:37 +0000

Hello code-mates, ever since I learnt about this in Javascript a year ago, I had never fully felt mentally confident that I can interpret, analyse and refactor complicated scenarios where this is used. I therefore made a small cheatsheet-like summary to always help me get the immediate context & idea, especially when I am rushing through documentations or others’ code, and obviously infiltrate well later.

Here are a few bullets I always find handy in relation to this:

All regular functions (function myFunction() {}) always have their this as the global window object (in browsers) or global object (in Node JS), UNLESS it is called in a different context:
- As a method of an object.
- Explicitly bound by .bind(), .call() or .apply().
Regular functions have to be explicitly bound with a this value while arrow functions (() => {}) automatically get their this from the immediate enclosing parent-function (lexical scope).
The lexical/enclosing scope in which an arrow function is actually running is the immediate parent REGULAR function, even though it is inside an object’s method.
The this value of arrow functions (got at time of creation) is unchangeable while that of regular functions is changeable (.bind(), .call() etc.)
Unlike methods of object literals (const obj = {...}), functions defined as methods of classes, Event though regular or arrow, their this is always the object instance created (new MyClass())

Please feel free to suggest edits, add more bullets, or even criticize me on any blunders. I always welcome an opportunity to learn from excellent programmers like you! ☺️ 💛

Chronicles of Supermarket website #1: HTML & CSS

Dhokia Rinidh — Wed, 15 Jan 2025 19:29:54 +0000

My mistake

In the previous year, I learn a lot but in haste as well as in vain. I didn’t realize how and when the imposter syndrome sieged my determined mindset. It was indeed a big blunder to mock and neglect learning the fundamentals — HTML, CSS & vanilla JS); I never considered advice from great youtubers, so I it took me months of physical trial to realize this on my own.

The new site

Let bygones be bygones. This year I started afresh, learning the basic building blocks of web development with a rather cautious mindset. Starting up with plain HTML5 and CSS3, I have built a mini supermarket app with only these two technologies. Apologies in advance if your eyes pain and you cringe seeing so much newbie code; I tried to keep it as simple as possible. You can view the production site here.

⚠️ I have used some names and terms in the local language of my area of residence

Having accomplished this first stage, without any responsive design, any framework, any javascript, or any complicated sauce in this simple cookout, just with html and css, I still learnt quite a few interesting facts I want to share.

Key lessons

Set a specific height and width on a div and overflow-y: auto/scrollto allow scrolling inside the div, if its content is larger/more than its size
margin: auto makes a div centered in its parent. To horizontally center a child div in its parent, use margin-left; margin-right: auto. Similarly for vertical only centering, margin-top; margin-bottom: auto

Attributes you will use everytime with <input>:

<input
    id="for ref to label tag"
    name="for ref in js code"
    value="to be sent to server"
    title="global att, text shown when pointer hovers over elem" />

Place <input> inside <label> tags to automatically relate to the label without using the same id with for attribute

<label>
    <input type="text" />
</label>

<label>
    <textarea cols="35" rows="10" />
</label>

My Request

That’s a few of them. It’s just the beginning of this marathon. Please feel free to admire or roast (criticize) me on any blunders, I am eager to see your suggestions, as Industry experts, on how I can improve this site, its design, its implementation etc.

Lots of Love,

Rinidh 😉

I am productive, are you?

Dhokia Rinidh — Wed, 25 Dec 2024 19:36:46 +0000

Hello guys, how is the marathon going. Running in the fast paced world today, we realize that our brain is surely a powerful CPU but a weaker RAM. Taking out the fancy words, I mean that amidst very many daily tasks and to-dos, we can’t accurately remember and coordinate all, but surely, with focus on only one at a time, accomplish tasks like a expert.

I am a beginner, and after receiving loving support and advice from a number of senior developers (like you), I have ended up with a simple, beginner-friendly toolset / system for productivity, that I want to share today. To be honest, each has a different mindset, habits, likes, hates, preferences etc. but I feel this will help uplift newbies like me.

I decided to organize my information in 3 levels, according to the urgency of its need:

Level 1 : Immediate To-dos

Only store information that you are going to use at a maximum duration of tomorrow. I formerly used simple windows sticky notes, and they would be great up to the end of my career unless they had very small, hard-to-read letters, which are only customizable from general font settings of entire windows system.

I decided to stick with the desktop app of Google Keep (as I am a rising fan of Google Ecosystem). This also ensures automatic frequent backup to the cloud. I usually put information to help me start of immediately on the project the next day e.g. “style the banner on about-us page”

Level 2 : Tasks

Include information that you will be working on for the next 3 days, week or even few more weeks depending on your preference. I use Notion as it is great, especially when you will work with teams in the future. I may include information such as “Make html-css only website, max time: 12/01/2025”

Level 3 : Plan (Long Term)

Still using Notion, I set up a long term rough-copy list of what I have to learn, and keep adding to it whenever I find new technologies I need to learn, as well as which projects to make and when. This is crucial as it gives you a bird’s eye, or rather an eagle’s eye view of your progress and motivates you to push faster as you see the road ahead. As you keep completing one by one, keep transferring the current item to the “Tasks” list above.

I guess you might have noticed the toggle heading of “Routine” in the above photo. I realised that reading articles, documentation and even (sensible) social media posts is mandatory if you are succeed as a developer. I therefore drafted a timetable to follow for reading, taking out at least 30 to 45 minutes of my daily time

That’s it guys. Please do share what you think I and other beginner developers can include and exclude in this simple work plan. I never wanted to initially complicate my work with feature-rich apps. This also widened my thinking / creativity and proves to me the use of efficient, more personalized system of work

New to web dev like me?

Dhokia Rinidh — Sun, 15 Dec 2024 19:35:55 +0000

Hello enthusiastic developers,

I am Rinidh Dhokia, a self-learning web developer based in Uganda, with already about year of study & research, thanks to the widened world web, or rather world wide web 😉.

It's true that everything today is indeed available on the web. The problem is just about the way to discover & exploit these resources instead of spending thousands of dollars at colleges, unless you want to peruse through upto a doctorate.

It's going to be an interesting journey at this platform. I highly urge you to follow up with me, as I learnt that collaboration is key. No matter how good your skillset, if you can't work together with a team of friends to make the best out of it, it's not marketable.

Thank you...

Forem: Dhokia Rinidh

Summary of insights into traditional CSS Grid & Flexbox

Inline Direction (left → right in most writing modes)

Block Direction (top → bottom in most writing modes)

Restrictions / Differences

Dynamic Layout Patterns

Other Useful Notes

Track Sizing Keywords

Conclusion

Test Isolation vs. Mocking Mechanics in Express

The scenario

What clearing mocks does not reset

Why this matters in tests

The correct approach: reset runtime state

Takeaway

Building Forms with React Hook Form (Part 2)

More Lessons & Tips

1. useWatch() and re-renders

2. Subscribing to formState can be expensive

3. When using Zod with dynamic fields, be cautious with shouldUnregister

4. About using <Controller> / useController() when the standard register() isn't enough

Wrapping Up

Building forms using React Hook Form

Lessons Learned (a.k.a “Things I Wish Someone Told Me Earlier”)

1. getValues() gives you a snapshot, not a subscription

2. watch() gives you real-time updates

3. Handling errors the proper way

4. Custom validators can be stacked (and async!)

5. reset() behavior depends on whether defaultValues exists

Final Thoughts

Content consumption: Real world Development vs Big Tech Hype

Intro

Confusion & Burnout

What SMEs care about

Stay focused on your needs, not on trends!

Outro

My Web Development Journey - The New Maze

My Absence

What I Realized

The Fear Factor

The Plan for the Game Ahead

Chronicles of Supermarket website #2: responsive design

From #1 and moving ahead:

Key lessons

Regular this, Arrow this (Tersely bulleted)

Chronicles of Supermarket website #1: HTML & CSS

My mistake

The new site

Key lessons

My Request

I am productive, are you?

Level 1 : Immediate To-dos

Level 2 : Tasks

Level 3 : Plan (Long Term)

New to web dev like me?

1. `useWatch()` and re-renders

3. When using Zod with dynamic fields, be cautious with `shouldUnregister`

4. About using `<Controller>` / `useController()` when the standard `register()` isn't enough

1. `getValues()` gives you a snapshot, not a subscription

2. `watch()` gives you real-time updates

5. `reset()` behavior depends on whether defaultValues exists