I am creating a little chat app for practice, but I was unsure what direction to take with the editor, out of the options I found TipTap and Lexical, I tried a bit of both (Didn't get very far with either yet) But I am still so torn on which one I should try first

In this I want more possibilities of what you can put in the chat, for example: Embedded images, tables, maybe some excalidraw integration, etc.

I also don't want to spend too much time on either and realizing that picking one over the other was not worth it long-term because of the timetaken

If anyone has used tiptap, lexical or both could you give some pro's and con's to each and some guidance on what I should pick?

Thanks! :)

I’ve been working on NexoreUI(v1.5), but this time I focused on the visual builder.

You can customize a component visually, change its props, preview the result, and then copy the code into your project.

The goal is to make it easier to go from “I like this component” to “I actually use it.”

Still early, so I’d love to hear from React developers:

Would you actually use a tool like this?

https://nexoreui.site
Github: https://github.com/Al1mov77/NexoreUI

Kya koi muje bta sakta hai ki apni portfolio website bnane k liye UI kese choose kre

Not the stack, not the libraries — the architecture or code organization decision you regret the most.

Hi all,

Sharing a project I recently finished and open-sourced: LaunchPad Lite.

It’s a clean starter template built around the Next.js 15 App Router ecosystem with a focus on type safety and modern auth:

- Better Auth: Handled via Server Actions and route handlers, avoiding legacy NextAuth quirks.

- Drizzle ORM: Minimalist schema setup designed to connect effortlessly with Supabase, Neon, or local Postgres.

- Tailwind CSS v4 + Radix UI: Fast UI primitives without CSS bloat.

GitHub: https://github.com/BZDevelopments/LaunchPad-Lite

For anyone who eventually needs full Stripe subscriptions, AI SDK v5, or multi-layout support, I also maintain a Pro version, but Lite is 100% self-contained and free forever. 

Take a look at the repo structure and let me know what you think of the architecture!

Hi, I made an free english learning app site

it has ipa (rachel english) and speech rules with annotations to study connected speech

give it a try and use the flag button to report issues which im sure there are a lot since im not a native speak and rules are generated with ai.

thanks !

Hey everyone 👋

I recently finished building PDFForgeLib, a project I started to explore the challenges involved in building a web application around PDF processing.

Tech stack: typescript+next.js + Python/FastAPI + supabase+vercel+render

The project focuses on common PDF operations such as:

• Merging and splitting PDFs
• Compressing PDFs
• Converting files
• Working with different PDF utilities
• Handling file uploads and processing
• Responsive UI for desktop and mobile

Project: [https://pdfforgelib.com/](https://)

One of the things I found interesting while building it was that PDF processing becomes quite different once you start thinking about larger files, processing time, browser limitations, error handling, and keeping the user experience simple.

I'm interested in hearing from developers who have worked with file processing, document systems, or similar web applications.

A few things I'd like to discuss:

• What problems would you expect with this type of architecture as usage grows?
• What are the important security considerations when processing user-uploaded PDFs?
• Would you handle PDF processing primarily on the client or server?
• What performance issues should I be looking out for?
• Are there better approaches for handling large files?
• What functionality would you consider essential in a PDF utility?
• Is there anything about the UX or workflow that feels unnecessarily complicated?

I'm still improving the project, so I'm particularly interested in technical criticism, alternative approaches, and things I may have overlooked.

Would be great to hear how other developers would approach the same problem.

Thanks!

We’ve gone full-Rust with our build pipeline at Outlyne.com and it feels like the React Compiler has really arrived. The last time I posted about using React Compiler here, I talked about how good it’s been for us overall, but also about all its limitations, the biggest of which was that it would bail out on compiling any component or hook that had a try/catch with conditional logic of any kind (if/else, ternary, ??, ||, optional chaining). Another big one was that it would bail on computed object keys, which bit us a few times with assembling classes using clsx (e.g. className={clsx({ [`item-${props.index}`]: props.isItem })}).

Both of those are fixed now. The oxc team shipped official support for the Rust React Compiler on August 4th, and that support includes all of the fixes to the compiler since the v1.0 release of the Babel-based compiler. In our codebase, seven more functions the compiler had been skipping are now compiling, five from the try/catch fix, two from computed keys. And that’s lower than it would be if I hadn’t gone through and contorted eight components to keep conditionals out of their try/catch blocks, including adding a @ts-expect-error from having to drop an optional chain and extracting my auth flow into an async run() that’s immediately awaited inside the try, for no reason but to move the value blocks out of it. All of those workarounds have been rendered obsolete.

There are still bailouts, most notably logical assignment operators (??=, &&=, ||=), but far fewer, and now actively being addressed. A couple weeks ago, oxc shipped a version bump that prevents a bail out from reassigning a destructured prop that then gets read in a nested closure.

Going Rust is also, of course, much faster. The compiler step on our 1,036 files dropped from 14.3s to 0.81s (~17.6×), and the build overall from 22.1s to 9.3s. And we verified parity with the Babel compiler. Across all 1,036 files, there are zero functions the Babel compiler memoizes that the native one doesn’t. The only difference in the built JS before and after are the seven extra compiled functions.

I wrote a blog post with all the details and before/after configs both for folks using @vitejs/plugin-react and for those who use an alternative plugin (React Router framework mode’s plugin in our case): https://blog.master.dev/react-now-rusted-all-the-way-out/

Hi r/reactjs! We just shipped v1 of webmcp-react after quite a few beta versions to work out the kinks. It is MIT licensed and we're hoping to find some more contributors!

What it does AI agents currently have to parse through 1000s of HTML tokens to browse a website. They essentially scrape the DOM and guess where the buttons are. WebMCP is a new web standard that fixes this. It adds document.modelContext to the browser, where a page registers typed tools an agent can call. Chrome shipped it in Early Preview in February, and since companies like Shopify and Codex support it fully. The spec was barebones, and there was no clean React-like way to integrate it into modern UIs, so we made one!

webmcp-react gives you a provider and one hook. The hook registers a tool when the component mounts and removes it on unmount.

```tsx import { WebMCPProvider, useMcpTool } from "webmcp-react"; import { z } from "zod";

function SearchTool() { useMcpTool({ name: "search", description: "Search the catalog", input: z.object({ query: z.string() }), handler: async ({ query }) => ({ content: [{ type: "text", text: Results for: ${query} }], }), }); return null; } ```

It ships with Zod and JSON Schema inputs, a built-in polyfill, SSR support for Next.js and Remix, StrictMode safety, execution state, and cancellation through AbortSignal.

WebMCP is early and we're looking for contributors. Chrome changes the API between releases, and only a few people track it. We are a small team and we don't intend to productize this since we made it mainly to add WebMCP support to our core website. The library works, but a standard needs many hands and many real sites. We'd love any bugs / feedback. If you want to help out with the project please DM me!!

Links:

• Repo: https://github.com/agentcathq/webmcp-react
• Playground: https://agentcathq.github.io/webmcp-react/playground/
• Install: npm install webmcp-react zod

If you're working on a React project and need some avatars for profiles, dashboards, user lists, comments, or mock data, here's a collection that might be useful.

There are 200+ free, open-source UI avatars that you can use in your projects.

There's also a UI Avatar Guide on the page if you want to learn more about using avatars in interfaces.

🔗 https://radianui.com/resources/avatar

Sharing it in case it's useful for anyone working on a React project!

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!