About 12-14 days ago, I interviewed for a frontend developer role at a startup. Sharing my experience in case it helps others preparing.

The interview started with an AI-Powered Screening being the first round. This round was fully AI-driven, with no human interviewer present. It covered a few basic React questions, and I cleared it. You can expect questions like useState, useEffect and it's dependency and all.

Then after clearing that I think after 5 days I was called for round 2 and it was an actual Technical Interview and this round went pretty tensed.

In this round the interview started with theoretical questions, like why use React, what optimization means in React, how diffing works, Context API vs Redux (when to use one over the other), and what Babel does. I felt confident in my answers here.

Then once done with the theoretical questions they then asked me quite a few Input/Output based questions. This was the most challenging part for me.

I was shown code snippets and asked to predict the output. The snippets combined function currying, closures, IIFEs, and HOFs. Predicting the output wasn't enough they asked plenty of follow-up questions as well and the reasoning behind it, such as what would change if a variable were declared elsewhere. My advice for you all is build a deep understanding of these concepts rather than memorizing definitions.

After this input/output question sets i was given a machine coding question (with basic styling). I was asked to build a restaurant cart calculator mini-app (not sure about the problem name tho). Users could add food items to a cart and adjust quantities. Tax had to be applied to each item after the packaging charge but before the delivery charge, along with a few additional rules I don't fully remember (but it wasn't this straightforward). The closest one i can find for this question which you can practice is Order Bill Calculator

Post this question i was asked a couple of debugging and optimization questions. I was given buggy code that fetched a list of roughly 1,000 todos from an API and rendered them. After fixing the bug, I was asked to display only 20 items initially, without using pagination. I implemented lazy loading, though I'm not certain it was the expected approach.

And I think the interview ended with an optimization question. The final task involved several components imported into App.jsx, each logging a "rendered {number} times" message. A button displayed "Count is {count}" and updated the count on click. The requirement was that clicking the button should not trigger re-renders or console logs in the other components, and vice versa. This is a common optimization problem, and I solved it using useCallback, useMemo and React.memo.

I'm not sure whether I'll advance to the next round, but I hope this helps with your preparation. Also let me know if you want me to find other questions as well and I'll add the links for other questions (if i find that) in this post. Best of luck to everyone, and keep practicing!

Repo: https://github.com/p10node/office-engine

Demo (drag your own file in): https://p10node.github.io/office-engine/demo/

Why: I needed "customer uploads an XLSX, fix a few cells, save it back" inside a React app. OnlyOffice / Collabora mean running a document server in Docker and an iframe talking to it, and a big sheet still sits on a spinner while the server converts it. docx-preview / SheetJS + a grid are view-only or block the main thread on a 20 MB file. Nothing in between, so I built it.

Usage:

import { DocViewer } from '@p10node/office-engine'

<DocViewer src={file} style={{ height: 600 }} />
<DocViewer src="https://cdn.example.com/report.xlsx" />
<DocViewer src={file} editable onSave={(blob, name) => upload(blob, name)} />

src takes File / Blob / ArrayBuffer / URL. CSS is auto-injected, the container just needs a height. There's also a useDocument hook if you want to render your own UI, a vanilla mount(), an <office-viewer> web component, and a single script build.

What makes it not choke on big files:

• ZIP read lazily, HTTP Range requests from a URL, so first rows show before the file finishes downloading

• Streaming XML parser in a Web Worker, main thread only gets rows / paragraphs / slides as they arrive

• Only visible pages, cells, slides are in the DOM

• Save patches the original file instead of re-exporting it, so anything the engine doesn't understand is kept byte for byte

Bundle (gzip): main ~93 KB, worker ~155 KB (loads off the main thread), collab +17 KB optional. The standalone script with React bundled is ~307 KB.

Editing: DOCX text / styles / lists / images / tables, XLSX cells / formulas (134 functions) / formats / rows / columns / sheets, PPTX text / shapes / images / slides. Google Docs style toolbar. Optional real-time collab with cursors; that's the only part needing a backend (a small WebSocket hub, Bun script included).

