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
Related
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).
I have a NextJS project using Relay. I have it working fine in development, but when I build, it is building static pages and is trying to access my GraphQL server (in dev it is pointed to https://localhost:3000/api/graphql), but I don't want it to since it should be a dynamic page.
With that, I also can't seem to get SSR working with Relay since a lot of functionality in Relay requires hooks and we can't use hooks in non React components (like getServerSideProps()). I got as far as using loadQuery from Relay in getServerSideProps but now my issue is that I need to get the Relay environment somehow, but again, can't use getRelayEnvironment() in there either. I import it from the createRelayEnvironment file but then I'm not using my App's environment (RelayEnvironmentProvider at the root of my App).
Anyone have success with using Relay in NextJS?
I don't know how I missed this, but I followed along with NextJS's example for using Relay Modern on GitHub.
I didn't do everything the same - I don't have a .babelrc file, for example, because that info is in the next.config.js file (thanks to NextJS 12.1).
What I really used from here was how they were starting and using relay in their relay.js file. Then I used that in a getServerSideProps function in my page just like how they did in their index.js file.
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.
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.
Let's say I have a file named utils.js, containing two functions s and c.
s is a server-side function (Being called on an /api endpoint handler), and uses mongodb package.
c is a client-side function (will be bundled and sent to the browser).
When compiling the app using next build, will it cause any issues?
Does webpack know to bundle only part of a file/module? (considering server-side functions and imports as a "dead code" since they only being called from a server-side code)
Thanks
If you need to know which functions get bundled to the client & which ones to the server, there's an easy way to know this → https://next-code-elimination.now.sh/
Just copy & paste the contents of your file into it & you'll see which code gets bundled to the client & which code is bundled to the server. If you have imports then make sure to put all the imports in one file so you can see how it works.
The thumb rule is:
Anything like getServerSideProps, getStaticProps & getStaticPaths will be removed from the bundled code. If you import anything from a file that uses server-side code like fs but doesn't use it in any of the above 3 functions, then it won't be removed (check at Next Code Elimination Tool) & will give you an error.
The tool is the answer. I copy-pasted my file in it & found the answer in an instant.
I think there will be errors but not in the build time. It is likely issues will happen in the run time. You won't be able to access file systems on the client side just like how you can't access the window object on the server-side.
In my current project, we have utility functions for both the server-side, client-side, or universal. All server-side functions are called in getServerSideProps to make sure they work as expected. All your server-side code in getServerSideProps will not be imported as part of the client-side bundle if that's what you mean by "dead code". According to the Next.js
Note: You can import modules in top-level scope for use in
getServerSideProps. Imports used in getServerSideProps will not be
bundled for the client-side.
This means you can write server-side code directly in
getServerSideProps. This includes reading from the filesystem or a
database.
I'm not aware of a way you can ask webpack to bundle part of the file or execute a subset of import statements.
I hope that provides some help.
Reference:
Docs - getServerSideProps
Custom Webpack Config