Here is my honest question:

What's the actual problem with the useEffect hook? All over the X/twitter, I see a lot of negativity about this hook. It seems like a buggy thing in React.

My opinion is that developers blame useEffect because it's often used for data fetching as the primary use case. As we deal with various states like loading, data, error etc… synchronization of these causes bugs.

Also, a misunderstanding of the rendering cycle in React, such as where useEffect gets called could introduce additional misuses and bugs.

Hence, just saying useEffect is evil, may not be the right assumption is what I think. But, there could be cases that I'm missing.

What's your take or opinion about it?

Curious how people handle this in practice. Take something like a form field whose value is technically "derived" from a couple of other pieces of state (say, a computed total, or a filtered list) but where computing it is expensive enough or async enough that it doesn't feel right to just recompute it inline during render.

The "official" answer is usually "compute it during render, memoize with useMemo if needed," and I get why - it avoids the classic bug where a useEffect writes to state and triggers an extra re-render, plus it keeps the value always in sync by construction. But in practice I keep running into cases where the derivation genuinely can't happen synchronously during render (it depends on a ref, a DOM measurement, or an actual async call), and at that point it stops feeling like "derived state" and starts feeling like its own piece of state that just happens to be initialized from other state.

Where do you personally draw that line? Is there a rule of thumb beyond "sync and cheap = compute in render, anything else = its own state + effect"? And for the async case specifically, do you reach for a library (React Query, SWR, etc.) even for small in-component derivations, or is that overkill below a certain complexity threshold?

I put together a list of React problems I kept seeing come up in interview prep — mix of core hooks, a couple of classic "build this component" asks, and a few that companies like Meta/Airbnb/Flipkart actually use. Figured I'd share instead of just keeping the list to myself.

Didn't want to just describe them — you can open each one and actually write + run the code against real tests in the browser, no setup. Links go straight to the problem.

1. Build a counter with three buttons. The classic warm-up — but the interesting part is making sure rapid clicks never lose an update.

Practice counter problem

2. Delay a value until the user stops typing. You've used this in every search box you've ever built — now write the hook yourself.

Practice this problem

1. Track what a value used to be, one render ago. Small hook, but people trip over when it actually updates.

Practice usePrevious hook

1. Model a shopping cart's add/remove/update-quantity logic. A good test of whether you reach for useReducer or keep fighting with useState.

Create shopping cart

1. Build a traffic light that cycles red → green → yellow on its own timer. Looks simple until you have to get the timing and cleanup exactly right.

Create traffic light

6. Build a search box where slow responses can't overwrite fast ones. This is the one that trips almost everyone up the first time — asked at Airbnb.

Create search box

7. Render a comment thread with infinite nested replies. Recursion inside JSX — asked at Meta.

Build nested comment

8. Stop a long list from re-rendering every item on every keystroke elsewhere on the page. A real performance debugging exercise, not just a memo() one-liner.

Practice memoization

9. Give a callback prop a stable identity across renders. Sounds trivial, isn't — especially once a child component is memoized.

Stable callback

10. Build a modal where keyboard focus can't escape it. Accessibility question that separates "I use libraries" from "I understand the DOM."

Practice this problem

11. Write a fetch hook that won't re-request data it already has. Basically: build a tiny cache layer from scratch.

Build usecatche

12. Manage state for a multi-step form wizard. Back/next/jump-to-step, without the state turning into spaghetti.

Multi-step form

13. Build an autocomplete search with keyboard-navigable suggestions. Filtering logic plus a surprisingly fiddly amount of UI state.

React auto-complete practice

14. Add undo/redo to a stateful app. Command-pattern state history — the kind of thing that's easy to describe and annoying to actually implement cleanly.

Undo/Redo Functionality

15. Build a month calendar grid that handles real date math. Leap years, month boundaries, the works — asked at Flipkart.

Build calendar grid

Hi everyone,

I'm looking for a fully open-source spreadsheet component for React.

I do not want a paid/commercial library or a library where important spreadsheet features require a paid license.

I need something closer to Excel / Google Sheets, rather than just a data grid.

Main requirements:

• Fully open source and usable in a commercial project
• React + TypeScript support
• Import .xlsx Excel files
• Export to .xlsx
• Preserve Excel formatting as much as possible
• Formulas and calculations
• Multiple worksheets
• Cell formatting
• Merge/unmerge cells
• Copy/paste
• Sorting and filtering
• Data validation/dropdowns
• Freeze rows/columns
• Undo/redo
• Insert/delete/resize rows and columns
• Good performance with larger worksheets
• API for programmatically reading/updating cells
• Custom toolbar/components
• Extensible enough to implement drag-and-drop elements/components into spreadsheet cells

I've already looked at Univer and FortuneSheet, but I'm trying to find the best option with strong Excel import/export support.

My ideal flow is:

Import existing .xlsx → Edit in React → Export back to .xlsx

without losing important formulas, formatting, worksheets, merged cells, etc.

