qwik
qwik copied to clipboard
Strange bug conditionally rendering components with slots
Qwik Version
0.12.1
Operating System (or Browser)
Mac OS. Chrome.
Node Version (if applicable)
16.14.2
Which component is affected?
Qwik City
Expected Behaviour
This is a weird one to explain so I've linked a reproduction above. TL;DR to reproduce the error click the "edit" icon in the link above. You're supposed to see an input field with two icons to save to cancel the edit; however there is a console error about $types
. If you comment out DeletePageIcon
or wrap one of the IconButton' components in a
I have a component called IconButton
that renders a button
with a <Slot/>
, similar to MUI IconButton. It's used like so:
<IconButton>
<Icon name="icon-name"/>
</IconButton>
IconButton
:
import { component$, Slot, useStyles$ } from "@builder.io/qwik";
import type { PropFunction } from "@builder.io/qwik";
import styles from "./buttons.css?inline";
interface IconButtonProps {
onClick$: PropFunction<() => void>;
classNames?: string;
}
export default component$((props: IconButtonProps) => {
useStyles$(styles);
return (
<button class="base-button newt-icon-button" onClick$={props.onClick$}>
<Slot />
</button>
);
});
Icon
looks like this:
interface IconProps {
name: string;
}
export default (props: IconProps) => {
const { name } = props;
return (
<svg viewBox="0 0 24 24">
<use href={`#${name}`} />
</svg>
);
};
In the root of the application is rendered a hidden SVG component with the icons rendered as <symbols>
. The idea is the the use
points to the href of the symbol
. I use this icon system in most of my applications because its very performant when rendering a bunch of icons (I'm rendering a D3 force graph with a bunch of icons on it).
In my application I have a page header where the user can edit the page's title. There's suppose to be a Delete IconButton and an Edit IconButton. When the user clicks the Edit button the header title is supposed to be replaced with an input field and two different icons. Wrapping the IconButtons in divs solves the problem, but I'm not sure why.
Actual Behaviour
See above.
Additional Information
See above.