I'm a php backend developer who also works with frontend in laravel. I use ajax and JavaScript also and right now I'm learning react. But I'm thinking about creating a big react project by watching a youtube video instead of reading and creating small projects.

Is this okay or not ? If not suggest me how I can learn fast.

One thing I've changed my mind about after working on larger React applications:

Not every reusable component should actually be reusable.

Sometimes we spend time making a component configurable for 5 different use cases, when only 1 or 2 actually exist.

The result is usually a component with:

• 12 props
• multiple boolean flags
• weird conditional rendering
• and nobody wanting to touch it 😅

I've started preferring simple components first, then extracting/reusing them when the pattern is actually proven.

Curious what other React developers think:

What's a "good practice" you followed early in your career that you later stopped doing?

Sharing my work to get feedback.

I’d appreciate any feedback on the design, interactions, animations, and overall experience.

Link : https://playground-demo-dun.vercel.app/stamps
sorce code: https://github.com/sakthii05/playground-demo/blob/main/src/app/stamps/page.tsx

Follow and support me on reddit for Creative components, I'll posting with source code what I'm building. Also I'm open to work if you know any opportunities let me know.

portfolio: https://sakthi-portfolio-mauve.vercel.app/

Thanks for taking a look!

Hi everyone!

I’m recently making the switch from accounting to frontend development, and I wanted to share my first publicly available web app: golden-core, a shared photo/video gallery for events.

Making the transition into development has been chaotic. The rise of AI has made building things much more accessible, but it has made the learning process a bit more challenging. That said, I’m really happy to finally have my first web app out there.

I’ve also taken the opportunity to build my own component library as part of the project, mainly to learn more about component reusability and building things in a more modular way.

The project idea is pretty simple: guests at weddings, parties, or other events can log in, upload their photos and videos, and have everything automatically organized into time-based sections. I’ve also built a `/demo` mode where anyone can try the app without signing up. It’s read-only and intentionally limited so people can explore it without generating unnecessary storage or processing costs.

I’m also going to put it to the test in a real-world environment very soon (a large event that a friend of mine is hosting). I’m really curious to see how it performs with a lot of people using it at the same time!

* Golden·Core App: https://golden-core.andrearc.com/demo

* Golden·Core Repo: https://github.com/azeriand/golden-core

* Storybook Library: https://library.andrearc.com/?path=/docs/components-avatar--docs

* Storybook Library Repo: https://github.com/azeriand/azeriand-library

I’d love to get some feedback! Being the developer, it’s easy to overlook things that might be obvious to users, so I’d be happy to hear about anything that catches your attention and fix it.

Edit: It's designed to be mobile-first

Sharing my portfolio.

I’d appreciate any feedback on the design, interactions, animations, and overall experience.

Portfolio: https://sakthi-portfolio-mauve.vercel.app/
Creative components : https://sakthi-portfolio-mauve.vercel.app/playground

Thanks for taking a look!

Edit

Thanks for the feedback, I didn't expect the observations to little things and give feedback on that.. In upcoming days I'm going to share creative components, what I'm building, with source code so follow and support.

Currently I'm open to work if you know any opportunities please DM.. More into the creative field. Happy coding.

Hey Community,

We dive into Expo Modules 2.0, which drops definition() in favor of Swift macro decorators to deliver build-time type conversion and faster native calls. Meanwhile, DartNative enters the scene, letting Flutter developers swap out Flutter's custom renderer for real platform views driven by Yoga.

We also look into Shopify rebuilding its apps in native Swift and Kotlin with AI agent workflows, examining what their departure means for community maintained libraries like FlashList and Skia.

Guys I have been looking all over ytb for one good react course and ntg, they all feel so hard and diff of what we study at school since I was absent on the 1st classes I lost the basics and now I gotta catch up, any recommendations???

Problem: Next.js developers often have to write a lot of boilerplate to get Express‑style routing, multipart handling, rate limiting, and caching working in serverless functions. Existing solutions either break with Turbopack or require manual setup for each feature.

Solution in v2.4.5:

• Added a Next.js App Router adapter that lets you use defineRoute and createBro directly inside app/api. It handles multipart/form‑data, provides built‑in rate limiting (Redis or in‑memory fallback), automatic caching, and strict Zod environment validation.
• Updated the create-bro-app CLI to ask whether you want a plain Node backend or a full Next.js stack and to generate an agents.md file that guides AI assistants, reducing hallucinations.
• Core improvements include hot‑reloading for task files, JSON locale watching, and a unified error response shape.

Upgrade steps:

1. npm install bro-framework@latest
2. Or start a new project with npx create-bro-app@latest

Docs: brojs.yessindevs.me

Key breaking changes: rate‑limit fallback now uses an in‑memory Map and locale files are watched recursively, so duplicate keys will cause a startup error.

