qwik: [🐞] When try to load component dinamically via import I get error

@mrclay If the dynamicity is not about the on-demand loading but the programable loading by name as here, then I think it is still relevant

Yes, the above is possible with caveats.

1. During build time, the qwik build system needs to have access to all components so that it can generate symbol IDs for it.
2. There needs to be a hashmap (could be on the server) that maps the name to a component.

Here is one way to do in Qwik: https://stackblitz.com/edit/qwik-starter-j55lca (but depending on your requirements it may be done differently)

import { Component, component$, useSignal, useTask$ } from '@builder.io/qwik';
import { server$ } from '@builder.io/qwik-city';

export const getComponentFromDB = server$((name: string) => {
  return {
    cmpA: CompA,
    cmpB: CompB,
  }[name];
});

export const CompA = component$(() => <span>A</span>);
export const CompB = component$(() => <span>B</span>);

export default component$(() => {
  const Comp = useSignal<Component<any>>();
  const name = useSignal('cmpA');
  useTask$(async ({ track }) => {
    const compName = track(() => name.value);
    Comp.value = await getComponentFromDB(compName);
  });
  return (
    <div>
      <input type="text" bind:value={name} />
      <div>dynamic component: {Comp.value && <Comp.value />}</div>
    </div>
  );
});

@mhevery hey I mean the path or name of a component is read dynamically for the current user or page and I need to load it dynamically. So like mentioned by @oceangravity:

const Component  = await import(`~/components/${nameFromDatabase}`)

Is this possible with Qwik? I find that issue a lot, like if everyone is just building static sites but in big apps you need to load components dynamically based on information related to the user or a product.

@appinteractive

Sorry for the oversight, it’s actually possible to import.meta.glob without eager:true

Rectified example:

type ComponentPreviewProps = QwikIntrinsicElements["div"] & {
  name: string;
  align?: "center" | "start" | "end";
  language?: "tsx" | "html" | "css";
};

export const ComponentPreview = component$<ComponentPreviewProps>(
  ({ name, align = "center", language = "tsx", ...props }) => {
    const config = useConfig();
    const highlighterSignal = useSignal<string>();

    const componentPath = `/src/registry/${config.value.style}/examples/${name}.tsx`;

    const Component = useSignal<Component<any>>();
    const ComponentRaw = useSignal<string>();

    useTask$(async () => {
      const highlighter = await setHighlighter();

      Component.value = (await components[componentPath]()) as Component<any>;
      ComponentRaw.value = (await componentsRaw[componentPath]()) as string;

      highlighterSignal.value = highlighter.codeToHtml(
        ComponentRaw.value || "",
        {
          lang: language,
        }
      );
    });

    return (
      <div>
          ...
          {Component.value && <Component.value />}
          <div dangerouslySetInnerHTML={highlighterSignal.value} />
      </div>
    );
  }
);

This doesn’t seem to add much to dev server starting time and it does allow me to improve my mdx editing DX quite a lot.

So in my .mdx files,

instead of doing

import CardWithFormPreview from "~/registry/new-york/examples/card-with-form";
import CardWithFormCode from "~/registry/new-york/examples/card-with-form?raw";

<ComponentPreview code={CardWithFormCode}>
  <CardWithFormPreview q:slot="preview" />
</ComponentPreview>

where I have to add weird conditional logic with Slots if I want to pass different components (in my case I also have /registry/default, so I would have to find a way to display the right components based on user config).

I can simply do

<ComponentPreview name="card-with-form" />

And let my component handle everything for me 👌 .

@mhevery what do you think of import.meta.glob as an alternative to dynamic import? If it’s not an issue for the optimizer I think it should be presented in the docs as it can significantly improve the DX for some use cases (especially in .mdx files where there’s no typescript auto-complete).

This would require a bit more testing (especially in prod), but I can work on a docs PR if you like the idea.

@appinteractive it is possible to make a vite plugin that creates such a registry object from a directory of Qwik components. But manually maintaining the registry probably takes less time than writing and maintaining the plugin

This error happens even with no dynamic content. As long as you’ve got a back quote in the import() function, vite throw the error:

[vite] Internal server error: Dynamic import() inside Qrl($) scope is not a string, relative paths might break
  Plugin: vite-plugin-qwik
  File: <...>/icon.tsx:24:21
  24 |    const res = await import(`./icons/material/zoom_in.txt?raw`);
     |                       ^
  25 |    return res.default;
  26 |  });

It’s my understanding that if you build Qwik components correctly, there’s no reason to use dynamic import(). The in-browser runtime loads everything on-demand already.