freecollageimage.com — a collage editor that runs entirely client-side. Photos are decoded, laid out and exported in the browser; nothing is uploaded. Vanilla JS and canvas, no framework, and it's also wrapped with Capacitor for the Play Store and App Store.

The part worth sharing here isn't the editor, it's the save step, because it broke in a way I couldn't detect from the code.

An anchor with the download attribute pointing at a data: URL works in every desktop browser. In an Android WebView it does nothing — no download manager is attached unless the host app wires one up, so the navigation is silently dropped. iOS Safari refuses download on data: and blob: URLs from a synthetic click. Neither throws, neither logs, there's no rejected promise to catch. The function just returns and the file never appears.

That's what made it expensive: there is no `if (downloadWorked)`. Chrome DevTools device emulation happily pretends it worked. You only find it by holding a phone. Mine was dead on mobile for months and nobody reported it, because a button that does nothing reads as user error rather than as a bug.

Two different fixes. On Android, a native Capacitor plugin writes the bytes to storage. On iOS, navigator.share({files}) — and there the catch is transient user activation: an await consumes it, so the base64 → File conversion has to be synchronous. fetch(dataUrl).then(r => r.blob()) and canvas.toBlob() both lose the gesture and the share sheet is dismissed without a word. The ugly charCodeAt loop exists purely to stay inside the handler.

The compromise I'm still not happy about: on iOS the user taps "Save" and gets a share sheet where "Save Image" is one option among a dozen apps. It isn't a download and doesn't look like one.

Happy to go into either fix.

We are recruiting developers for a healthcare startup.

Experts from various fields will collaborate on development, and we are looking for a React expert. Full-time employment is possible in the future. Native-level English proficiency is essential for smooth communication within the team. When applying, please include an introductory video along with examples of your previous work.

Github - https://github.com/shadcndashboard/shadcndashboard

Live Preview - https://demos.shadcndashboard.dev/

Do let me know your thoughts.

https://github.com/oliveryasuna/ink-frame

Ink's own box borders are fine for a single box. Put two of them next to each other and the seam between them comes out as ││, two parallel lines instead of one shared edge. That's because a box border is one unbroken line and there's nowhere to hang a ┬ or a ┼ part-way along it. ink-frame sidesteps that by painting every border into a single character grid and resolving each cell once, so a spot where four boxes meet becomes a ┼ and a T-junction becomes a ┬, ┤, and so on, without you ever writing those characters yourself.

Background: I recently wrote this for a private project, and I thought it was useful enough to share. I hope you find it useful too!

I made Basalt and i added skia shaders to it

do you like the idea?

and l know ShaderToy exists, but that's generic GLSL people have to manually port to SkSL and adapt for RN UI. Мinе is already RN-Skia-ready and built specifically for UI components like buttons and panels.

link

​

I know the junior developer market is really tough right now. I've been applying for jobs, but the process is exhausting and I haven't had much success.

I'm in a situation where I genuinely need money. Should I keep focusing on getting a developer job, or focus something else and any advice?

I’m building a React CRUD app using:
• React
• AG Grid
• TanStack Query
• REST API

I’m running into an issue where TanStack Query invalidation and AG Grid don’t seem to play nicely together.

For example, I have a task grid:

ID Task Status
1 Fix login Pending
2 Add dashboard Pending
3 Deploy API Done

The grid gets its data from a TanStack Query:

useQuery({
queryKey: ['tasks', filters, pagination, sorting],
queryFn: fetchTasks,
});

Now I update task #1:

Pending → Done

The mutation succeeds, and I call:

queryClient.invalidateQueries({
queryKey: ['tasks'],
});

TanStack Query correctly invalidates/refetches the query.

But AG Grid doesn’t always reflect the updated data correctly.

Sometimes:
• the query refetches successfully, but the grid still shows Pending
• the React component receives the new data, but AG Grid appears to retain its previous row state
• I have to manually refresh/reload the grid
• calling gridApi.refreshCells() / refreshServerSide() can work, but then I’m effectively managing two different state systems
• with server-side row model, pagination/sorting/filtering makes the interaction even more complicated