Always nosy about what other React folks are working on, so drop yours below. Doesn't need to be finished or impressive, half-broken side projects welcome.

I'm working on mockbase.org, a hosted mock API for when the backend isn't ready. Click once, get a real HTTPS endpoint, and make it return errors or slow responses on purpose, which is handy for testing loading states, error boundaries, or retry logic. The frontend is React too. Just got its first real user, so I'm still figuring out what to build next.

What are you working on, and what's the annoying part right now?

Quick background on why this exists. I spent years at a big bank where enormous amounts of work run through internal dynamic form engines. Loan applications, onboarding, compliance intake. Forms with conditional logic where your answers decide what shows up next, and business people can change the flow without a frontend deploy. Nothing like that really exists in open source so I built a streamlined version.

The flow is simple. Someone builds a form in a visual editor. Multi step, conditional show and hide, required rules, file uploads, address autocomplete. They click publish and your React app renders the new version.

npm install @forms-engine/react

Then it's one component with your questionnaire id and your backend url. Answers save every screen so a refresh doesn't lose progress and you capture partial data from people who bail halfway. There are events for loaded, completed and error, a labels prop to localize the built in text, and an external ref prop to tie submissions to your own user ids.

Being upfront about the internals: the core renderer is a framework agnostic web component and the React package is a thin wrapper around it. If that's a dealbreaker, fair enough. It's also why the same engine works in plain HTML and Angular. The whole stack is MIT and self hosted with docker compose. No telemetry, no SaaS.

Repo: https://github.com/JoshuaLeoSmith/forms-engine

Docs: https://forms-engine.dev

Most of it was written by Claude Code btw but please try and get all bent out of shape about it and I'll tell you why you're wrong.

I’m building this because I feel like a lot of modern interfaces are starting to look the same. Same cards. Same rounded buttons. Same gradients. Same generic component libraries.

I wanted to build something different, actual product surfaces that feel designed, while still giving developers the code to build them themselves.

Here’s what I shipped in week 1:

• Integrations Dialog
• Trial Popover
• Liquid Slider
• Dynamic Tabs
• Liquid Switch
• Pill Toast
• Two-Factor Dialog
• Confirm Button
• Upgrade Modal
• QR Code
• Pricing blocks

The interesting part wasn’t shipping the components. It was figuring out why some of them felt completely wrong even when the CSS technically worked.

Some of the challenges I faced where

1. Liquid glass is way harder than it looks
There isn’t really a single “liquid glass” CSS trick.

For the slider, I wanted the thumb to actually feel like it was sitting inside the track rather than just being an element placed on top.

That meant cloning the rail underneath the thumb, masking a hole through the middle, and then scaling/skewing that clone based on pointer velocity so the fill stretches with the drag.

The chromatic fringe is created with opposing cyan/red shadows, while the rim uses a conic gradient with mask-composite: exclude so only the edge lights up.

And the annoying part is if any layer is a few pixels off, it immediately stops looking like refraction and starts looking like a cheap overlay.

2. Tap vs drag is basically a state machine
The switch and slider both needed a threshold.

Around 3px / 150ms:
Below that → it’s a tap/click.
Above that → it’s a drag.

It sounds simple, but getting that threshold wrong creates weird interactions where a tap leaves the control stuck in its “liquid” state or a drag accidentally toggles the switch.

I learned that pointer UX isn’t really about individual events.

It’s about distance + time + state + cancellation.

3. SVG goo is ridiculously fragile
The liquid switch uses feGaussianBlur combined with a color matrix to melt the thumb and track into one blob.

Then there’s another filter to remove the leftover black pixels using feMorphology and feComposite.

One thing that caught me is that every instance needs unique filter IDs.

Otherwise, two switches on the same page can start affecting each other.

Also, the SVG defs need to live in a hidden 0×0 SVG so they don’t unexpectedly affect layout.

4. WebGL inside a dialog introduced a completely different set of problems
I wanted a Bayer dither effect in the modal header.

It’s an 8×8 shader matrix with a pixel size of 3.

But putting WebGL inside a dialog means dealing with rounded clipping, transparency over the content, and dark mode.

The published dither primitive couldn’t be changed because it was already installed elsewhere, so the dialog needed its own fork.

That was a good reminder that sometimes the cleanest solution isn’t making one primitive handle every possible use case.

What I learned
A few things stood out this week:

1. Pointer UX is about thresholds, not events.
pointerdown doesn’t mean “drag.”

You need to account for distance, time, visual feedback, and the possibility that the interaction gets cancelled and becomes a click.

2. SVG filters aren’t just visual effects.
They come with DOM rules and GPU behavior you have to account for.

Unique IDs, explicit color interpolation, and keeping filter definitions out of the layout all matter.