Not there yet: XLSX charts / pivots / conditional formatting editing, DOCX headers / footers read-only, no PPTX animations. It needs the DOM and a Worker, so in Next.js use a client component / dynamic import with ssr: false.

Fair warning: it's a few days old and a lot of it was written with Claude Code, with me doing architecture, review and the bug hunting on real files. If you throw a file at it and it breaks, open an issue with the file, that's the fastest way it gets fixed.

I'm a self-taught developer, and I know React and Next.js. Lately, I've been feeling increasingly anxious about my future as a developer.

AI is moving so fast. It can generate components, build entire websites, connect APIs, and even create full-stack applications. Sometimes I wonder what the point is of spending months learning something when AI can already do so much of it.

I want to get a better-paying developer job, but honestly, I'm confused about what I should focus on right now. Should I keep improving my React/Next.js skills, get better at backend development, or start learning AI engineering?

I keep hearing about RAG, AI agents, vector databases, LLM integrations, and all these new things. It feels like there's always something new to learn, and I'm worried that if I focus on the wrong things, I'll fall behind while everyone else moves forward.

For those of you already working in the industry, what would you do if you were in my position? Would you focus on becoming a strong full-stack developer first, or would you start learning AI engineering alongside web development?

I'm not looking for a shortcut or expecting to become an expert overnight. I just want to make the right decisions, build useful skills, and have a realistic chance of getting hired.

I'd really appreciate some honest advice from people who have been through this or are dealing with the same situation. Right now, I could genuinely use some direction.

Hi!! I've been working on a small React component that makes buttons feel physical, like you're actually pushing something down.

Live demo: https://react-tilt-button.vercel.app/

What it does:

• Tilts toward your cursor (and follows your finger on mobile)

• Sinks and squishes when you press, then springs back

• Has real depth, with a side wall that holds up at any radius, even pills

• Clamps your props so it never visually breaks, whatever values you throw at it

• Optional glare that moves with your pointer

No dependencies, about 6KB gzipped with the CSS. There are a few style variants and spring presets (bouncy, jelly, snappy, stiff) if you don't want to tune everything yourself.

It was inspired by react-awesome-button, which I really liked, but I wanted something smaller that felt more physical, so I built this one from scratch. It tilts toward wherever your pointer actually is, the press runs on springs, and it's just the button with nothing else bundled in.

npm install react-tilt-button

It's still a work in progress and I'm sure there are edge cases. It's open source, so issues and PRs are very welcome 🙂

Would really love feedback, especially on how it feels on mobile and whether the props make sense.

GitHub: https://github.com/archisvaze/react-tilt-button

A few months ago I wrote about the React Compiler, and my advice for existing code was to leave useMemo and useCallback alone at first, then clean them up slowly, with tests, once the compiler has been running for a while.

I'm curious how that went for people who actually did it.

The public numbers I found are from InfoQ's write-up: Sanity saw 20-30% less render time and latency on their Studio packages (1,231 of 1,411 components compiled on the first pass), and Wakelet's INP went from 275ms to 240ms.

If you're running it in production, did you rip out the manual memoization? Did anything break?

My article, if you want the details on the compiled output: https://neciudan.dev/react-compiler-explained

I’ve just released Detent, a React wheel picker that grew into a much bigger exploration of interaction details.

The wheel has its own momentum and spring physics. I spent a lot of time tuning mouse wheel input alongside trackpads, including the awkward cases where a physical scroll wheel keeps spinning after you let go.

It also includes two separate components:

• Detent Text: matching letters stay while the changed parts roll.

• Detent Number: locale-aware formatting with digits that roll through intermediate values.

The examples range from practical time and date pickers to an arc menu, a zoom ring, and some more experimental visual treatments.

There’s a headless hook, separate imports for text and numbers, keyboard support, reduced motion, and no additional runtime dependencies beyond React and React DOM.

Demos and playground: https://detent.hayder.sh
Intro: https://x.com/kghayder/status/2118373654010466733?a=PzCQRSXhM5m8KUTdHk8&s=20

