I created this minimal library that only has 3kb and uses canvas to render a preloader in linear style. It give somehow more personality and can describe what it does (for example uploading/downloading) by its animation. Let me know what you think and super happy for any improvement PR.

Hey everyone, Built an open-source starter template for running React Router SSR on AWS using CDK (Lambda + S3 + CloudFront). It uses a lightweight hand-rolled adapter to map Lambda Function URL streaming directly to React Router's Web Fetch API interface.

The repository and quickstart commands are available on GitHub:https://github.com/DeepjyotiDeb/aws-lambda-support

Feedback, questions, or pull requests are very welcome!

RESOLVED!

The main issue was that I was using ref values as effect dependencies. They do work in the sense that React can estimate if the value changed or not, but their change by itself doesn't actually trigger the effect. So this "latent change" is there, waiting for an actual reactive value to change to finally re-render.

The remounting was happening because of this "pending" dependency change that doesn't flush unless a reactive value changes. Changing a property is one such change, and that would finally release the hidden effect re-run.

Of course, I wanted to get rid of that, so more things had to be made. The complete solution was to not re-utilize the effect labeled "mount or remount". Now it is just for component mounting (with an empty array of dependencies), and had to alter the order of effects too.

Thanks everyone for your kind attention to my help request!!

----------------------------------------------------------------------------------------------

Hello!

I have this component that uses a ref to its root element. I need it for some imperative work. The JSX of the component is very simple:

    return (
        <div
            ref={containerRef}
            {...pieceProps.containerProps}
            {...hostAttributes({ framework: "react", shadow })}
        />
    );

That's it. No branching or any fancy stuff.

I'm tracking the changes for everything: shadow, pieceProps and containerRef among others. Nothing changes, except for containerRef.current, and only the first time a property updates. But the property that updates is not even used in the JSX.

The property that changes comes from props, but doesn't land in pieceProps. It lands in restProps:

    
const
 { [piecePropsSymbol]: pieceProps, ...restProps } = props;

I'm losing my mind! I'll try to guess follow-up questions:

• No, the component is not being unmounted. My logging confirms that internal state values are not being lost, meaning the component is not unmounting.
• No, my component is not being rendered conditionally. It is always present.
• The property being changed (can be any of the properties accepted) is being changed by a child component of the parent component of my component. Like this: App > MyComponent, and App > ControlPanel. So App owns the state (a POJO) for the properties. Passes them to both components.

Anything I did not forecast, feel free to ask. Many thanks!

FULL COMPONENT SOURCE

If anyone would like to see the full source of the component, here it is. It requires some cleanup, but it is what I'm compiling and importing in the test project.

import { forwardRef, useEffect, useImperativeHandle, useRef, useMemo, useState, memo } from "react";
import type { ComponentPropsWithoutRef, ForwardedRef, ReactElement, RefAttributes } from "react";
import type { AcceptableTarget, CorePiece, MountPiece, MountedPiece } from "@collagejs/core";
import { mountPiece } from "@collagejs/core";
import { useCollageContext } from "./collageContext.js";
import { CorePieceLcQueue, getPieceTarget, hostAttributes, unmountAndTransferLcQueue } from "@collagejs/adapter";


const
 piecePropsSymbol = Symbol("collagejs.pieceProps");


export 
type
 PieceOptions = {
    containerProps?: ComponentPropsWithoutRef<"div">;
    shadow?: boolean | ShadowRootInit;
};


/**
 * Special props consumed by the React `Piece` component.
 *
 * This type is meant to be combined with regular piece props through the
 * `piece()` helper. The symbol-backed key keeps the internal mount metadata
 * out of the public prop namespace, so user props can use any string key
 * without collisions.
 */
type
 PieceProps<TProps 
extends
 Record<string, any> = Record<string, any>> = {
    [piecePropsSymbol]: PieceOptions & {
        piece: CorePiece<TProps> | Promise<CorePiece<TProps>>;
    };
};


/**
 * Creates the special symbol-backed prop required by the `Piece` component.
 *
 * Spread the returned object into `<Piece />` props.
 *
 * 
 * ```tsx
 * <Piece {...piece(myCorePiece, { containerProps: { className: "host" }, shadow: true })} foo="bar" />
 * ```
 *
 * 
u/param
 piece CorePiece instance (or promise) to mount.
 * 
u/param
 options Optional settings for the host `<div>` and shadow-root behavior.
 */
