I'm wondering if it is currently possible to have Supabase work with both server + client rendering. It seems as though we must generally choose one or the other, but NextJS allows one to define SSG (server-side generated), SSR (server-side rendered), and CSR (client-side rendered) pages.
For example, the webapp example for NextJS + Supabase seems to indicate that we should SessionContextProvider; however, wrapping the entire app in this context provider requires useState, which to my understanding will render the entire app as client-side rendered.
Supabase has a server-side rendering solution, but then this seems to require us to manually handle components/pages that we want to render client-side. For each component that requires authentication, we would need to explicitly make a session call, which seems unnecessarily excessive.
With the NextJS-13 beta, we can explicitly define server components, and it seems Supabase has a beta solution too. However, I was wondering if it is currently possible to do this without the beta?
Wrapping the entire app in this context provider requires useState, which to my understanding will render the entire app as client-side rendered.
No, it won't cause the entire app to be CSR. The use of React hooks on pages folder components (including _app.js) won't cause the page to be client-side rendered, it will still be pre-rendered (as long as there are no blocking data requirements, e.g. using getServerSideProps or getInitialProps in the case of _app.js, see Automatic Static Optimization) and then sent to the client to be hydrated. This is also true for pages/components marked as client-components on Next.js v13 app directory feature, they will still be pre-rendered.
The only way in which Next.js won't server-render a component is if using dynamic imports and setting ssr to false (doesn't apply for page components).
Related
For example, I have a piece of code to check if I am a client or a server to have the appropriate logic.
For example. I can use isClient to know that I am in client component.
Server components : All components inside the app directory are React Server Components by default, including special files and colocated components.
Client Components enable you to add client-side interactivity to your application. In Next.js, they are prerendered on the server and hydrated on the client. You can think of Client Components as how Next.js 12 and previous versions worked
learn more in next official doc
By default, a NextJs middleware is run using the Edge runtime and from what I understand this is because the middleware is meant to be run on the edge network instead of the main server (being run on the edge network reduces the latency so this offers improved performance in some scenarios).
The downside of this is that the Edge runtime comes with some restrictions in terms of what it can run (list here).
My question is: is there any way to make a middleware run using the default runtime instead of the Edge runtime?
In my situation, we're not hosting anything on the edge so the Edge runtime imposes some restrictions on us without providing any benefits. A possible workaround would be to use a custom middleware instead of a NextJs one, but unless this is the only choice, I would rather use the NextJs middleware architecture & plumbing instead of building our own.
P.s.: We're using NextJs 12.1.6 (latest version at the moment of writing this question)
There's no way to do it at the moment, but it's being worked on. See RFC: Switchable Next.js Runtime
At the moment if you need node apis in your middleware you can work around the issue by making api routes that do stuff with node apis and then calling them from your middleware. You should definitely try that one out instead of making custom middleware with custom server I assume, since custom servers have limitations.
Next.js 13 added option to change the runtime, but I don't think the setting applies to middleware. The setting can be used to make everything run on the edge though. https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runtimes#global-runtime-option
Now it's possible to determine at global and segment levels which runtime should be used with Next.js 13.
This configuration is for defining the runtime for global:
module.exports = {
experimental: {
runtime: 'experimental-edge', // 'node.js' (default) | experimental-edge
},
};
https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runtimes#global-runtime-option
If you want to determine at the segment (aka server component) level, the only thing to do is export a runtime constant variable.
[app/layout.js]
export const runtime = 'experimental-edge'; // 'node.js' (default) | 'experimental-edge'
https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runtimes#segment-runtime-option
I want to create a Browser-Application without SSR, with React and MUI. So I found a NextJS-Template here:
https://github.com/mui/material-ui/tree/master/examples/nextjs-with-typescript
I want to disable SSR completely, let's say in the best case starting with _document.tsx, but at least the file _app.tsx and all following as for example _index.tsx should be rendered without SSR.
So, how to disable SSR "completely"?
While some might tell you to use plain React, others still use Next.js because of things like file-based routing, sane ESLint and TypeScript defaults, and fast compilation times (because of SWC). If you prefer the developer experience of Next.js over standalone React, but don't want/need SSR, then you have the option to use a static HTML export:
next export allows you to export your Next.js application to static HTML, which can be run standalone without the need of a Node.js server. It is recommended to only use next export if you don't need any of the unsupported features requiring a server.
The example template you linked to shouldn't need any additional code changes (running next export on it worked fine for me, it only threw a warning about a missing ESLint configuration which is easy to set up).
Just remove the getStaticProps, getStaticPaths and getServerSideProps from the pages you don't want to SSR and it will act like a normal react page.
Svelte’s JavaScript server-side rendering API is described here: https://svelte.dev/docs#run-time-server-side-component-api
However, when I do this in TypeScript, there is no method App.render().
Do I need to change rollup.config.js (e.g. compilerOptions.generate)?
Do I need two versions of this file – one for the server and one for the client?
Can anyone help? Thanks!
Svelte Server-side component API is not directly accessible via import. Instead, you need to build the production with vite options --ssr. Otherwise, you're importing the component class extended SvelteComponent and that class has no render function.
You can check out this guide for Production SSR build: Vite Server-Side Rendering.
You don't need to set up the SSR Dev server or inject /#vite/client because svelte-hmr already does the magic under the hood.
The SSR Bundle options ssr.noExternal doesn't seem to work for me. So that I need to convert all Svelte components import into static import for a production build.
The official template relies on rollup-plugin-svelte, where similar question was asked. Essentially compiling in SSR mode does not automatically generate any HTML, in fact some post processing is required. The Svelte Server-side component API can be used for that.
There are several solutions out there for SSR:
SvelteKit
Routify
ElderJS
I am exploring the development with Web Components, more specifically, it's Fast. However, it would take a long time to rebuild the project and refresh the page, then verify for the CSS modification. Is there any CSS hot reload solution for the Web components(Fast)? (I am using Webpack)
There is no out-of-box solution for HMR with Web Components in General. It really depends on how you are using Web Components. Are you relying on just Custom Elements and using CSS-in-JS with it or fully using ShadowDOM with encapsulated styles and the underlying framework to declare those styles.
You can consider building your own HMR driver. To do this, you need all the three things in order for enable HMR - the bundler (assuming Webpack already has it), the server (webpack's dev server or middleware) and your own application.
In you own application, you would add the driver as:
// RUN SOME BOOSTRAPPING CODE
// HMR interface
if (module.hot) {
// Capture hot update for a particular module
module.hot.accept("./style.css", () => {
// Logic to remove old stylesheet
});
}
If you look at the above code, you can notice that it is almost impossible to change StyleSheet if it is defined within the shadow root for each component. If you have some global CSS which gets added to top Document then it simpler to implement HMR by manipulating StyleSheet objects from the javascript. At least, you will get partial HMR. For other activities, you can fall back to automatic full page refresh.