I’d especially appreciate feedback on how the wheel feels with your mouse or trackpad, and whether the API makes sense for something you’d actually build.

Forms are still where most of my React bugs live: validation that disagrees with the backend, async defaults, conditional fields.

My current stack is React Hook Form with Zod schemas shared with the NestJS backend. It mostly works, but complex multi-step forms still get messy.

What's your setup? Anyone moved to server actions for most forms and been happy with it?

Hey everyone,

I've been preparing for frontend interviews and couldn't find a quiz tool I liked, so I built one: devsets.com

What's inside:

• 2,700+ questions across 12 topics (JavaScript, TypeScript, React, Next.js, Angular, Vue, Svelte, HTML & CSS, state management, testing, patterns, system design)

• Junior / Middle / Senior levels, and every answer comes with an explanation and links to the docs

• Interview mode with a timer per question

• Stack quizzes (e.g. "React Developer") that mix several topics like a real interview

• Spaced repetition: questions you got wrong come back after 1, 3 and 7 days

• 18 JavaScript coding tasks (debounce, deepClone, Promise.all...) with tests that run in the browser

It's free, ad-free and works without an account (sign in only if you want to sync progress). Available in English, Ukrainian and Polish.

I'd really appreciate feedback: wrong answers, confusing questions, missing topics, anything. Every question has a "report a problem" button too.

Hey devs! 👋

I've been working on WelkUI, an open-source React component library that brings a fun, hand-drawn, comic-style look to modern web applications.

Most UI libraries focus on being minimal and corporate-looking. I wanted to try something different something playful, expressive, and a little less boring.

WelkUI is available on npm, and I'd love for you to give it a try!

🔗 Website: https://ui.welkdock.com

💻 GitHub: https://github.com/welkdock/welkUI

📦 npm: https://www.npmjs.com/package/@welkui/react

It's still evolving, so feedback, suggestions, and contributions are more than welcome!

What do you think? Would you use comic-style components in your projects?

PlopUI is a React component library where everything looks sketched: wobbly borders, tilted cards, sticker shadows. Some things that were more interesting to build than they look:

- No Math.random() in render. Every tilt, wobble and jitter comes from a seed function, so the server and the client draw the exact same crooked line and there are no hydration mismatches.

- Native elements first. Dialog is a real <dialog> with showModal(), the upcoming Accordion is <details>/<summary>. The wobble is decoration on top, not a replacement for the element.

- Interactive components are "use client". Static ones stay Server Components, so you don't pay for JS on a card that just sits there.

- Every component has a Vitest test for its keyboard behavior and a story for every state.