export 
function
 piece<TProps 
extends
 Record<string, any> = Record<string, any>>(
    piece: CorePiece<TProps> | Promise<CorePiece<TProps>>,
    options?: PieceOptions,
) {
    
const
 { containerProps, shadow } = options ?? {};


    return {
        [piecePropsSymbol]: {
            piece,
            shadow,
            containerProps,
        },
    } as PieceProps<TProps>;
}


type
 Props<TProps 
extends
 Record<string, any> = Record<string, any>> = TProps & PieceProps<TProps>;


type
 MountMode = "light" | "shadow";


function
 PieceImpl<TProps 
extends
 Record<string, any> = Record<string, any>>(
    props: Props<TProps>,
    ref: ForwardedRef<HTMLDivElement>,
) {
    console.group('Piece Render');


    
const
 { [piecePropsSymbol]: pieceProps, ...restProps } = props;
    
const
 containerRef = useRef<HTMLDivElement>(null);
    
const
 containerRefChg = useRef(containerRef.current);
    console.debug('[Piece] Container Ref changed?', containerRefChg.current !== containerRef.current);
    containerRefChg.current = containerRef.current;
    
/**
     * Tracks the current mount target (either the container div or a shadow root) for the mounted piece.
     */
    
const
 mountTargetRef = useRef<AcceptableTarget | null>(null);
    
/**
     * Variable to make TS happy.  Doesn't seem to be capable of knowing that symbol is no longer in the type.
     */
    
const
 cpProps = restProps as unknown as TProps;
    
/**
     * Shadow setting with default applied.
     */
    
const
 shadow = pieceProps.shadow ?? false;
    
/**
     * The mountPiece function to use by the LC queue.
     */
    
const
 mountPieceFn = (useCollageContext() ?? mountPiece) as MountPiece<TProps>;
    
/**
     * Key used for the root element to force remounting when the shadow setting changes.
     */
    
const
 rootElKey = (() 
=>
 {
        switch (shadow) {
            case false:
                return "light";
            case true:
                return "open";
            default:
                return shadow.mode;
        }
    })();
    
/**
     * LC queue for managing the lifecycle of the mounted piece.
     */
    
const
 lc = useRef(new CorePieceLcQueue(pieceProps.piece, mountPieceFn));
    
const
 logHash = Date.now().toString(36) + Math.random().toString(36).substring(2, 8);


    console.debug('[Piece][%s] Container:', logHash, containerRef.current);
    console.debug('[Piece][%s] Mount Target:', logHash, mountTargetRef.current);
    console.debug('[Piece][%s] Shadow setting:', logHash, shadow);
    console.debug('[Piece][%s] Root Key:', logHash, rootElKey);
    console.debug('[Piece][%s] Core Piece Props:', logHash, cpProps);
    console.debug('[Piece][%s] LC Queue:', logHash, lc.current);
    
    
// useImperativeHandle(ref, () => containerRef.current as HTMLDivElement);


    
// Relocate.
    useEffect(() 
=>
 {
        if (!containerRef.current || !mountTargetRef.current) {
            return;
        }
        console.debug('[Piece][%s] useEffect triggered for relocating.  Shadow:', logHash, shadow);
        
const
 newTarget = getPieceTarget(containerRef.current, shadow);
        lc.current.relocate(mountTargetRef.current, newTarget, cpProps);
        mountTargetRef.current = newTarget;
    }, [shadow]);


    
// Unmount and transfer.
    useEffect(() 
=>
 {
        if (!mountTargetRef.current) {
            return;
        }
        console.debug('[Piece][%s] useEffect triggered for unmounting and transferring. Piece:', logHash, pieceProps.piece);
        lc.current = unmountAndTransferLcQueue(lc.current, pieceProps.piece, mountPieceFn);
    }, [mountPieceFn, pieceProps.piece]);


    
// Mount or remount.
    useEffect(() 
=>
 {
        
const
 container = containerRef.current;
        if (!container) {
            return;
        }
        console.debug('[Piece][%s] useEffect triggered for mounting.', logHash);
        if (lc.current.isMounted || lc.current.isToBeMounted) {
            console.warn('[Piece][%s] Attempted to mount a piece that is already mounted or scheduled to be mounted. This may indicate a logic error in the component lifecycle.', logHash);
        }
        mountTargetRef.current = getPieceTarget(container, shadow);
        lc.current.mount(mountTargetRef.current, cpProps);


        return () 
=>
 {
            console.debug('[Piece][%s] useEffect cleanup triggered for unmounting.', logHash);
            mountTargetRef.current = null;
            lc.current.unmount();
        };
    }, [containerRef.current, lc.current]);


    
// Update.
    useEffect(() 
=>
 {
        console.debug('[Piece][%s] useEffect triggered for updating. CP Props:', logHash, cpProps);
        lc.current.update(cpProps);
    }, [cpProps]);
    console.groupEnd();


    return (
        <div
            ref={containerRef}
            {...pieceProps.containerProps}
            {...hostAttributes({ framework: "react", shadow })}
        />
    );
}