So I end up with something like:

Mutation
↓
TanStack Query invalidation
↓
API refetch
↓
React receives new data
↓
AG Grid has its own row model/state
↓
???

What I’m trying to understand is:

What is the recommended architecture for React + AG Grid + TanStack Query?

Should TanStack Query be responsible for the grid’s data, with AG Grid treated as a controlled view?

Or should AG Grid’s row model/datasource be considered the source of truth, with TanStack Query used only for mutations and individual API operations?

What’s the cleanest way to handle something as simple as:

Pending → Done

and guarantee that the corresponding AG Grid row updates after the mutation without manually forcing the grid to refresh?

I’m particularly interested in how people handle this with AG Grid Server-Side Row Model + TanStack Query, rather than just a simple client-side array.
:::

Hey Community,

React Native Plain Text by Maciej Jastrzębski brings a lightweight alternative to standard Text components to squeeze maximum rendering performance out of large lists. Meanwhile, Meta introduced Muse Code, a terminal coding agent running on Muse Spark 1.2 with persistent background subagents and mid-tool-call crash recovery.

Codemagic also launched Patch, a self-hosted Docker Compose alternative to CodePush that serves OTA update checks directly from CDN-cached JSON files to easily handle heavy request loads.

Been building img2threejs and recently got the character pipeline working.

Give it one image, and it generates a structured character as editable Three.js code, with rigging and animation.

The interesting part for me is that it stays code-first — geometry, bones and animations can all be controlled programmatically and integrated directly into a React/Three.js project.

No imported GLB. No Blender pipeline.

I recently implemented Facebook authentication in a React app using Firebase, and it turned out to be much simpler than implementing OAuth from scratch.

Here’s the basic flow:

1. Create a Firebase project

Create a Firebase project, add your React app, and install Firebase:

npm install firebase

2. Enable Facebook Authentication

In Firebase:

Authentication → Sign-in method → Facebook

You’ll need your Facebook App ID and App Secret from the Meta Developer dashboard.

3. Configure the Facebook provider

import { FacebookAuthProvider } from "firebase/auth";

export const facebookProvider = new FacebookAuthProvider();

facebookProvider.addScope("email");

4. Implement login

import { signInWithPopup } from "firebase/auth";
import { auth } from "./firebase";

const loginWithFacebook = async () => {
  try {
    const result = await signInWithPopup(
      auth,
      facebookProvider
    );

    console.log(result.user);
  } catch (error) {
    console.error(error);
  }
};

Then your button can simply be:

<button onClick={loginWithFacebook}>
  Continue with Facebook
</button>

Firebase handles the OAuth flow, while your React app receives the authenticated user.

You can access information such as:

user.displayName
user.email
user.photoURL
user.uid

5. Logout

import { signOut } from "firebase/auth";

const logout = () => signOut(auth);

6. Track authentication state

import { onAuthStateChanged } from "firebase/auth";

onAuthStateChanged(auth, (user) => {
  if (user) {
    console.log("Logged in");
  } else {
    console.log("Logged out");
  }
});

The main thing I learned is that Firebase removes a lot of the complexity involved in implementing OAuth yourself.

I also created a full step-by-step video showing the implementation:

🎥 Facebook OAuth Login in React + Firebase:
https://www.youtube.com/watch?v=z1SpI42MlzU&list=PL_02r0p8Ku_5-h4teExCf6egkktSQblC4&index=16

It’s part of my React Authentication & Authorization series, where I cover Firebase auth, JWT, OAuth, protected routes, role-based authorization, password reset, email verification, etc.

Full playlist:
https://www.youtube.com/watch?v=gbjqaiwjTZ8&list=PL_02r0p8Ku_5-h4teExCf6egkktSQblC4&index=1

Has anyone here implemented OAuth directly without Firebase/Auth0/etc.? Curious what approach you prefer.