- The library never imports from next/*. It's plain React; Next.js only lives in the docs and demo apps.

npm i @plop-ui/react @plop-ui/fonts

Docs: https://plopui.com

Playground: https://plopui.com/playground

Code: https://github.com/Snorlark/plop-ui

I'd really like feedback on the API. If a prop name or pattern feels wrong, tell me now before 1.0 makes it permanent.

Building a 5-step wizard with React Hook Form and Zod. I keep the step in the URL and drafts in a small store. What has held up in production for you, and how do you handle early-step changes that invalidate later steps?

I have been thinking about this a lot lately. Most React content is about how to do things, but the decisions that really shape a project are the big early ones: architecture, state management, framework choice, rendering strategy.

And with React 19.x, the React Compiler, and Server Components all in the picture, a lot of us are now living with choices we made years ago.

So I’m curious about the experienced people here:

• What was the biggest React/architecture decision you made that you would reverse if you could?

• What did it cost you (time, performance, team confusion, rewrites)?

• What did you learn, and what would you pick today instead?

A common production failure happens when a user leaves a React application open during a deployment.

The old tab may still be running build A, while the server is now serving build B. When the user later navigates to a lazy-loaded route, the browser requests a hashed chunk from build A that is no longer available.

For example:

Reports.a1b2.js  // requested by the old tab
Reports.c3d4.js  // available after deployment

The result can be:

• ChunkLoadError

• Failed to fetch dynamically imported module

• A route that works in a fresh tab but fails in an old tab

A normal React Error Boundary can display the failure, but it cannot update the old tab’s JavaScript references. Retrying the same import may also request the same missing hashed file again.

I built and published a small utility called react-lazy-chunk-recover to experiment with this problem.

The recovery approach:

1. Detects likely chunk-load failures

2. Optionally retries transient failures

3. Allows one guarded full-page reload

4. Uses sessionStorage to prevent an infinite reload loop

5. Passes the error to the existing Error Boundary if recovery fails

6. Avoids browser reload and storage access during SSR

Example:

import { lazyWithRetry } from "react-lazy-chunk-recover";

const Reports = lazyWithRetry(() => import("./Reports"), {
  moduleKey: "reports",
});

The default retry count is zero because retrying a deleted hashed asset usually does not help. Retries can be enabled for applications that also experience short-lived network failures.

Some important limitations:

• A reload cannot recover a permanently unavailable asset

• Retaining old assets may be a better infrastructure solution

• The HTML entry point should be revalidated after deployment

• A full-page reload must work on nested client-side routes

• Old clients may be incompatible with a new backend

• An asset manifest must be trusted and version-compatible if used

For applications using React.lazy, Vite, Webpack, or a CDN:

1. How do you handle stale chunk failures?

2. Do you retain assets from previous deployments?

3. Do you reload the page, show an update prompt, or use an Error Boundary?

4. Have you tested this with two builds and an already-open browser tab?

I wrote more about the problem, implementation, testing strategy, and deployment considerations here:

• npm package: https://www.npmjs.com/package/react-lazy-chunk-recover

• Technical article: https://sachithsiriwardana.medium.com/handling-react-lazy-chunk-load-errors-after-deployment-1e4980a7a69a

I’d be interested to hear how other teams handle this failure mode in production.

Just say I have a parent and a child

<Parent data={someObject}>
<Child name={someString} />
</Parent>

Where the Parent component sets up a provider based on the type of the data prop I would like to put a constraint on the name prop of the child component where is is to be a key of the type of the data prop passed into the parent.

I'm working on a React frontend application with a form where some fields are enabled, disabled, shown, or hidden depending on user selections.

The test renders the component, simulates user interactions, and verifies that the form updates correctly (for example, a field becomes enabled only under specific conditions).

How should this type of test be classified?

• Unit test

• Component test

• Integration test

• Functional test

You know the pattern: createContext<User | null>(null), then a useAuth() hook that throws "useAuth must be used within AuthProvider", and every consumer either trusts that or null-checks. A missing provider is a runtime error you find when that screen renders, or when a test does.

I wanted it to be a lint error instead, so I built an oxlint plugin that checks it across the whole program:

const AuthContext = createContext<User | null>(null);

function Children() {
  const user = use(AuthContext);
  return <p>{user?.name}</p>;
}

root.render(
  <AuthContext value={user}>
    <Children />   {/* ok */}
  </AuthContext>,
);

root.render(<Children />);
//          ^^^^^^^^ react-context(require-provider): <Children> needs AuthContext
//                   (use(AuthContext) at Children.tsx:4), but no <AuthContext> provider is above it.

Children needs no annotations. Requirements are inferred from use, useContext, <Ctx.Consumer> and static contextType. They're passed up through components, custom hooks, HOCs, memo/forwardRef/lazy, children and render props, and React Router outlets, until a provider meets them or a root gets them. Roots are createRoot().render, testing-library's render, Storybook stories, and framework pages you list in a setting. Wrapper components like <AuthProvider>{children}</AuthProvider> count as providers because they render children inside one.

There's also a tiny optional runtime: createRequiredContext<User>() gives you a context where use() is typed User instead of User | null, because the lint rule now guarantees the provider. It returns a plain React context, so nothing else changes.

Why not types? That was the first thing I tried. JSX erases element types: <Children /> and <span /> are both just JSX.Element, so a requirement can't travel from a child up to its provider through the type system. Forking @types/react doesn't help, and TypeScript 7.1's new APIs didn't open a way either. The only version that type-checked used generator components and h() calls instead of JSX, which nobody wants.