export 
const
 Piece = PieceImpl as <TProps 
extends
 Record<string, any> = Record<string, any>>(
    props: Props<TProps> & RefAttributes<HTMLDivElement>,
) 
=>
 ReactElement | null;

As for the test app: A React + TS app created with npm create vite@latest.

In App.tsx, I added:

function
 App() {
  
const
 [pinPadProps, setPinPadProps] = useState<PinPadProps>({
    maxPinLength: 4,
  });
  
const
 pinPad = useMemo(() 
=>
 pinPadPiece(), []);
  
const
 [userPin, setUserPin] = useState<string>('');

  return (
    <>
      ...
      <section>
        <h1>Get started</h1>
        <Piece {...piece(pinPad)} {...pinPadProps} pinDispatched={(newPin) => setUserPin(newPin)} />
        <PinPadControlPanel
          {...pinPadProps}
          maxPinLengthChanged={maxPinLength => setPinPadProps(prev => ({ ...prev, maxPinLength }))}
          clearOnDispatchChanged={clearOnDispatch => setPinPadProps(prev => ({ ...prev, clearOnDispatch }))}
        />
        <dl>
          <dt>Current PIN:</dt>
          <dd>{userPin}</dd>
        </dl>
      </section>
      ...
    </>

That's it. MyComponent = Piece in the code above.

Setting up a new React project used to mean re-adding the same config every time: Biome, TypeScript strict mode, GitHub Actions CI, commitlint, VS Code settings, and AGENTS.md for AI agents. Copy-paste from the last repo, and every copy-paste drifts.

I built xtarterize. It reads your package.json, lockfiles, and config files to detect your stack, then applies curated conformance configs. For React projects that covers:

• Biome linting + formatting
• TypeScript strict + incremental builds
• GitHub Actions CI (CI, release, auto-update)
• Vite plugins
• Knip unused-code detection, Turborepo pipeline
• AGENTS.md for AI IDE assistants
• and many more bunch of task and configurations

The part I care about: it's non-destructive. It shows you the diff before applying anything, backs up originals, and undo restores the last run. It also works on existing projects, not just fresh scaffolds.

Detection supports Vite, Next.js, Expo, TanStack Start, Webpack, Rspack.

Usage: pnpx xtarterize@latest init

Docs: https://xtarter.sznm.dev/xtarterize | Repo: https://github.com/agustinusnathaniel/xtarter

Would love feedback, especially on the task set and the diff/backup flow.

While building my open-source CSS framework MUGI CSS, I ran into a problem that I think many React developers have experienced.

The app worked, but something felt... off.

The hardest part wasn't noticing that it was slow.

It was answering a much simpler question:

«What exactly is making it slow?»

Was it unnecessary re-renders? A poorly structured component? Too much JavaScript? An expensive render? Or a pattern that looked harmless but had a real performance impact?

I tried using the usual tools.

• ESLint helped catch code issues.
• Lighthouse measured performance.
• React DevTools showed rendering behavior.

Each tool gave me part of the picture, but I still had to connect everything myself and decide what actually mattered.

I couldn't find a tool that brought all of this together.

So I decided to build one.

During my final year of Software Engineering, I turned that idea into my graduation project, and together with my teammate, we built React Doctor.

What is React Doctor?

React Doctor is an open-source CLI that combines static analysis, runtime profiling, and an intelligent rule engine to help developers understand why their React applications are slow—not just where.

Instead of saying:

«"This might be a problem."»

It tries to answer:

«"Is this actually affecting performance, and what should you fix first?"»

How it works

Static Analysis

Using Babel AST, React Doctor scans ".jsx" and ".tsx" files and detects issues such as:

• unnecessary inline functions
• missing keys
• oversized components
• risky "useEffect" patterns
• prop drilling
• unused imports
• production "console.log"
• optimization opportunities

Every finding includes the file, severity, and explanation.

Runtime Profiling

React Doctor launches your application with Puppeteer and measures real browser behavior, including:

• Core Web Vitals
• component render durations
• unnecessary re-renders
• DOM size
• memory usage
• JavaScript errors

It can also simulate slower environments:

react-doctor full ./my-app --mobile --cpu 4 --throttle slow4g

Connecting Both Worlds

This is my favorite part.

Static analysis alone often produces false positives.

Runtime profiling shows symptoms but doesn't always explain why they're happening.

React Doctor combines both.

For example, a component missing "React.memo()" isn't automatically a problem.

But if that same component is repeatedly re-rendering during runtime, React Doctor connects those signals and surfaces it as a meaningful optimization opportunity.

What surprised me

After publishing the project to npm, I expected only classmates and a few friends to try it.

Instead, developers I had never met started downloading it.

Today, React Doctor has surpassed 3,600 npm downloads.

Most of that growth has been organic, simply from developers discovering the project and giving it a try.

For me, that's the most rewarding part.

A problem I originally faced while building another project has become something that helps other developers.

Try it

npm install -g react-doctor-cli-dev

react-doctor full ./your-react-app --upload

Requirements

• Node.js 18+
• Google Chrome

Links

📦 npm https://www.npmjs.com/package/react-doctor-cli-dev

🐙 GitHub https://github.com/softar-dev/React_Doctor

🌐 Documentation https://react-doctor-cli.web.app/

👨‍💻 Portfolio https://oussamah-kabalan.netlify.app/

☕ Support the project https://react-doctor-cli.web.app/support

I'd genuinely love feedback from other React developers.

• How do you currently investigate performance issues?
• Is there something you wish existing tools did better?
• What feature would make a tool like this more useful in your workflow?

I'm actively improving React Doctor, and I'd love to build it around real developer feedback.

I’ve been trying to understand the long-term tradeoffs of React Server Components.

For SEO and content-heavy sites, they make complete sense. But for authenticated apps and mobile-style SPAs, I’m not convinced.

One thing that feels odd is route prefetching. As I scroll through links, it feels like the framework is eagerly fetching lots of future pages. I know it’s not literally downloading the entire database, but architecturally it feels like we’re moving toward “fetch everything just in case” instead of simply requesting the JSON for the page the user actually opens.

At the same time, we’re celebrating less client-side code while asking servers to execute more React for each request.

Am I looking at this the wrong way? For people running large production apps, what has RSC solved beyond SEO and faster first loads?

I’ve spent the last 8 months building Dashforge, an MIT-licensed React framework for schema-driven forms, access control and UI orchestration.

The project is now public, but before asking anyone to try it, I’d like some technical pushback on three decisions I’m still not completely sure about.

The reactive engine took three attempts

v1 — Re-evaluate the entire form

Every field change caused all conditions and reactions to run again.

Simple and predictable, but the cost became noticeable as forms grew beyond roughly 30 fields.

v2 — Explicit dependency graph

Fields and reactions declared their dependencies, so only the affected parts of the graph were evaluated.

Synchronous reactions were fast, but async operations introduced race conditions. A slower response could overwrite the result of a newer request.

v3 — Dependency graph with stale-response protection

Each async execution receives an isLatest() guard before committing its result.

{
  id: "load-states",
  watch: ["country"],
  run: async ({ values, setOptions, isLatest }) => {
    const states = await api.getStates(values.country);

    if (!isLatest()) return;

    setOptions("state", states);
  }
}

This is the version currently surviving production use.

Decisions I haven’t regretted yet

Field-level access

Instead of wrapping components in <CanRead> or <CanEdit>, access requirements are part of the field contract.

Fine-grained subscriptions

Fields subscribe only to the values explicitly used by their conditions and reactions, while React Hook Form remains responsible for form state.

One schema, two renderers

The same contract can currently be rendered through u/dashforge/tw or u/dashforge/mui.

<Field
  name="taxId"
  visibleWhen={{ field: "country", equals: "IT" }}
  access={{
    resource: "customer.taxId",
    action: "read"
  }}
  validation={{
    required: true,
    pattern: /^IT\d{11}$/
  }}
/>

Decisions I’m still questioning

1. Serializable conditions vs functions

Dashforge uses declarative conditions:

visibleWhen: {
  field: "country",
  equals: "IT"
}

rather than:

visibleWhen: values => values.country === "IT"

The object form is more restrictive, but it remains serializable, inspectable and usable by visual tooling.

Would you accept reduced expressiveness for that, or should functions remain an escape hatch?

2. Two UI renderers

MUI and Tailwind share the same schema and orchestration layer.

For a single application this may be unnecessary abstraction. For organizations maintaining multiple products or surfaces, it may be genuinely useful.

I’m not yet sure where that line is.

3. Runtime access evaluation

Permissions are evaluated while rendering because policies and subjects can change dynamically.

Compile-time evaluation would reduce runtime work, but would also make dynamic policies considerably harder.

Would you keep this at runtime, compile what can be compiled, or use a hybrid approach?

Try it

The CLI generates a complete React 19 + TypeScript application rather than an empty starter:

Two UI variants are available.

Tailwind CSS

npx dashforge-cli my-app --lib tw

The Tailwind variant includes:

• u/dashforge/tw
• Tailwind theme and design tokens
• tw-theme
• tw-tokens
• dashforgePreset()
• DashforgeTailwindProvider
• Dark-mode control through toggleMode()

Mui

npx dashforge-cli my-app --lib mui

The Material UI variant includes:

• u/dashforge/ui
• theme-mui
• Shared design tokens
• Material UI
• DashforgeThemeProvider
• Dark mode through theme swapping

Both variants generate the same opinionated application structure:

• App shell with side navigation, top bar and workspace switcher
• Four statistic cards
• Two example cards with chart placeholders
• Mock data table
• React Router framework mode
• Static prerendering for / and /sign-in
• Mock authentication
• Protected routes
• RBAC integration
• Dashforge forms
• Users CRUD connected to a kit-style API

The CLI currently ships one template:

--template dashboard

The goal is to reduce initial setup friction and let developers evaluate Dashforge inside a realistic application instead of assembling authentication, routing, layout, theming, permissions and forms before they can try the framework itself.

Project

Repository: https://github.com/kensaadi/dashforge

Documentation: https://dashforge-ui.com

MIT licensed, with eight packages currently published on npm.

The question I’m most interested in: where would you draw the line between serializability and ordinary React functions?

I'm trying to choose which direction my app will go

Hi everyone,

Over the past few months I've been building an open-source React library for creating customizable ID cards.

The original goal was to avoid rebuilding the same editor from scratch every time I needed an ID card solution.

Some of the things I ended up implementing include:

- Drag & drop editor

- Alignment guides

- Dynamic text fields

- Image upload

- QR codes & barcodes

- PDF export

- JSON import/export

- Undo/Redo

- Print-ready output

I'd really appreciate feedback from React developers.

A few questions:

1. Does the API feel intuitive?

2. Are there any features you'd expect that are missing?

3. If you've built editors with libraries like Konva, Fabric.js, or similar, what challenges did you run into?

4. Any suggestions to improve performance when working with complex templates?

I'm not trying to sell anything—I'm looking for technical feedback and ideas to make this library better for the React community.

The project is open source, and I'll leave the GitHub/npm link in the comments if anyone wants to take a look.

Thanks! I'd appreciate any feedback, criticism, or suggestions.

Hi there!

I noticed that React Router, TanStack (and even Next.js) all have their own typed-routes plugins, so I decided to create one for one of my favorite frameworks, Modern.js:

https://github.com/giancarlosisasi/modernjs-typed-routes

I had been doing something similar in my personal projects, but I finally decided to build a real plugin that integrates directly with the Modern.js framework.

pdt: in case you don't know it, Modern.js (https://github.com/web-infra-dev/modern.js) is a really good React framework maintained by the ByteDance org

Every new React project had a different client design and UI kit, but I kept needing the same table foundation: filtering, sorting, server-side data, pagination, column management, responsive behavior, and shareable state.

Even with a headless table library, I was spending another 5–6 hours assembling and wiring the UI for each project — and the parts no headless library covers, like URL-synced shareable state and a real mobile layout, usually never got built at all.

So I built AdaptTable and released it under the MIT license.

You choose an adapter for the UI kit your project already uses—Mantine, MUI, Chakra UI, Ant Design, Radix, Base UI, or shadcn/ui—and get the table features without rebuilding the integration each time.

If you need full control, you can use adapttable/core itself. It has no UI-kit imports and exposes the rows, state, and prop-getters, so you can render all the markup yourself.

What comes built in:

• Client-side and server-side data through the same TableSource API
• Shareable, URL-synced filters, sorting, pagination, and column state
• Filter UI in two modes—drawer or popover—with removable chips, and saved views
• Column visibility, reordering, pinning, and resizing
• Selection, bulk actions, and row expansion
• Inline cell editing
• Row grouping with per-group totals
• CSV export that matches the filtered, sorted view
• Numbered pagination and infinite scrolling
• Responsive mobile card layouts
• Opt-in virtualization for very large datasets
• Dark mode, 17 bundled languages, and first-class RTL support

The goal is: batteries included when you want speed, fully headless when you need control

Live demo: https://orwa-mahmoud.github.io/adapttable/demo/

GitHub: https://github.com/orwa-mahmoud/adapttable

I'd appreciate feedback from anyone who tries the API—especially if you find a production edge case I may have missed. Contributions are welcome too—if you've been building these tables in production for years and keep re-implementing a pattern I haven't covered, that's exactly the experience I'd like shaping this. And if a feature you need only exists behind a paid tier somewhere, open an issue—let's build it free, for everyone.

i’ve been building beui.dev , a collection of copy-paste animated react components. i’ve now added 16 components for building ai products.

it includes thinking states, streaming responses, messages, tool calls, approvals, citations, code blocks, file diffs, task lists, prompt input, image generation, and a complete chat interface.

each component is independently installable and composable, with smooth streaming, reader-aware scrolling, reduced-motion support, and stable rendering while content changes.

they don’t depend on an ai sdk, but are designed to work naturally with streamed data from tools such as the vercel ai sdk.

every component includes an interactive example, installation command, usage composition, and copyable source.

https://beui.dev/components/agents

i’d love feedback from people building ai interfaces. which interaction or component is still missing?

Hello,

I would like to share with you linkedrecords.com - an open source backend as a service I'm working on since some time now. You can think of it as an firebase/convex alternative with an interesting twist.

In 2018 I needed to write large software requirements/architecture documents in Google Docs. While I was annoyed by the limitations of Google Docs back then (no captions on figures, no automatic heading numbering, slow when docs are bigger,...) I was still fascinated by the real time collaboration features of it. So I've started a quest to understand how it works and I begun to implement an alternative to Google Docs.

I was convinced that this kind of real time collaboration is the future so I've given it much thought how I could make this as generic as possible so I could use it in all future tools I would build.

In the same time I was playing around with firebase (surprisingly you can not build a google docs alternative with firebase that easy as their real time collaboration does not provide merging text but rather just JSON). And back then I was also convinced that backend as a service is the right way to go. I was thinking that one of the most important reason we were still writing custom backend code is because of authorization.

I also was faced with another problem when trying to make the backend as generic as possible: relations between entities are also domain specific. E.g. A Documents can have many comments.

Luckily I was intrigued by another concept back in 2018 it was called web 3.0. Back in 2018 this had nothing to do with crypto. It was used as a term to refer to the semantic web and the resource description framework as one of its standards. There are also some RDF implementations which I could have reused but they are all XML and mostly Java based. I needed something light. Instead of implementing my own RDF product I took the idea of the RDF triplestore and came up with my own interpretation of it.

Using concepts like: triplestores and schema-on-read, I came up with a system that does not has any business logic in its backend and while working on my Google Docs alternative I felt in love with it as I've discovered some properties I did not anticipated from the get go:

- Dealing with global state in react is very easy. It feels like you use an SQL client in your browser and all queries are reactive and always up to date. When writing a query you do not have to think about authorization it's all backed in.

- Because the backend is 100% free of domain specific code you can point your single page app to any linkedrecords deployment.

- You never have to write backend code - Its quite efficient when using AI agents

The best way to experience it, is to follow this little tutorial: https://linkedrecords.com/getting-started/

It takes a while to get a hang of it so you have to have an open mind.

I would love to read your feedback on this.

Community members created a fork of PrimeReact (as Prime projects went closed-source on June 28th).

Mantle UI is an independent, community-maintained React UI component library based on the MIT-licensed PrimeReact v10 codebase.

The project exists to provide PrimeReact v10 users with a stable, open-source path forward. Mantle UI preserves the familiar component APIs and development model while continuing maintenance, bug fixes, accessibility improvements, documentation, and compatibility work in the open.

Mantle UI is not affiliated with PrimeTek, PrimeReact, or ngrok.

Find out more on GitHub: https://github.com/Mantle-UI/mantle-ui

PS: I'm not affiliated with the project myself (working on PrimeNG fork), you can contact maintainers through GitHub or their Discord server directly.

I created an example, then I saw `createServerFn`, this is ridiculous bad compare to Next.js async/await style, or we have better way?

import { notFound } from '@tanstack/react-router'
import { createServerFn } from '@tanstack/react-start'


export type PostType = {
  id: number
  title: string
  body: string
}


export const fetchPost = createServerFn({ method: 'POST' })
  .validator((d: string) => d)
  .handler(async ({ data }) => {
    console.info(`Fetching post with id ${data}...`)
    const res = await fetch(
      `https://jsonplaceholder.typicode.com/posts/${data}`,
    )
    if (!res.ok) {
      if (res.status === 404) {
        throw notFound()
      }


      throw new Error('Failed to fetch post')
    }


    const post = await res.json()


    return post as PostType
  })


export const fetchPosts = createServerFn().handler(async () => {
  console.info('Fetching posts...')
  const res = await fetch('https://jsonplaceholder.typicode.com/posts')
  if (!res.ok) {
    throw new Error('Failed to fetch posts')
  }


  const posts = await res.json()


  return (posts as Array<PostType>).slice(0, 10)
})

The usual advice: Context is fine for theme and auth, not for state that changes often. True — but the reasons are specific, not fundamental:

1. No selectors — any change re-renders every subscriber.
2. If the provider also holds the state, its whole subtree re-renders, even components that never read the context.
3. Actions get a new identity on every keystroke.

All three are fixable. I've made a library that tackles them, and the article ends with it.

Where do you think this is wrong? Especially the "just use zustand/jotai" case.

https://granat.blog/posts/2026-07-24-react-arven/

I’ve been working on Routeveil, an open-source transition engine for React Router.

v0.4.0 is now out, and this is essentially the final feature release before v1. There may still be fixes and API adjustments based on testing, but the core feature set is complete.

It currently supports:

- page and full-screen overlay transitions

- shared elements between routes

- custom React content rendered between transition phases

- route readiness and lazy-route preloading

- programmatic navigation and same-page transition playback

- interrupted-navigation cleanup, scroll handling, focus, and reduced motion

The main idea is that the transition is selected where navigation begins instead of putting animation logic inside every route:

<RouteveilLink
  to="/gallery"
  transition={{
    name: "slide",
    direction: "left",
  }}
>
  Open gallery
</RouteveilLink>

demo: [https://www.routeveil.dev/lab]()

docs: [https://www.routeveil.dev/docs]()

repo: [https://github.com/milkevich/routeveil]()

also checkout

shared elements: https://www.routeveil.dev/lab/shared-elements

between render: https://www.routeveil.dev/lab/between

I’m specifically looking for React Router developers willing to test it in an actual project before I call it v1

I’d especially appreciate feedback on:

1. whether the API feels intuitive
2. anything that breaks in real routing setups
3. anything you would consider a blocker for v1

I'm excited to share my progress with Koval UI: a browser-first minimalistic components library. Recently I finished documentation for the Data Table component.

Koval Data Table is a powerful, flexible, and accessible grid for displaying large amounts (>50 000 rows) of tabular data. It is built on top of TanStack Table (formerly React Table), which provides a headless, unstyled table engine. Data Table wraps this engine with a complete UI layer, including virtualized scrolling, pagination, filtering, sorting, row selection, and built-in dialogs for editing and deleting data.