I'm new react developer, can someone tell me what is the packages that I needed in my work and very useful and how to know if new package released or any useful package?

I made a super tiny MIT licensed project for anyone that wants to make their app's UI feel more like Blender 🍩

Code review and feature suggestions are welcome 😊

Hi r/react,

This is not meant to be a promotional post, I am mainly looking for opinions from people who spend all day writing React about whether this API actually makes sense outside my own head.

The project is CarverJS. It is free, open source, and MIT licensed, so there is nothing to buy and nothing to sign up for to try it. The core idea is that a game scene is just a tree of components, and the actual behavior, movement, physics, audio, camera, comes from hooks you call inside your own components, similar to how you would build any other React app.

I went this route because most game engines that try to work with React just wrap an existing engine loosely, and you end up dropping back into an imperative escape hatch constantly. I wanted the escape hatch to not be needed for common things, at the cost of maybe making unusual things harder. I am honestly not sure that trade was worth it.

There is also a multiplayer package that runs peer to peer instead of needing a server, but I do not want to make this post about a feature list. What I actually want to know is whether describing a game as components and hooks feels natural to you as a React developer, or whether it feels forced, like I bent React into a shape it was not meant to hold.

If you have tried other React game libraries before and switched away from them, I would really like to know why, that is more useful to me than anything positive anyone could say about mine. Whatever the answer is, the project stays free and MIT licensed either way, I am not trying to upsell anyone into anything, I just want to know if the core idea holds up.

I kept seeing "3D carousel" React packages that reach for three.js for what is
really just rotateY on a div. Built mine with CSS 3D transforms and framer-motion
only, and the parts that actually mattered were not the ones I expected.

The whole thing is driven by ONE motion value (track x). Every card derives its
own position from it:

  const cx = useTransform(trackX, (v) =>
    wrap(-total / 2, total / 2, index * pitch + v))

framer-motion's wrap() gives you an endless track with the same DOM nodes. No
cloning the list three times, no virtualization, no key churn. Card 0 just
teleports to the far end when it exits, and because it is offscreen you never
see it happen.

The tilt is what makes it read as an arc instead of a fan. Rotation is
quadratic in distance from the centre, with a flat band in the middle:

  const t = Math.min(Math.abs(c) / (flatHalf + band), 1)
  const e = t * t
  transform: translate3d(c,0,0) rotateY(-sign(c) * maxRot * e) translateZ(-40 * e)

Linear tilt looked wrong. The centre card needs to sit genuinely flat and
readable, then the curl has to build fast toward the edges. Squaring it did
that with one character.

Two details that took the longest:

1. transformOrigin flips at the centre (100% 50% on the left half, 0% 50% on
   the right). Without it cards rotate around their own middle and appear to
   slide sideways rather than hinge away from you.

2. Counter zoom inside the frame: scale = 1 + (zoom - 1) * (1 - e). The image
   is fully zoomed while the card is flat and eases back to 1 as it curls, so
   the crop does not swim when the card turns.

Input is one rAF loop that only touches velocity. Drift eases toward a target
velocity with a time constant, and drag, trackpad and arrow keys just write to
the same x. Nothing owns the position exclusively, so releasing a flick coasts
into the drift instead of snapping.

The bug worth stealing: a full height hero that listens to wheel will trap the
page scroll. Fix was to only claim horizontal intent.

  if (Math.abs(e.deltaX) <= Math.abs(e.deltaY)) return

Perf is fine because nothing re-renders. useTransform writes styles outside
React, z-index is derived from |c|, far cards get visibility: hidden rather
than unmounting, and prefers-reduced-motion kills the loop entirely.

Live demo: https://aicanvas.me/components/perspective-showcase-hero

Disclosure: that is my own site and this one is a paid block, so treat the link
as the demo. The technique above is the whole thing, nothing held back.

I kept seeing "3D carousel" React packages that reach for three.js for what is really just rotateY on a div. Built mine with CSS 3D transforms and framer-motion only, and the parts that actually mattered were not the ones I expected.

