new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Nuxt · API · all subjects

components/nuxtisland

7 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

NuxtIsland component purpose

NuxtIsland renders a non-interactive component without any client-side JavaScript. When rendering an island component, the content is static and no JS is downloaded client-side. Changing the island component props triggers a refetch to re-render it. Global styles of the application are sent with the response. Server-only components use NuxtIsland under the hood.

NuxtIsland props

NuxtIsland accepts the following props: - name (string, required): Name of the component to render. - lazy (boolean, default: false): Make the component non-blocking. - props (Record<string, any>): Props to send to the component to render. - source (string): Remote source to call the island to render. - dangerouslyLoadClientComponents (boolean, default: false): Required to load client components from a remote source. Remote islands require experimental.componentIslands to be set to 'local+remote' in nuxt.config. Component props and context are sent as GET query parameters to enable caching, which may be visible in server access logs, CDN caches, and HTTP Referer headers. By default, component islands are scanned from the ~/components/islands/ directory.

NuxtIsland security warning for remote source

Using the source prop to render content from a remote server is inherently dangerous. When specifying a remote source, you are fully trusting that server to provide safe HTML content. The remote server can inject any HTML, including potentially malicious content. Only use source with servers you fully trust and control. The dangerouslyLoadClientComponents prop controls whether to download and execute client components from the remote source. Even with dangerouslyLoadClientComponents disabled (the default), you are still trusting the remote server's HTML output.

NuxtIsland ref methods

NuxtIsland exposes a refresh() method on its ref with the following signature: - refresh(): Promise<void> - force refetch the server component by refetching it.

NuxtIsland events

NuxtIsland emits the following events: - error (parameters: error of type unknown): emitted when NuxtIsland fails to fetch the new island.

NuxtIsland useId limitation

Each island is rendered in its own Vue app on the server, so Vue's useId counter restarts for every island. IDs generated inside an island can collide with IDs generated by other islands on the same page or by the rest of the app. A workaround is to set a distinct idPrefix on the island's Vue app from a server plugin based on the island context id. However, identical islands still share the same IDs when rendered with the same name, props and context, resulting in duplicated ID attributes in the DOM. Additionally, useId does not work in interactive components inside islands because components loaded with the nuxt-client attribute are server-rendered inside the island's app but hydrated by the main client app, causing a hydration mismatch.

NuxtIsland useId workaround example

To work around useId ID collision issues in islands, create a server plugin that sets an idPrefix based on the island context ID: ```ts [plugins/island-id-prefix.server.ts] export default defineNuxtPlugin((nuxtApp) => { const islandContext = nuxtApp.ssrContext?.islandContext if (islandContext) { nuxtApp.vueApp.config.idPrefix = `${islandContext.id}-v` } }) ```

Give your agent this brain