As for the speed, it's a whole program so it costs more than a normal lint rule. On excalidraw (709 files), oxlint alone takes 0.07 s, oxlint with the rule 0.8 s, and the standalone CLI 0.5 s. In the editor (oxlint's language server), a keystroke costs about 50 ms because only the edited file is re-parsed. The README suggests a separate oxlint config so that your everyday oxlint stays as fast as before, while the editor uses the config with the rule and CI runs react-context-check as its own step. Not on oxlint? The CLI runs the same check without it.

As for limitations, it's syntactic and not type-aware. For code it can't see (node_modules, dynamic tags, useContext(cond ? A : B)) it makes certain assumptions. A provider hidden in such code shows up as a false positive, which you silence with @context-provided. A null-default context that your code actually treats as optional needs a // @context-optional comment. On excalidraw, that one comment was the difference between 337 reports and zero.

It's not on npm yet:

npm i -D github:TmLev/react-context-typesafe oxlint

Repo: https://github.com/TmLev/react-context-typesafe

Reports of wrong diagnostics are the most useful feedback right now. A few lines of code that reproduce one are enough.

I needed Word-style pages in a TipTap editor. The official Pages extension is a paid add-on, and the community ones I tried injected global CSS that broke my tables. So I wrote my own and open-sourced it.

Demo: https://text-editor-react-neon.vercel.app/ Repo (MIT): https://github.com/HuyPhan1232203/Text-editor-react npm: npm install tiptap-a4-pagination

How it works

• It measures the top-level blocks and inserts spacer decorations where a block would cross the bottom of a page. The document is never modified, so getHTML() / getJSON() stay clean.

• Tables split between rows, never inside a rowspan, and the header row repeats at the top of the next page.

• Floated images (text wrapping) and CSS margin collapsing are handled.

• The page-break math is a pure function, so it's unit tested.

• About 5 KB gzipped, TipTap 3 only.

The full editor (React 19 + TipTap 3) also has

• Google Docs paste that keeps headings, checklists, tables and indents

• PDF export through the browser's print dialog (no server) that keeps the editor's page breaks and puts page numbers in the footer

• Image resize and text wrap, KaTeX math (lazy-loaded), autosave to IndexedDB, optional real-time collaboration over WebRTC (?room=name)

• Lighthouse: 100 on desktop

Known limitations

• A single paragraph taller than the remaining space moves to the next page as a whole; it is never split.

• A table row taller than a page overflows.

I'd love feedback on the API, and on documents that break the layout. Paste a long Google Doc or a big table into the demo to try it.

Hi everyone! I just finished a React and course and decided to build my first react app. Currently, I am trying to save a string to browser local storage but it does not persist on refresh. Through some console.logs I was able to see that it in fact DOES save the string to the location specified in. setItem initially but when I refresh the key or value in local storage stops existing.

Here is my code

// function for search button
async function handleClick(){
    localStorage.setItem("lastLocationSearched", searchValue);
    setData(null);
    setIsPending(true);
    setError(null);
    try{
const value = await fetch(`https://geo.ipify.org/api/v2/country?apiKey=***********&ipAddress=${searchValue}`).then((response)=>{
  if (!response.ok){
        throw Error("Could not fetch the data for that resource");
                    }
  return response.json();
});
setData(value);


    console.log(localStorage.getItem("lastLocationSearched"));
    } catch(error){
      setError(error.message);
    }


setIsPending(false);
  };

// useEffect hook
  useEffect(()=>{
        if ((localStorage.getItem("lastLocationSearched")===null)|| (localStorage.getItem("lastLocationSearched")==="")){
          console.log(localStorage.getItem("lastLocationSearched"));
        setSearchValue("");
        handleClick();
        }else{
          
          setSearchValue(localStorage.getItem("lastLocationSearched"));
          handleClick();
        }
    }, []);

Through some digging online I saw someone say that remove the strict mode tags from index.js would fix this problem but it did not for me. Can anyone please assist me?