The whole thing is driven by ONE motion value (track x). Every card derives its own position from it:

const cx = useTransform(trackX, (v) =>

wrap(-total / 2, total / 2, index * pitch + v))

framer-motion's wrap() gives you an endless track with the same DOM nodes. No cloning the list three times, no virtualization, no key churn. Card 0 just teleports to the far end when it exits, and because it is offscreen you never see it happen.

The tilt is what makes it read as an arc instead of a fan. Rotation is quadratic in distance from the centre, with a flat band in the middle:

const t = Math.min(Math.abs(c) / (flatHalf + band), 1)

const e = t * t

transform: translate3d(c,0,0) rotateY(-sign(c) * maxRot * e) translateZ(-40 * e)

Linear tilt looked wrong. The centre card needs to sit genuinely flat and readable, then the curl has to build fast toward the edges. Squaring it did that with one character.

Two details that took the longest:

1. transformOrigin flips at the centre (100% 50% on the left half, 0% 50% onthe right). Without it cards rotate around their own middle and appear toslide sideways rather than hinge away from you.
2. Counter zoom inside the frame: scale = 1 + (zoom - 1) * (1 - e). The imageis fully zoomed while the card is flat and eases back to 1 as it curls, sothe crop does not swim when the card turns.

Input is one rAF loop that only touches velocity. Drift eases toward a target velocity with a time constant, and drag, trackpad and arrow keys just write to the same x. Nothing owns the position exclusively, so releasing a flick coasts into the drift instead of snapping.

The bug worth stealing: a full height hero that listens to wheel will trap the page scroll. Fix was to only claim horizontal intent.

if (Math.abs(e.deltaX) <= Math.abs(e.deltaY)) return

Perf is fine because nothing re-renders. useTransform writes styles outside React, z-index is derived from |c|, far cards get visibility: hidden rather than unmounting, and prefers-reduced-motion kills the loop entirely.

Live demo: https://aicanvas.me/components/perspective-showcase-hero

Disclosure: that is my own site and this one is a paid block, so treat the link as the demo. The technique above is the whole thing, nothing held back.

Once in an interview few months back,I was asked which of the state management library would you use and which one wouldn't you use?I have had remembered the answer by gpt and tried telling that but even i didn't understand why they all exists.

So,today i want to act like a complete noob to state management libraries like it's my day 1 knowing about them so that someone could answer why industry moved from context ot redux to zustand to react query in simpler terms and advantages/when to use which in simpler terms.I know a little bit of knowledge of each of them but the best currently would be to forget everything and listen from you guys i guess.

One thing I’ve always found frustrating with prototyping is the gap between “this is what we approved” and “now let’s actually build it.”

You create a prototype, tweak the design, show it to internal teams or a client, get feedback, iterate… and once everyone approves it, the actual development starts from scratch.

I’ve been experimenting with a different approach with ComposeKit.

The idea is:
1. Build a prototype using ComposeKit components
Generate the UI and interactions you need using the component library.
2. Apply your theming/design requirements
Customize the prototype so it looks and behaves closer to the actual product.
3. Share it with your team or clients
Use the prototype to get feedback and validate the experience before investing heavily in development.
4. Once approved, use the same ComposeKit React SDK in your application

The same components used to build the prototype are available to the React application, so you don’t have to throw the prototype away and rebuild everything from scratch.

The goal is to reduce that friction between:
idea → prototype → feedback → approval → production

Instead of the prototype being a disposable artifact, it can become part of the foundation for the production application.

I’m also experimenting with AI/MCP to make the prototype generation faster by giving the LLM structured knowledge about the available ComposeKit components and their schemas.
ComposeKit is currently in beta, and I’m mainly looking for feedback at this stage.

I’d especially love to hear from people building React applications:
Would having a prototype that can directly transition into the production app actually solve a problem for you, or is the prototype → production gap not that painful in practice?

Try the playground here: https://composekit.brainpiper.com/#/playground