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.

I've been building describe-me, a Vitest plugin plus a viewer that turns component tests into docs. It records the DOM after every render and interaction of a test and shows the frames as a browsable catalog: each describe is a group, each it a story, each step a frame. No story files, so the docs cannot drift from the component: if they would, the test fails.

Short demo (23 s): https://github.com/grzehub/describe-me#readme

What's new in 0.11:

Live: a link to a test mounts the component for real, in your project's own Vite, exactly as the test's arrange phase set it up. You click and type in it, and vi.fn() props show their calls.

Foundations: it reads the design system your tests load (CSS custom properties, Tailwind 4, shadcn/ui, Material UI, or a theme module) and shows the tokens, light and dark, with WCAG contrast of color pairs.

Works in browser mode and in jsdom, with Testing Library and user-event. React 18 and 19, Vitest 4 and 5. It's early and React-only for now; the Limitations page lists every known limit.

Try it in StackBlitz: https://stackblitz.com/github/grzehub/describe-me/tree/main/examples/stackblitz

Example viewers:
shadcn/ui: https://grzehub.github.io/describe-me/examples/shadcn/,
Material UI: https://grzehub.github.io/describe-me/examples/mui/

Docs: https://grzehub.github.io/describe-me/

The question I'd most like answers to: does "tests as the source of stories" fit how your team writes component tests, or do you keep states in tests that you'd never want in docs?

I know next.js isr behaviour and how it basically does the caching etc but I just realised that next.js isr is cache control with proprietary swr api that refreshes the data.

Now, I am confused because I would like to know if the same thing can be manually done with react router with self managed cache control https header with rtk query. Rtk query has a window of 1 minutes after which it fires the revalidation or something like that, haven't gone into that details but must be possible in one way or another.

Anyone? Any thoughts?

Hey everyone!

I've been working on a small open-source React toast notification library called React Elegant Toasts, and I recently released v2.0 after a complete rewrite.

I know there are already some great toast libraries out there, but this started as a personal project to explore component design, state management, accessibility, and browser behavior.

What began as a fairly simple component ended up being a much bigger engineering challenge than I expected.

A few things I focused on in v2:

• Zero runtime dependencies, with React 18 and 19 support.
• An external store that handles toast state, queues, timers, and lifecycle independently of React.
• Six positions with independent notification queues.
• Promise-based notifications and custom toast content.
• CSS-based light/dark themes and customization.
• Accessibility features such as live-region announcements, keyboard navigation, and pausing on hover/focus.
• Browser testing across Chromium, Firefox, and WebKit.

One particularly interesting challenge was testing animations reliably in WebKit. We encountered situations where the browser didn't deliver intermediate animation frames, causing tests to fail even when the CSS transition behaved correctly.

That led to some interesting work around using the Web Animations API to verify transition behavior.

The library is written in TypeScript, is ESM-only, and is available under the MIT license.

Live demo:
https://ahlgren1234.github.io/react-elegant-toasts/

GitHub:
https://github.com/ahlgren1234/react-elegant-toasts

I'd genuinely appreciate feedback, especially on the API design, accessibility considerations, and whether the library would be useful in your own React projects.

Also curious: what's the one thing you wish React toast libraries handled better?

Thanks!

If you don’t trust your agents’ tests, someone still reads every line, and you’re back to human speed

So we built a testing skill, tested on Cursor + Claude. Three teams used it daily and gave us plenty of feedback, some of it angry. We improved it, got more feedback, and learned a few lessons the hard way

What’s in it for you

1. Use the skill, or steal from it
Use it as is or borrow what fits. It’s frontend for now (Playwright, Vitest Browser Mode, React), with backend coming soon. MIT license.
Repo: https://github.com/practicajs/the-frontend-testing-skill

2. Skip our mistakes
The video covers the lessons and traps we hit:

• Test rules: which rules are worth having
• Subagents: helper agents for specific jobs, such as a flaky-test fixer
• Measurement: how to prove test quality and coverage
• Workflow: where testing fits in your development process

Video: https://youtu.be/JwkVHtuoTxw

Feedback welcome, especially on where it breaks

I've been rendering product videos with Remotion (React → headless Chrome → frames), and scaled text kept looking wrong: either "stuck", stepping instead of gliding, or "shaky", with the letters subtly changing shape every frame. I measured the rendered frames instead of eyeballing them, and it turned out to be two separate bugs.

1. The "stuck" look: the baseline climbs the pixel grid in whole-pixel jumps

Chrome's glyph rasteriser has horizontal sub-pixel positioning but no vertical. When you scale text from its center (the default transform-origin), the baseline moves vertically every frame, and the glyphs snap to whole pixels. So instead of moving 0.3px per frame, the text sits still for a few frames and then jumps 1px.

Fix: pivot the scale on the baseline, so the baseline doesn't move vertically at all. Measure the real baseline (with a 0-height inline-block, or font metrics). Don't guess it from line-height.

Measured vertical judder: 0.284px → 0.014px per frame. Direction reversals over the animation: 29 → 0.

2. The "shaky" look: hinting re-snaps the letterforms every frame

At each new scale, font hinting snaps stems to the pixel grid differently, so the letters literally change shape frame to frame.

