The following is the explanation of the idea of using React components as components with responsibility for a certain domain within an application (e.g., authentication, images, forms), promoting segregation of responsibilities, reduced coupling, testing, etc…
In a nutshell, React components live up to their name.
What if React Components were the new API? Meeting developers where they are today, right in their React frontends? What if state management and third-party SaaS workflows could be abstracted away in a single React component (and maybe a hook or two)?
Why now? Better styling primitives for components that expose a functional skeleton UI that can be integrated with custom themes. Usually, this happens with a mix of CSS-in-JS or other theming patterns.
Authentication — Most authentication applications offer a React SDK — everything from Auth0 to AWS Amplify to upstarts like Clerk. These usually include components for SignIn, SignUp, and user information.
Real-time backends — Not quite a component, but DriftDB exposes a useSharedState hook that acts like useState but is synchronized with other clients. Others are more specific, like Liveblocks, which exposes a createRoomContext hook that shows presence (“who else is viewing this document”)
Search — Algolia’s DocSearch can be added as a simple React component.
Chat and activity feeds — Stream has a React Component that embeds a chat or activity feed into your application.
Image CDN — Vercel’s next/image encapsulates a CDN and optimized caching workflow behind a React component. It does lazy loading, blur, resizing, and more.
Forms — There are many form startups that ship a React component for automatically uploading responses.
#reads #matt rickard #react #software engineering #react components