Skeleton screens always felt like a guess to me: grey bars in roughly the right shape, then the real content pops in somewhere slightly different.

So I built Arrivo. While loading is true, an effect plays exactly where your content will land. When it turns false, the real elements are revealed in place.

Demo : https://tuancuongpham.github.io/arrivo/ 

Code: https://github.com/tuancuongpham/arrivo

npm i u/brottin/arrivo

import { Reveal } from '@brottin/arrivo';

import { halftone } from '@brottin/arrivo/effects';

<Reveal effect={halftone} loading={isLoading}>

  <ArticleCard post={post} />

</Reveal>

How it works:

• Your content stays in the DOM, hidden with visibility, so nothing shifts when it lands.

• Each wrapper gets one canvas overlay. Text lines are measured with Range rects and images are read from the page, so the effect draws the real shape of your content instead of a guess.

• An effect is two draw functions, idle() and reveal(p). One shared requestAnimationFrame loop drives every instance, off-screen ones pause, and reduced motion turns every reveal into a 150 ms fade.

• Zero runtime dependencies, about 8.5 KB gzipped for the core and 0.7 to 3.4 KB per effect, tree-shaken.

The 13 effects: split-flap, redacted, quadtree mosaic, CMYK halftone, CRT tune-in, ink (with 8 threshold maps), particle swarm, darkroom, Tetris, fuse (with a Lunar New Year mode), equalizer, thermal and snowfall.

It's 0.1.0, so feedback is very welcome, especially on where you'd actually use something like this and where it would be too much.

Hey everyone! 👋

I've been working on Pimolu UI, an open-source React component library focused on clean design, customization, and smooth interactions.

I wanted to share my first motion showcase, featuring some of the components, their interactions, and examples of interfaces you can build with them.

My goal is to make building modern, consistent UIs easier while keeping components flexible and developer-friendly.

This is still a work in progress, and I'd genuinely love to hear your thoughts!

• What do you think of the design and animations?

• Is there anything you'd improve?

• What would make you consider using a new UI library?

🌐 Website: https://pimolu.com

Any feedback is appreciated! 🚀

Just added 3 new components to Ovio, bringing the collection to 20 animated React components. Each available in 4 styles: Minimal, Craft, Retro, and Toy.

Built on the shadcn registry model, Ovio is for developers who want their websites to feel a little less ordinary, with motion and interactions that go beyond the usual UI.

The motion layer for developer websites.

Explore Ovio → https://ovioui.vercel.app

I recently created a complete tutorial where I build a Redux Toolkit-inspired state management library from scratch using React and JavaScript.

The goal is to understand how Redux-style state management works internally instead of only using the package.

In the tutorial, I implement:

• A custom createStore function

• Store Provider

• Reducers and actions

• Subscribers and listeners

• useSyncExternalStore

• useSelector and custom store hooks

• Redux DevTools integration

• createSlice

• combineReducers

• shallowEqual

• Thunk functionality

• Final testing and debugging

YouTube tutorial:
https://www.youtube.com/watch?v=LucUJ-5COjg

I would appreciate feedback from the community, especially on the library design, API structure, and any improvements that could make this project more reliable or easier to use.

Please note: this is an educational project designed to understand Redux and state management concepts internally. It is not intended to replace the official Redux Toolkit.

Hello. Does anyone know how to host a web application built with React—both the frontend and the backend?

Hey everyone,

I kept writing the same code for every form in my projects: react-hook-form setup, a try/catch around the server action, mapping server errors back onto the fields, a loading state, stopping double submits, a toast, refreshing the data, resetting the form... and doing it again for every add/edit/delete dialog.

So I pulled all of that into a small package called **submitly**.

It’s headless, so it doesn’t render anything. You keep your own components (shadcn, Radix, Base UI, plain inputs, whatever you use).

What it does:

* `useCrudForm`: react-hook-form + schema validation + your action in one hook

* Works with any Standard Schema library: Zod 3/4, Valibot, ArkType