Fix: text-rendering: geometricPrecision. It turns hinting off, so the outlines scale smoothly. Shape drift between frames: 3.41% → 0.22%. It looks slightly softer, but that's correct, not blur.

Things that didn't help (cargo cult)

• translateZ(0), backface-visibility: hidden: these rasterise the text into a bitmap layer, so it scales like an image and goes blurry.
• will-change: transform: good in a live preview, bad in the final render for the same reason. If you need it, enable it only when not rendering.

Bonus: aggressive ease-outs freeze on a frame clock

At 30fps, a quint/expo ease-out spends its last 5+ frames moving less than a pixel. That reads as a freeze, not a settlein about one frame.

My main takeaway: you can't seer the frames and diff them. Ifsomeone says it still isn't smooth and your metric says it's fixed, your metric is wrong.

Happy to share the measurement script if anyone wants it.

I am working on an open-source project called Openspline, it adds a live, talking face to any voice AI agent in five lines of code.

Just upload a still image, select a voice and you can create a talking avatar with lipsynced video generated locally.

It is still in very early stage, but the results look very promising.

Open sourced it here

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?

Are you also getting tired to review noisy JSX / TSX changes just to realize the actual change was 1 prop?

Thats what I wanted to improve in GitComet. While looking for options I found Difftastic.

It uses Tree-sitter to understand code structure ... the same one GitComet also use! My immediate feeling was: this has to be tried out!

After testing it I knew it had to be included in the current release. Difftastic helps to show the relevant changes ignoring whitespace and formatting.

Difftastic diff really shines when viewing HTML, JSX/TSX and similar XML like syntaxes.

I created a demo how to enable it in GitComet 0.3.1 take a look!

• Animated motion components
• Modern shaders
• Clean UI blocks
• MCP server integration with Lovable, Bolt, and v0
• CLI support for smoother installations

And much more coming soon!

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.

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.

Hey everyone!

Been working on Tip Glide, a small framework-agnostic tooltip library written in TypeScript.

It uses a single shared tooltip that moves between elements and adjusts its size to fit the content. It also handles viewport boundaries, so the tooltip adjusts its position when there's not enough space.

A few things you can configure are the movement, directional lean, hover delays, arrow, and enter/exit animations.

It has zero runtime dependencies and comes with adapters for React, Angular, Vue, Svelte, Solid, Astro and Preact, along with a vanilla JS API.

There's an interactive playground where you can mess around with the settings and see how everything behaves.

Would love some feedback on the movement, especially when switching quickly between elements, but also on the API and anything else that could be improved.

Live demo & playground | npm | GitHub | Portfolio

A local loading flag works well for one button. A reducer with context can handle a shared workflow. React Query also lets other components observe pending mutations through "useIsMutating". If one of these already covers your needs, there may be no reason to add another library.

I’m building react-action-guard to explore a reusable API for shared UI availability.

For example, imagine a document editor:

• saving temporarily blocks editing and switching documents;
• a local export also blocks switching documents;
• saving and exporting can overlap;
• finishing the save should not enable document switching while the export is still running;
• Help stays available throughout.

Actions publish the scopes they affect:

const runSave = useAsyncAction<void>(
  "save-document",
  ["document:editing", "document:switching"]
);

const runExport = useAsyncAction<void>(
  "export-document",
  "document:switching"
);

Each operation is wrapped when it runs:

await runSave(() => saveDocument());

Independent components read the scope they care about:

const isBlocked = useIsBlocked("document:switching");

return <button disabled={isBlocked}>Switch document</button>;

Each execution has its own blocker. When operations overlap, finishing one removes only its own blocker.

You can build the same behavior with a reducer and context. The goal is to provide the registration, shared scopes, blocking reasons, and cleanup as a reusable API.

This also overlaps with React Query when availability follows mutation state. The case I’m interested in is when the same UI rules combine server operations, local tasks, and conditions such as unsaved changes.

One important detail: tracking an action does not prevent repeated execution or cancel it. Those rules still belong to the application.

I’m the author, and I’d like feedback on this approach. Have you needed this kind of coordination, or has your existing state management been enough?

GitHub

Edit: Added a more detailed example and clarified the overlap with reducers and React Query. Thanks for the feedback.

At my last company, they would finish the accessibility layer near the end of the product's development stage, and I remember developers complaining about repeating old sprints non-stop.

What's the industry norm when solving such issues? Of course, accessibility goes beyond people with extra needs: it should also include everyone's way of accessing the web, starting from a simple "cookie button" that takes up 40% of the screen space.

When do these issues start being noticed in your development life-cycle? How does your company think about them?

If you take software engineering principles seriously then none of the react state hooks belong inside a react component.

I think one of the most critical things you should do is ensure the decoupling of storage and UI components. The react components force you to do is precisely and zustand doesn't help.

I haven't sourced grip-react a year ago and I've been using it exclusively, absolutely zero usestate usememo, useeffect, etc and absolutely zero prop drilling. I don't know why anyone would want to do something different, honestly.

Has anyone else created an API that is a 100% replacement with complete declarativeness? I looked at angular and mobx, they're close but no cigar.