What is the best fully open-source React spreadsheet library in 2026 for this?

If you're using one in production, I'd really appreciate hearing about its limitations, especially around Excel import/export.

Thanks!

Introducing a new major update for the "Electron React App" desktop app's starter kit.

Let's talk about the worst part of building Electron apps. You want to minimize a window from a button. So you write a handler in main. Then invent a channel name. Then add a preload bridge entry. Then declare the types. Then finally make the call in the renderer. Five files for one button, and the whole thing silently rots the day you rename something.

v13 throws that out. You define the feature once in main, and the renderer just has it. Typed, auto-completed, React hooks attached. No channel strings anywhere.

Read more about the new changes in the Repository page:
https://github.com/guasam/electron-react-app

Feature Highlights:

- Type-safe IPC: queries, commands, streams, and events, inferred end to end
- Cross-window state owned by main, synced live, with opt-in persistence
- Sandboxed renderer with a two-line preload
- Custom window frame, titlebar, and menus with keyboard shortcuts
- Light and dark theme
- React error boundary with detailed dev reporting
- Import path aliases for app, lib, conveyor, and resources
- Shadcn UI on Radix, styled with TailwindCSS
- Vite HMR, with ESLint and Prettier preconfigured
- VS Code debug configs for both main and renderer
- electron-builder packaging for Windows, macOS, and Linux

If you were starting an Electron app tomorrow, what would you want already handled for you?

I've been working on HonestUI, and I wanted a real project to test the components against instead of making more isolated demos.

So I built this Next.js analytics dashboard starter and open sourced it.

It uses HonestUI for the UI and charts, with ECharts underneath the chart components. The starter has working date filters, revenue views, customer search and filtering, retention data, responsive navigation, loading states, and dark mode.

There is no auth or backend wired in. The data is static on purpose so the repo stays easy to clone and change.

I also tried to avoid the usual dashboard template where everything is a separate card with a number in it. I wanted it to look closer to an actual SaaS product.

Demo: https://dashboard-template.honestui.com

GitHub: https://github.com/honestui/honestui-dashboard

I'd be interested in feedback on the starter itself, especially anything you'd expect to be included before you'd actually use something like this for a new project.

Hi everyone!

For a while now, I have been working with React and Storybook libraries. react-docgen and react-docgen-typescript libraries are the supported libraries by Sitecore to extract metadata and populate the arg table with jsdoc comments and types.

As components' types grew more complex, react-docgen and react-docgen-typescript stopped giving me enough. They're good libraries, but they often fail to parse jsdoc comments and interfaces correctly, forcing me to manually override ArgTypes — which means duplicating information in both the type files and the Storybook files.

I was looking for some ideas to implement with AI, and it pushed me to build a new docgen parser. My main goals were parsing union types more accurately, making sure JSDoc comments always show up and letting me see the full structure of an interface without leaving Storybook.

Part of the motivation is also that the two main tools we have - react-docgen and react-docgen-typescript — haven't been updated in 6 months to a year.

This is my first open source project. I plan to keep improving it and maintain it long-term if people find it useful and see a future in it.

Link: https://www.npmjs.com/package/react-props-parser

I'd like you to test whether you are using Storybook and TypeScript, and share your feedback if the output is better for you compared to the default parsers.

If you let me know what breaks, what's missing, or what you'd want changed, I can turn around fixes quickly. Many thanks beforehand!

Hello, I'm a nextjs(react) fullstack developer, currently working in a company as a single developer on this position.

---

In the near future I want to transfer to a big company / team to work on big projects and as we all know most of the worlds big softwares aren't made with js, so i want to learn a mew programming language and follow a new path.

---

I'm trying to make a choice between: Java, Python or going into mobile development with React Native.

-

I was also thinking about RUST, but the market doesn't seem that big for it.

-

I'm not that good with math and I also know that python is often used in companies for data analysis.

---

I would appreciate any advice from you guys on helping me choose my next path.

Thank you!

I've got a filter panel in a Vite app on React 18 where the date inputs wipe themselves maybe one time in five when the parent list refetches. I've ruled out the usual cause, the child isn't declared inside the parent's render body, and the key I pass it is a stable string. I put a log in the child's mount effect and it fires every time the fields clear, so it's actually remounting rather than losing state some other way. I've been on this about three hours and I can't work out what's different about the renders where it happens.

I feel like this decision gets made almost by accident on a lot of teams — either everything ends up in Redux/Zustand/Context out of habit, or nothing does and you end up prop-drilling through five components to pass a single boolean. The rule of thumb I've seen most often is "if more than 2-3 components that aren't directly related need it, lift it to global," but that always feels a bit fuzzy in practice. Do you have an actual heuristic you use, or is it more of a gut call that gets refactored later once the pain shows up? Also curious how people handle the in-between case — state that's shared by a meaningful chunk of the tree but is really more "feature-local" than "app-global," where a full global store feels like overkill but prop drilling is annoying.