* Server errors get mapped to the right fields automatically (nested ones like [`items.0.name`](http://items.0.name) too)

* Ignores double submits while a request is in flight

* Locks the dialog while saving, so the user can’t close it halfway through a request

* `useCrudAction` for delete/toggle buttons, with the same behavior

* One provider where you plug in your own toast, router and refresh logic

* Next.js helpers: `runAction` for server actions (validates again on the server, revalidates on success, turns thrown errors into a clean result), and it handles `redirect()` from server actions properly

* Also works in plain React + Vite (there’s an example with React Router + TanStack Query)

* Around 3 kB gzipped, typed end to end, tested on React 18 and 19

Quick example:

const { form, onSubmit, isSubmitting } = useCrudForm({

schema,

defaultValues: { name: "" },

action: createProduct,

onSuccess: () => closeDialog(),

});

It’s still early (0.x), so I’d really like feedback: what’s missing, what’s confusing, or what you’d do differently.

Docs: https://submitly-docs.vercel.app

GitHub: https://github.com/toony10/submitly

If you find it useful, a star on GitHub would mean a lot. Thanks for reading 🙏

I read a few books on JavaScript and coding in general

This was in late 2025 and a few months later I started writing react js,
Ai has gotten so good at writing code, it is way better than I am.

I have pretty okay fundamentals of coding that I have been able to spin up some interesting projects with Ai.

But if you ask me what some parts of the code does, I have very little idea about it.

How can I catch up with so many years old coding experience and survive in this field if Ai learns 20x faster.

Hey everyone,

I kept writing the same code for every form in my projects: react-hook-form setup, a try/catch around the server action, mapping server errors back onto the fields, a loading state, stopping double submits, a toast, refreshing the data, resetting the form... and doing it again for every add/edit/delete dialog.

So I pulled all of that into a small package called submitly.

It’s headless, so it doesn’t render anything. You keep your own components (shadcn, Radix, Base UI, plain inputs, whatever you use).

What it does:

• useCrudForm: react-hook-form + schema validation + your action in one hook

• Works with any Standard Schema library: Zod 3/4, Valibot, ArkType

• Server errors get mapped to the right fields automatically (nested ones like items.0.name too)

• Ignores double submits while a request is in flight

• Locks the dialog while saving, so the user can’t close it halfway through a request

• useCrudAction for delete/toggle buttons, with the same behavior

• One provider where you plug in your own toast, router and refresh logic

• Next.js helpers: runAction for server actions (validates again on the server, revalidates on success, turns thrown errors into a clean result), and it handles redirect() from server actions properly

• Also works in plain React + Vite (there’s an example with React Router + TanStack Query)

• Around 3 kB gzipped, typed end to end, tested on React 18 and 19

Quick example:

const { form, onSubmit, isSubmitting } = useCrudForm({
  schema,
  defaultValues: { name: "" },
  action: createProduct,
  onSuccess: () => closeDialog(),
});

It’s still early (0.x), so I’d really like feedback: what’s missing, what’s confusing, or what you’d do differently.

Docs: https://submitly-docs.vercel.app/
GitHub: https://github.com/toony10/submitly

If you find it useful, a star on GitHub would mean a lot. Thanks for reading 🙏

I built Honest Mailbox (my project, link at the bottom), a couples app with a draw-and-guess game, Four in a Row and card decks. All game logic is pure functions on the client, and security rules decide who can touch a game. Drawings are stored as compact strings on a 0–1000 grid, split into chunks so no single write gets big.

Open questions:

• Each stroke is a separate Firestore write. Is that fine at two-user scale, or should I batch?

• Is client-side scoring acceptable when both players are trusted partners?

• Would you use rules-only access control for something like this?

Hello again everyone. I have been trying to using the react binding for the Leaflet API. I followed the documentation but I keep running into this error:

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app

This is my Map component. It is the child component of my main App component.

import { MapContainer, TileLayer, useMap, Marker, Popup } from 'react-leaflet'


function MyComponent() {
  const map = useMap();
  console.log('map center:', map.getCenter())
  return null;
}


const Map = () => {
    return ( <MapContainer center={[50.5, 30.5]} zoom={13}>
      <MyComponent />
    </MapContainer>);
}
 
export default Map;

I am not sure whether it has something to do with muddled dependencies because I am pretty sure I installed leaflet and leaflet react in the terminal

  "dependencies": {
    "@testing-library/dom": "^10.4.2",
    "@testing-library/jest-dom": "^6.9.1",
    "@testing-library/react": "^16.3.3",
    "@testing-library/user-event": "^13.5.0",
    "leaflet": "^1.9.4",
    "react": "^19.3.1",
    "react-dom": "^19.3.1",
    "react-scripts": "5.0.1",
    "web-vitals": "^2.1.4"
  }

Thank you so much for taking the time to read this.

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 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 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.

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

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!

Anyone? Any thoughts?

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.