Нове компоненте сервера Реацта могу бити смрт преплављених веб апликација

Функција RSC (React Server Components) SSR (Server-Side Rendering) CSR (Client-Side Rendering)Интеракција Не ✅ Потпуно ✅ Потпуно Функција RSC (React Server Components) SSR (Server-Side Rendering) CSR (Client-Side Rendering) niko Интеракција Не ✅ Потпуно ✅ Потпуно Персонализовани или динамички УИ Функција RSC (React Server Components) SSR (Server-Side Rendering) CSR (Client-Side Rendering) сервера Клијент сервера niko niko Интеракција Не ✅ Потпуно ✅ Потпуноинтеракције ✅ преко getServerSideProps Potreban vam je API poziv ✅ преко getServerSideProps Potreban vam je API poziv Када се трчи po zahtevu Када се трчи Персонализовани или динамички УИ Персонализовани или динамички УИ Карактеристике Сервер Компонента Клијент Компонента употребаСтатус ❌ ✅ употребаЕфекат ❌ ✅ употребаКонтекст ✅ (ако је статичан) ✅ асинх/очекивати ✅ ❌ (треба да се укључи у ефекте) Управљачи догађајима ❌ ✅ Функција Сервер Компонента Клијент Компонента Коришћење Ефекат async/await ✅ (треба да се умотава у ефекте)Детаљи Серверске компоненте Серверске компоненте Коришћење Ефекат async/await ✅ (треба да се умотава у ефекте) Детаљи Потребна је интерактивност и локална држава CSR Потребна је интерактивност и локална држава РСЦ + стреаминг Често мењају, преносе се са Суспенсе да не блокирају ТТФБ (*If you’d like to skip ahead and dive directly into the technical breakdown, jump to 1. Why React Server Components Were Introduced.) In the early 2010s, React revolutionized frontend development with its declarative component model and efficient virtual DOM diffing. What began as a simple view library soon became the backbone for large-scale single-page applications (SPAs). These SPAs predominantly used Client-Side Rendering (CSR), meaning the browser would download a JavaScript bundle, execute it, and construct the UI entirely on the client. This client-centric model was flexible and highly interactive, and it defined “modern” web apps for years. However, as applications grew more complex and feature-rich, the CSR approach started to show its cracks: Hefty JavaScript bundles and client-side work meant users waited longer before they could actually interact with the page. Longer Time-to-Interactive (TTI): Хидрација боца: Претварање ХТМЛ-а који је приказао сервер у интерактивну апликацију (хидрација) постала је тачка удара у перформансама, посебно пошто се количина динамичког садржаја повећала. Надувани пакети: Апликације често испоручују много више ЈаваСцрипта него што је потребно, оптерећујући претраживаче кодом за функције или садржај који би могао бити испоручен ефикасније. The larger and more complex the app, the harder it became to maintain snappy performance across all devices and network conditions. Performance that doesn’t scale: Next.js emerged to tackle some of these pain points by introducing Server-Side Rendering (SSR), Static Site Generation (SSG), and other optimizations. These techniques improved initial load times and offloaded some of the UI rendering work to the server. But even with SSR and SSG, the fundamental issue remained: we were still over-delivering JavaScript to the browser. Брзо напред до 2025. године.Са Next.js 15 који ради на Реацт 19, нова парадигма рендерирања је ушла у средишњу фазу: РСЦс омогућавају програмерима да беспрекорно мешају компоненте које приказују сервери и клијенти у једном Реацт дрвету. Импликације су значајне. статички делови УИ-а сада се могу испоручити као чист ХТМЛ са Другим речима, за те секције није потребна хидратација са стране клијента. Логика прикупљања података се такође поједностављује покретањем компоненти унутар сервера, елиминишући многе непотребне АПИ позиве из претраживача. React Server Components (RSC) zero JavaScript overhead Овај чланак није преглед РСЦ-а на површини.Када сам почео да пишем о ефикасном коришћењу Next.js-а у 2025, брзо је постало јасно да Реацт Сервер Компонентс заслужује посвећено дубоко роњење.Оно што следи је технички ригорозно истраживање како РСЦ ради под капом, како га искористити у пројекту Next.js 15 и зашто то представља фундаменталну промену у фронтенд архитектури. By the end, I hope you come away with the same clarity and appreciation for RSC that I did through the process of researching and writing this piece. Intro: From CSR to RSC — How Rendering Evolved in React Intro: From CSR to RSC — How Rendering Evolved in React Током протекле деценије, начин на који градимо Реацт апликације фундаментално је еволуирао и са њим, начин на који размишљамо о рендерирању. 🕰 A brief history of Client-Side Rendering (CSR) in React React gained its popularity through — a model where the browser downloads JavaScript, executes it, and builds the entire UI on the client. This approach gave developers full control over interactivity and state, and made it easy to build dynamic single-page applications (SPAs). Client-Side Rendering (CSR) However, CSR came with notable trade-offs: Спорији почетни оптерећења, посебно на мобилним или лошим мрежама for content-driven pages Poor SEO — even for pages with minimal interactivity JavaScript-heavy bundles A was required after HTML loaded, delaying time-to-interactive hydration step Неко време, ова ограничења су била само "како су ствари биле." Како је Next.js довео SSR и SSG у развој Реацта When entered the scene, it introduced server-side rendering (SSR) and static site generation (SSG) as first-class citizens for React. This marked a turning point: frontend developers could now choose how and when rendering occurred. Next.js enabled pages to be generated per request, improving SEO and load speed for dynamic content. SSR allowed content to be prebuilt at deploy time, perfect for blogs, docs, and marketing sites. SSG bridged the gap by allowing static pages to be updated post-deploy. Incremental Static Regeneration (ISR) This flexibility helped developers strike a better balance between performance, SEO, and developer experience. But even with SSR and SSG, there was still a lingering issue: — even for components that didn’t need to be interactive. we were still sending too much JavaScript to the browser 🧠 The rise of React Server Components (RSC) in 2025 Са ослобађањем and Ušli smo u novu eru: are now a core part of how we build apps. Next.js 15 React 19 React Server Components (RSC) Unlike SSR, which still requires hydration and ships JavaScript to the client, . RSC allows you to render components on the server — without sending any JavaScript to the browser at all It’s a big shift: Components can now access server-side data directly Static content doesn’t require hydration You can mix server and client components in a single React tree, composing your rendering strategy per component RSC ne zamenjuje SSR ili SSG. , откључавање финијег контроле над перформансама, величином пакета и понашањем приказа. complements them In 2025, RSC is a foundational concept that every senior React engineer needs to master. 1. Why React Server Components Were Introduced 1. Why React Server Components Were Introduced As React applications became more complex, the industry began to feel the weight of its success. While Client-Side Rendering (CSR), Server-Side Rendering (SSR), and Static Site Generation (SSG) offered different strategies for building performant web apps, each of them carried trade-offs that grew more apparent at scale. 🚧 Limitations of CSR, SSR, and SSG 1 Hydration overhead Чак и са ССР или ССГ, када ХТМЛ стигне до претраживача, Реацт треба да "хидрира" страницу - прикључи слушаоце догађаја, поново покрене компоненте и ефикасно поново изгради апликацију у меморији. 2. JavaScript bundle bloat With CSR, every component, utility, and API call that’s part of the page must be sent to the browser — regardless of whether it’s interactive or not. SSR and SSG reduce this slightly, but most of the bundle still needs to be executed on the client. As apps grow, this leads to bloated bundles that slow down the user experience. 3. Disconnected data-fetching logic In the pre-RSC world, data lived outside the components that rendered it. You had to use or (or call APIs in ) to fetch data, then pass it into components via props. This separation added cognitive overhead and made code harder to co-locate and reuse. getServerSideProps getStaticProps useEffect 🧠 What problems RSC was designed to solve React Server Components (RSC) were created to address these growing pain points with a simple but powerful idea: . let components execute on the server by default, and only send JavaScript to the browser when it’s absolutely necessary ✅ Eliminate unnecessary JavaScript RSC allows components to be rendered server-side Ако компонента не захтева интерактивност, нема потребе за хидратацијом или оптерећењем њеног ЈС пакета. without Server-side data access within the component tree RSC removes the artificial boundary between data fetching and rendering. Server components can use да директно приступите базама података, датотечним системима или АПИ-има - ко-лоцирање података и природно прегледање логике, без потребе за АПИ рутама или бушењем. async/await ✅ Improve rendering efficiency and developer experience Пребацивањем неинтерактивне логике на сервер, програмери могу да граде лакше апликације са мањим пакетима и бољим перформансама.РСЦ такође поједностављује ментални модел - само пишете компоненте и пустите оквир да управља где се покрећу и како се испоручују. RSC ne želi da zameni SSR ili SSG, već ih nadopunjuje. , not just the page level, about what should run on the server and what belongs in the browser. at the component level In short: React Server Components were designed to bring modern frontend development back to its lean, fast, and maintainable roots without compromising interactivity. 2. Rendering Strategies in Next.js 15: RSC vs SSR vs CSR 2. Rendering Strategies in Next.js 15: RSC vs SSR vs CSR Next.js 15 offers developers a granular rendering model that goes far beyond traditional page-level strategies. With becoming a first-class concept, it’s essential to understand how they compare to two familiar models: and . React Server Components (RSC) Server-Side Rendering (SSR) Client-Side Rendering (CSR) While SSG (Static Site Generation) is still valuable in specific cases, it can be viewed as a built on top of SSR. In contrast, represent distinct runtime rendering paths, and understanding them is crucial for making performance- and architecture-aware decisions in 2025. caching strategy RSC vs SSR vs CSR 💡 Пре него што упоредимо: шта значи "интерактивна компонента"? U kontekstu React i Next.js, jedan is any UI element that . interactive component requires client-side JavaScript to respond to user input or browser events This includes (but is not limited to): Buttons that update state on click Forms with validation or controlled inputs Dropdowns and modals that toggle open/closed Animations triggered by scrolling or hover Tabs, carousels, filters, sliders Components that use , , or useState useEffect useReducer If a component has • интерни , or relies on the То мора да иде на клијента. event handlers state DOM or browser APIs Interactivity = Browser-side behavior + JS event listeners + local state. Разумевање ове разлике помаже да се разјасни : to avoid shipping JavaScript for UI pieces that don’t need to be interactive. why RSC exists 🧩 Rendering Models at a Glance Render location сервера сервера Клијент JavaScript sent to browser niko Да ✅ Yes Requires hydration ❌ No Да ✅ Yes Access to server resources ✅ Direct ✅ Via getServerSideProps Potreban vam je API poziv When it runs On-demand or streamed po zahtevu On load in browser Ideal use case Static or data-bound views Персонализовани или динамички УИ Interactive flows, local UX Render location сервера сервера Client JavaScript sent to browser ✅ Yes ✅ Yes Requires hydration ❌ No Да ✅ Yes Access to server resources ✅ Direct ✅ Via getServerSideProps Potreban vam je API poziv When it runs On-demand or streamed po zahtevu On load in browser Ideal use case Static or data-bound views Interactive flows, local UX Feature Feature RSC (React Server Components) RSC (React Server Components) SSR (Server-Side Rendering) SSR (Server-Side Rendering) – пренос са стране сервера CSR (Client-Side Rendering) CSR (Client-Side Rendering) Render location сервера Render location Render location сервера сервера Server Client Client JavaScript sent to browser ✅ Yes ✅ Yes JavaScript sent to browser JavaScript sent to browser niko Да ✅ Yes ✅ Yes ✅ Yes Requires hydration ❌ No Да ✅ Yes Потребна хидратација Потребна хидратација ❌ No Не Да Да Да Да интеракције Не Не ✅ Full ✅ Full Потпуно Потпуно Приступ серверским ресурсима Директно Приступ серверским ресурсима Access to server resources Директно Директно ✅ преко getServerSideProps Potreban vam je API poziv On-demand or streamed Преузмите у Browser When it runs On-demand or streamed On-demand or streamed po zahtevu Per request Преузмите у Browser On load in browser Идеални случај употребе Static ili data-bound pogledi Interactive flows, local UX Идеални случај употребе Ideal use case Static ili data-bound pogledi Static ili data-bound pogledi Personalized or dynamic UI Interactive flows, local UX Interactive flows, local UX 🔍 Think in Components, Not Just Pages In earlier versions of Next.js, rendering strategies were applied at the . You had , Шта год да изаберете, примењује се на . This made sense in a world where rendering happened all-or-nothing — either statically at build time, or dynamically on each request. page level getServerSideProps getStaticProps entire page But with and the директоријум уведен у Next.js 13+ и стандардизован у 15, Ona postaje a To otvara novi način razmišljanja. React Server Components (RSC) app/ rendering is no longer a top-down, one-size-fits-all decision per-component concern 🧠 A New Way of Thinking: Declarative and Composable Rendering Ova promena je više od promene API-ja, to je konceptualna promena u načinu na koji arhitektujete frontend. Declarative Уместо оркестрације and components are rendered manually, you now simply — React and Next.js take care of the rest. how gde declare what each component does and what it needs You don’t manually wire up API endpoints or pass props from SSR to components. You can just write: // Server Component export default async function ProductInfo() { const product = await db.getProduct(slug) return {product.name} } This component: Раде на серверу Doesn’t send JS to the client Не захтева никакве getServerSideProps или API слој Да ли је "само компонента" - није потребна додатна апстракција You describe the UI and its data needs , and the rendering engine figures out the rest. declaratively Composable Different parts of your UI can use different rendering strategies — , , и . . on the same page at the same time with minimal overhead For example: // Product page layout // Server Component (no JS, rendered on the server) // Client Component (interactive) // Static Component (SSG with revalidation) These components live together in the same tree, but each one: Runs in a different environment (server, client, build) Uses only the data and code it needs Преноси управо оно што је потребно за претраживач - не више, не мање To make this more concrete, I created a that showcases how different rendering strategies can coexist on a single page. Минимална демо 3. How React Server Components Work Under the Hood Како Реацт сервер компоненте раде под капом React Server Components (RSC) are more than just a new rendering strategy, they fundamentally change how component trees are built, rendered, and transmitted. To use RSC effectively in production, it’s important to understand and how it impacts the boundaries of state, interactivity, and data. how it works behind the scenes 🧱 Server/Client Boundary: A Split React Tree React aplikacije koje koriste RSC više se ne prikazuju u potpunosti na klijentu. : component tree is split into two worlds : Execute only on the server. No JavaScript is ever sent to the browser. Cannot hold local state or attach event listeners. Perfect for rendering static content and server-bound logic (e.g., DB access). Server Components : Must be explicitly marked with . These are compiled into browser-friendly JavaScript and support full interactivity, local state, , and event handling. Client Components "use client" useEffect At build or runtime, React constructs a tree where server and client components coexist and stitches them together during render. 📍 What U stvari čini "use client" When you add to a file, it marks that entire module and its exports as . Behind the scenes, this instructs the Next.js build pipeline to: "use client" client-only Compile that file (and its dependencies) into a separate JavaScript bundle Exclude that component from being run on the server Treat it like a classic React CSR component with hydration logic This directive acts as a between the two sides of the tree. All components above it can be server-rendered; all components below it must be rendered in the browser. boundary marker 💧 Streaming: Rendering in Pieces, Not All at Once RSC embraces as a native rendering strategy. Instead of waiting for the full React tree to be built before sending it to the browser, the server of UI to the client as they become ready. streaming streams serialized fragments Компоненте сервера се приказују и шаљу што је пре могуће Задржавачи места (нпр. преко ) привремено попуњавају Client Components hydrate incrementally, only when they load ✅ How is this possible? RSC introduces a concept called selective hydration. When a Client Component is rendered within a Server Component tree, React inserts a placeholder ( ) and defers hydration. Након што је клијент учитао одговарајући ЈС пакет: Реацти лазилно оптерећује ту специфичну компоненту Finds the placeholder and stitches it into the live tree Hydrates it in isolation, without re-rendering the entire page This design is : апликација почиње брзо, а интерактивност се постепено појављује на мрежи. decoupled and progressive }> // Server Component // Client Component (hydrated later) ⚙️ Data Fetching and Code Splitting in RSC Another key “magic” of RSC: — without relying on , , or manual prop-passing. you can fetch data directly inside components with async/await getServerSideProps useEffect // Server Component export default async function Dashboard() { const stats = await getStatsForUser() return } Why is this possible? RSC components , not as client-compiled modules run as real server functions Они могу приступити базама података, интерним АПИ-има, датотечним системима или било чему што ваш сервер подржава. The result is rendered HTML (not JS) and streamed to the client Also: , since the result is static No hydration needed in the component itself — everything resolves before it hits the browser No loading UI logic — unless nested inside a client boundary No code for this component is sent to the client This significantly reduces boilerplate and bundle size, while keeping logic colocated with UI — a long-standing React goal finally realized at scale. Стање, кукови и разматрања животног циклуса RSC traditional React hooks like , , or Зато што су они . does not support useState useEffect useRef don’t run in the browser Коришћење контекста ✅ (if static) ✅ Feature Client Component Feature карактеристике Серверске компоненте Компоненте клијента Client Component Коришћење useState ✅ ✅ useEffect useEffect ❌ ❌ ✅ Коришћење контекста ✅ (ако је статично) Коришћење контекста useContext ✅ (ако је статично) ✅ (if static) ✅ async/await async/await ✅ ❌ (should wrap in effects) ❌ (should wrap in effects) Руководиоци догађаја Руководиоци догађаја ❌ ❌ ✅ This enforces a clean separation of responsibilities: Компоненте сервера: подаци и распоред Client Components: interactivity and local state React Server Components are designed to simplify your app. Once you internalize the boundary rules, the streaming model, and async data access, you can with far less boilerplate than before. compose fast, personalized, and minimal-JS apps 4. What’s the Best Practice? Combining RSC, SSR, and SSG 4. What’s the Best Practice? Combining RSC, SSR, and SSG Једно од најчешћих питања са којима се React инжењери суочавају у Next.js 15 није "Да ли треба да користим РСЦ?" - то је “how do I combine RSC with SSR and SSG in a maintainable, high-performance way?” Лепота Next.js 15 је у томе што више нисте ограничени на једну стратегију рендерирања по страници. , applying the most appropriate approach to each part of the UI. compose rendering strategies at the component level This section introduces a practical framework for making that decision based on actual architectural needs. 🧭 Start with the Core Question: What does this component need? Поставите ова четири питања за сваку компоненту: Да ли је потребно да буде интерактивно? ✅ Да → Користите компоненту клијента Da li su potrebni bezbedni, specifični podaci ili podaci u realnom vremenu? ✅ Da → Razmislite o SSR Can it be precomputed or infrequently updated? ✅ Yes → Prefer SSG Does it fetch server data but never need to run on the client? ✅ Yes → Use RSC 🧩 Example: Product Page Strategy Breakdown Here’s how a typical e-commerce prduct page might be composed using all three strategies: Component Rendering Strategy Reason ProductDetails RSC Fetched from DB, no interactivity, no need to hydrate PriceWithPersonalization SSR Depends on user session, dynamic per request AddToCartButton CSR Requires interactivity and local state RelatedProducts SSG (with ISR) Safe to cache at build-time, can revalidate every 24h or per tag StockStatusBanner RSC + streaming Frequently changing, streamed in with Suspense to not block TTFB Компоненте Rendering Strategy Razlog ProductDetails RSC Fetched from DB, no interactivity, no need to hydrate ЦенаПерсонализација SSR Depends on user session, dynamic per request AddToCartButton CSR RelatedProducts SSG (with ISR) Safe to cache at build-time, can revalidate every 24h or per tag StockStatusBanner RSC + streaming Frequently changing, streamed in with Suspense to not block TTFB Компоненте Rendering Strategy Razlog Компоненте Component Rendering Strategy Rendering Strategy Razlog Razlog ProductDetails RSC Fetched from DB, no interactivity, no need to hydrate ProductDetails ProductDetails RSC RSC Fetched from DB, no interactivity, no need to hydrate Преузето из ДБ-а, нема интерактивности, нема потребе за хидратацијом ЦенаПерсонализација SSR Depends on user session, dynamic per request ЦенаПерсонализација PriceWithPersonalization SSR SSR Depends on user session, dynamic per request Depends on user session, dynamic per request AddToCartButton AddToCartButton AddToCartButton CSR CSR Requires interactivity and local state Потребна је интерактивност и локална држава RelatedProducts SSG (with ISR) Safe to cache at build-time, can revalidate every 24h or per tag RelatedProducts RelatedProducts SSG (with ISR) SSG (with ISR) Safe to cache at build-time, can revalidate every 24h or per tag Safe to cache at build-time, can revalidate every 24h or per tag StockStatusBanner StockStatusBanner StockStatusBanner RSC + streaming RSC + streaming Frequently changing, streamed in with Suspense to not block TTFB Често мењају, преносе се са Суспенсе да не блокирају ТТФБ Свака компонента ради — no more, no less. No full-page hydration, no global data fetching, no unnecessary JavaScript. just what it needs to do Дизајн најбоље праксе за комбиновање стратегија ✅ 1. почетак сервера-прво Design every component as a Server Component by default. Opt into interactivity ( ) only when necessary. This keeps bundles smaller and simplifies testing. "use client" ✅ 2. Keep boundaries clear Користите именовање фасцикле или суфикси имена да бисте границе изразили: /components /server/ProductDetails.tsx /client/AddToCartButton.tsx /shared/ReviewStars.tsx ✅ 3. Embrace Suspense for progressive delivery Коришћење to stream in non-critical RSCs without blocking the whole page: }> ✅ 4. Co-locate logic with components Don’t split data-fetching and UI across files unless necessary. In RSC, you can colocate logic directly inside the component tree — the framework takes care of the rest. async ✅ 5. Use ISR (Incremental Static Regeneration) smartly For cacheable, high-traffic pages like blog articles or marketing sections, use SSG + revalidation: export const revalidate = 3600 // regenerate every hour ✔️ Уобичајене грешке које треба избегавати ❌ by default — you’ll end up with CSR all over again Using "use client" ❌ Fetching data in client components when it could be server-fetched ❌ — instead, let client components be focused, isolated, and stateful Passing too much data between RSC and client components via props ❌ logic inside RSC — no need, RSC server-side Recreating SSR-style getServerSideProps is ✅ Decision Tree Summary Here’s a simplified guide: Is it interactive? │ ├── Yes → Client Component (CSR) │ └── No │ ├── Needs per-request data? → SSR │ ├── Can be pre-rendered? → SSG │ └── Otherwise → RSC You don’t need to memorize it. Once you internalize how rendering maps to responsibility, . the decisions become intuitive Најбоља пракса није о избору "најбоље стратегије рендерирања". То је о — with clarity, purpose, and performance in mind. designing rendering as an intentional part of your component architecture 6. Looking Ahead: Why RSC Is More Than Just a Feature 6. Looking Ahead: Why RSC Is More Than Just a Feature React Server Components are not just a performance optimization or a DX enhancement — . Much like React Hooks in 2019, RSC in 2025 is . . they represent a foundational shift in how we build React applications redefining the baseline for frontend architecture РСЦ мења ментални модел изградње у реакцији Традиционални развој Реацта је увек изграђен на овој претпоставци: “The browser owns the runtime. We hydrate everything. Every piece of logic and data must live in the client, or be fetched via API.” RSC breaks that assumption. With RSC, you now ask: Can I skip hydration entirely? Да ли се ова компонента може покренути искључиво на серверу? Can I colocate backend logic with my UI? It gives us back , not with wrappers and workarounds, but with . the ability to separate display logic and interactivity cleanly first-class architectural boundaries It’s no longer “client-first.” It’s “purpose-first.” Each part of your UI exists where it’s most efficient — server, client, or static. 🌐 Ecosystem Shift Toward Server-First Rendering RSC isn’t happening in isolation. The broader frontend ecosystem is undergoing a . . server-first rendering renaissance Frameworks like: lean heavily into server data loading and form actions. Remix embraces zero-JS by default, shipping only islands of interactivity. Astro takes hydration to the extreme — deferring all JS until explicitly needed. Qwik , with RSC and App Router, now puts of the developer experience. Next.js 15 per-component rendering at the center This isn’t a coincidence. It’s a reflection of a hard truth we’ve all felt: Sending less JavaScript is the only way to scale interactivity and performance on the modern web. React Server Components are the React-native answer to that challenge — deeply integrated, ergonomic, and production-ready. Šta očekivati sledeće The evolution is still ongoing. As React 19 and the ecosystem mature, we can expect: Више грануларних алата за дебугирање и профилирање за РСЦ дрвеће to show boundaries and hydration timelines Better DevTools integration to abstract rendering strategy (e.g., , wrappers) Higher-order patterns Broader adoption in design systems, frameworks, and libraries (e.g., RSC-aware UI kits) 💬 Enjoyed the read? Ако вам је овај чланак помогао да другачије размишљате о Реацт-у и Next.js 👉 За дубље дивљење Follow me on HackerNoon Хакери 👉 to chat about React, architecture, or RSC migration Or connect with me on LinkedIn LinkedIn