I kept losing the same explanations in bookmarks and half-remembered blog posts, so I spent a few months writing it all down in one place.

573 topics across 8 sections — the browser, JavaScript, React, Next.js, backend, data, system design, AI/LLM engineering, practices and behavioural.

One rule decided what got in: a topic earns a page if it can plausibly come up in a real interview round, or if you need it to answer something that does. That's why there's no algorithms grind, and why 70 topics are about building with models.

Every page is the same shape — what it is in one line, what it is, why it matters, key points, then the links out. Three to five links per topic, exactly one marked "start here", and a script re-checks all 1,415 on a schedule so they don't rot.

Free, no account, no ads. MIT code, CC-licensed writing, all on GitHub.

Website - https://theengmap.vercel.app

Github - https://github.com/prateekkk26/engineering-map

Product Hunt - https://www.producthunt.com/products/engineering-map?launch=engineering-map

It's on Product Hunt today too if that's your thing — but mainly I'd like to know what's missing, especially from anyone who's run these loops from the other side of the table.

So far, I understand that wrapping a function with startTransition tells React to treat it as a non‑urgent update. So if any urgent action occurs, React can respond to it immediately without blocking.

But here is where I got stuck. The docs say:

“useTransition is a React Hook that lets you render a part of the UI in the background.”

“The function passed to startTransition is called the Action. You can update state and (optionally) perform side effects within an Action, and the work will be done in the background without blocking user interactions.”

I don’t really get what “in the background” really means.

Looking at the example, I don’t understand why, with startTransition, the “Total” only renders once with the final "Total" after clicking “quantity” multiple times, instead of updating multiple times according to the number of times the “quantity” was clicked

Does “run in background” prevent multiple renders and only show the final result??

I've always found translation keys a little strange.

You start with something perfectly readable:

tsx <button>Delete account</button>

Then i18n turns it into something like:

tsx <button>{t("settings.account.delete")}</button>

Now the source code, translation keys, and translation files all have to stay synchronized.

So I tried a different approach with Zintl:

What if the source string itself could be the thing the localization system knows about?

With Zintl, you keep writing normal application code:

tsx <h1>Welcome back</h1> <p>Your account is ready.</p> <button>Continue</button>

Zintl's compiler discovers the localizable strings and builds the localization layer around them.

The goal is that adding i18n shouldn't mean rewriting your application around t() calls.

It's currently alpha, so I'm very much not claiming this is production-ready.

I'm looking for React developers who have actually dealt with i18n to try it and tell me where this approach falls apart.

Especially interested in:

• translation key management
• dynamic/interpolated strings
• component boundaries
• pluralization
• large applications
• translation workflows/TMS
• anything you think a compiler like this should handle

Docs: https://zintljs.github.io/zintl/en

I'd genuinely love the criticism. If you think the whole idea is flawed, tell me why.

I’m reading the React docs, but I find this passage confusing. Could someone explain it to me?

"Another example is reusable state. Concurrent React can remove sections of the UI from the screen, then add them back later while reusing the previous state. For example, when a user tabs away from a screen and back, React should be able to restore the previous screen in the same state it was in before."

React docs link

Hey r/reactjs,

I've been working on Oasis Editor, an open-source TypeScript document editor with its own Canvas-based rendering engine.

React sits on top as an adapter rather than owning the editor runtime, so the same core can be used from vanilla JS, Vue, or headless environments.

The editor handles paged layout, text rendering, selections, images, tables, and document geometry through its own rendering pipeline, and exposes a typed command/plugin API.

Live playground:
https://celsowm.github.io/oasis-editor/#/editor

GitHub:
https://github.com/celsowm/oasis-editor

I'd love feedback on the React integration, API design, and overall architectu

I want in my practice chat app to be able to paste an image into a text input and be able to send it, on how to actually do this, I am unsure

My idea is this given a text input:

- a user could Ctrl-V (i.e., paste) something from his clipboard (a file in this instance), until a download url is returned (see below) there will be some loader spinner thingy
- In the backend is requested an Upload URL
- (somehow) whatever they pasted is immediately uploaded, likely by the path? But I am still a little bit unsure on that part
- a Download URL is returned on that S3 upload (SOMEHOW)
And thus you replace that temporary spinner with the download URL and the person can send it.

This is at least my idea on how you should be able to upload a piece of media in a message and be able to send it, I don't want just message attachments, that would be an easier story because once the association is made between the message and attachment you display it. I want something like in forums where the image can be embedded anywhere,

There is also one more small concern, on slow connection do you want to wait for the file to finish uploading first and then allow the user to send their message, or just send the message and let the upload come later, if the latter, how would you go across with doing that!?

The issue is, I have no idea on how to do this, I gave my approach above, I would really appreciate it if you guys gave some advice on what your approach would be and secondly, how to implement it, I already can get a presigned URL so that's not an issue

This is more of a design question, but it's also really interlinked with react so sorry if this is the wrong place to ask! ;-;

That's all :)