Support React Server Components in Paragon

[aheykamp2u]

Description

Next.js v13.2+ added support for React's new React Server Components (RSCs), which bring server side rendering to React at the component level. More information here

Paragon makes heavy use of its ThemeProvider via the Container component, which is likely to be all over codebases utilizing Paragon. Because ThemeProvider leverages the Context API, any component or page that uses it will break if that component or page is being rendered as a RSC. This is because Context API is only available to client components, not server components.

To circumvent this issue, I'm adding the 'use client' directive to any Paragon component which makes use of a feature that would designate it as a client component. Note that this is exactly how react-bootstrap solved this issue.

I attempted to update Paragon to use the newest versions of react-bootstrap and bootstrap, but this proved to be very complicated, had several breaking changes, and ultimately I could not get it building and serving satisfactorily.

I'm submitting this as a draft for the time being while I verify that the Container component is the only component which is causing this breaking issue in Paragon.

Deploy Preview

Include a direct link to your changes in this PR's deploy preview here (e.g., a specific component page).

Merge Checklist

• If your update includes visual changes, have they been reviewed by a designer? Send them a link to the Netlify deploy preview, if applicable.
• Does your change adhere to the documented style conventions?
• Do any prop types have missing descriptions in the Props API tables in the documentation site (check deploy preview)?
• Were your changes tested using all available themes (see theme switcher in the header of the deploy preview, under the "Settings" icon)?
• Were your changes tested in the example app?
• Is there adequate test coverage for your changes?
• Consider whether this change needs to reviewed/QA'ed for accessibility (a11y). If so, please add wittjeff and adamstankiewicz as reviewers on this PR.

Post-merge Checklist

• Verify your changes were released to NPM at the expected version.
• If you'd like, share your contribution in #show-and-tell.
• 🎉 🙌 Celebrate! Thanks for your contribution.

[netlify]

✅ Deploy Preview for paragon-openedx ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	5f04a1f
🔍 Latest deploy log	https://app.netlify.com/sites/paragon-openedx/deploys/65d66f304c3a230008b348f7
😎 Deploy Preview	https://deploy-preview-3008--paragon-openedx.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (7e4a81f) 93.18% compared to head (5f04a1f) 93.18%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3008   +/-   ##
=======================================
  Coverage   93.18%   93.18%           
=======================================
  Files         249      249           
  Lines        4342     4342           
  Branches     1036     1036           
=======================================
  Hits         4046     4046           
  Misses        292      292           
  Partials        4        4           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bradenmacdonald]

Question: The <Container> component tends to be pretty high up in the DOM tree, containing most parts of each page. If we force it to be a client component, doesn't that mean that most of the page is going to end up being client rendered anyways? Then you don't get much of the advantage of RSC, while still paying the high complexity costs.

Side comment: (FWIW I began converting a large Next.js project from the page router to the app router with RSC, and I found it to be a bad experience. There is a huge difference between how client components and server components work in terms of things like React Context, fetching data, accessing route data, etc. Yet you're encouraged to put all your components together as if they're the same things. The idea of being able to render components either on the server or on the client is nice, but in practice many things have to be designed, coded, and used completely differently depending on whether they're server or client components, and I found this added an extra layer of cognitive load that wasn't welcome. Often, something that I wanted to develop as a server component had to be re-written to be a client component, and then so does everything below it in the React tree. Or, if I try to optimize the app by lifting something from client component to server component, I have to again rewrite it to use totally different APIs and support a new runtime. Until you discover that something it needs isn't supported on the server at all. What's more, Next with RSC makes the whole application stack more complicated; with SPAs you have a backend and frontend. You can compile the frontend to static pages and host it on a CDN. Simple. With Next.js RSC, your frontend has its own substantial edge backend that's now doing a lot more work, so you have two backend servers and a frontend. And the Next.js backend has somewhat idiosyncratic runtime behavior.)