I'm trying to share UI functionality between two Next.js apps, using ES modules.
I'm moving away from non-SSR apps using the SystemJS module format and wanting to avoid webpack's module federation scheme, hoping that the current standard ESM support across browsers and server is enough.
Next.js 11.1 blog post mentions work "on extensive ES Modules support in Next.js, both as input modules and as an output target" (emphasis added). However Next.js 12 post seems to focus only on importing ES modules.
I've tried using a custom webpack config, enabling config.experiments.outputModule, but it only affected the server side code (generated files in .next/server/pages did become ESM - breaking the build as expected with syntax errors). Using isServer to configure only the client side code seems to have no effect (code in .next/static stays the same).
Is this unsupported or am I doing something wrong? Thanks!
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
I have a Next.js 13 app that was deployed to the Edge on Cloudflare Pages with experimental: { runtime: 'experimental-edge' }, but requirements were updated and I need to include our feature flag dependency LaunchDarkly - and retrieve the feature flags via getServerSideProps.
Inside getServerSideProps I tried launchdarkly-node-server-sdk, launchdarkly-node-client-sdk, and launchdarkly-js-client-sdk, but they either require a Node specific library (fs and others) or window.
launchdarkly-cloudflare-edge-sdk with #cloudflare/kv-asset-handler looks promising, so I followed the template, but I'm not sure how to extend a Next.js app to have this functionality. For example, do I put the worker into a middleware.ts function or somehow extend the vercel build step to include this functionality.
I haven't tested this out but I am guessing you may need to use the Cloudflare SDK throughout since Cloudflare would deploy the functions as Cloudflare Workers, which is a non-Node runtime.
In a typical Next.js deployment, you'd use the Node server SDK for any server side code (like getServerSideProps) but my assumption is that this may cause errors due to the fact that it relies upon some Node-specific APIs that I am not sure the Workers runtime supports. We (LaunchDarkly) are working on updates to our JavaScript SDKs to better support non-Node runtimes but I don't have an ETA on their release.
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.
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
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