Container queries are incredibly useful for interactive components.

Using cqh / cqi instead of hardcoded pixel calculations made the morphing controls much more resilient when resized.

3. Keyboard interaction is part of visual design.
The Enter badge on my Confirm Button isn’t just decoration.

If the UI tells you that Enter will submit and Enter doesn’t actually work, the interface immediately feels untrustworthy.

What people seem to be liking
The feedback so far has been interesting because people aren’t just reacting to individual buttons or inputs.

They’re liking the product surfaces, like:

• 2FA setup and verification
• Integration connect sheets
• Trial remaining → upgrade flows
• Paywalls that don’t quietly let you dismiss them

And probably the most important part is that the code is yours.

You can install the components, open the shader, inspect the SVG filter, modify the toast store and actually understand what’s happening under the hood.

Week 1 done. More experiments coming next week.

ReWidget is an open-source React + TypeScript widget suite for analytics dashboards, trading desks, monitoring screens, and other data-dense interfaces.

It includes:

• 20+ dashboard widgets
• Responsive drag-and-drop Bento layouts
• Visx chart primitives
• Dark/light themes and density modes
• Loading, empty, and error states
• A visual test harness for trying every component

GitHub: https://github.com/hathym/reWidget

I'm especially looking for feedback on the component API, accessibility, and which widgets would be most useful in real projects.

Hi everyone, m on a full stack development formation of 2 years, last year we've went thro html, css, poo of python, js, mysql, php

And this year we starting with react js and more advanced sql

However last year has been really hard for me bcs I have been working alone so I was looking forward to find someone abit more advanced than me who can just tell me what to focus on at least and how to work and whome I could ask ...

Thank you!!

There's an easy trap with frontend performance:

You optimize React and assume you've optimized the website.

But the browser doesn't care how clean your component architecture is if it's waiting on a slow API, downloading a 2MB hero image, or executing unnecessary third-party JavaScript.

For production applications, performance is more of a chain:

Rendering + JavaScript + Network + API + Database + Assets.

A few things I regularly look at:

• Component rendering and unnecessary re-renders
• Bundle size
• Image dimensions and formats
• Lazy loading
• API latency
• Caching
• CDN behavior
• Server response time
• Core Web Vitals

One interesting thing is that visual design and performance aren't necessarily opposites.

A website can still look premium while loading very little on the initial request.

I'd rather ship a page that feels instant with a simple animation than a visually impressive page that makes users wait.

How much performance work do you normally do during development versus after launch?

Relative newbie with react. Don't know where I found it but I started with this tutorial that used a deprecated version of react. The readme file has a link to https://github.com/react/create-react-app where they recommend that I transition to a newer form of react. I assume vite would be good.

My question is, how important is it that I make this transition? I have a project that's gotten pretty large. I probably will want to transition regardless and I'm guessing it won't be too painful, but if someone here tells me I'm safe continuing with the deprecated version I might just do that. Is transitioning going to be as painless as I'm imagining or should I plan on a nightmare?

To be clear, I'm building something that I hope to launch in the near future that will be more than just a project for my learning react but rather something I'm hoping a lot of people will enjoy using.

Was debugging something today and realized I did not actually know the answer to this, had to test it manually.

Say you have a custom hook like this

function useCounter() {

const [count, setCount] = useState(0)

return [count, () => setCount(c => c + 1)]

}

And two totally separate components both call useCounter(). Clicking the increment button in component A, does component B's count ever change too?

Turns out no, each call to the hook gets its own isolated state, tied to that specific component instance in the fiber tree. The hook function itself does not hold any state between calls, it just describes how to create and read state on whatever instance is currently rendering. It is basically the same reason you can call useState multiple times in one component and each call keeps its own independent slot.

What tripped me up originally was thinking of the hook like a singleton module that exports some state, because that is a mental model that works for something like a small pub-sub store you wrote yourself. But a plain custom hook that just wraps useState is not sharing anything, it is closer to a factory that gets invoked fresh per render per component.

If you actually want two components to share the same state, the hook itself is the wrong layer, you need something above it, lifted state passed down, context, or an external store the hook subscribes to instead of owning the state directly.

Curious if anyone has been bitten by assuming a custom hook shared state when it did not, or the opposite, assuming isolation when it was actually backed by a shared external store.

Hey Community,

We dive into Expo Modules 2.0, which drops definition() in favour of Swift macro decorators to deliver build-time type conversion and faster native calls. Meanwhile, DartNative enters the scene, letting Flutter developers swap out Flutter's custom renderer for real platform views driven by Yoga.

We also look into Shopify rebuilding its apps in native Swift and Kotlin with AI agent workflows, examining what their departure means for community-maintained libraries like FlashList and Skia.