-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possibility to pass additional props to MDX custom components through the code blocks #69
Comments
This would be interesting. So like a custom configuration object to enable conditional logic, like |
Yep exactly! This would give user full control over rendering of the code fence. |
The question is what the syntax should be, especially ensuring things are kept forwards-compatible. For example, all these are possible:
Let's say we can feed the existing special syntax as props to
If we split the metastring by whitespaces, and if the library wanted to add another "unique" bit of syntax, it could break? So I guess we could add a new special config,
Which would pass Also considering this is meant to work with plain MD, I don't know if you can even pass props properly unless using |
Very true and valid points. Since the plugin's main use-case is plain markdown, adding this feature introduces a lot of complexity for little gain. I thought of something similar to your props approach initially as well where you introduce a new prop
This did work well and I was able to get the prop I think in the long run it may be better to have a MDX only plugin which can handle this somehow but even in MDX you will face this issue if you aren't using a custom component for |
Another idea would be handle this at the config level when defining the plugin. A boolean indicating whether we are using a custom MDX component for our Drawbacks with this would be when people try to mix MDX |
I had used https://github.com/remcohaszing/rehype-mdx-code-props in another project but unfortunately I couldn't get it to work in combination with |
Was it placed last?
|
Yup |
Looks like So I wrote a custom rehype plugin to add data attributes based on the meta: import { visit } from 'unist-util-visit';
export default function codeblockMeta() {
return (tree) => {
visit(tree, 'element', (node) => {
if (
node.tagName === 'pre' &&
node.children?.length === 1 &&
node.children[0].tagName === 'code'
) {
const codeblock = node.children[0];
const meta = codeblock.data?.meta;
if (meta) {
const attributes = meta.split(' ').reduce((acc, attribute) => {
let key, value;
if (attribute.includes('=')) {
[key, value] = attribute.split('=');
value = value.replace(/^"(.+(?="$))"$/, '$1');
} else {
key = attribute;
value = true;
}
return Object.assign(acc, { [`data-${key}`]: value });
}, {});
Object.assign(node.properties, attributes);
}
}
});
};
} This plugin should be included before But unfortunately this breaks when using As a workaround, I added the following after the let properties = node.properties;
Object.defineProperty(node, 'properties', {
set(value) {
Object.assign(properties, value);
},
get() {
return properties;
},
}); Super hacky but it ensures that the previous data attributes aren't overwritten. Though there's the other issue that these don't exist on the |
@atomiks thank you! i'll try it out |
Should be fixed now to use with https://github.com/remcohaszing/rehype-mdx-code-props |
Hi, currently when using MDX custom components and rehype-pretty-code, the following props are passed through to the component:
Is is possible to pass additional props to the component? For example:
Consider a code fence:
Here
copyEnabled
is custom metadata. ThiscopyEnabled
metadata should be available as a prop to the MDX custom component.This way we can conditionally control the components through markdown very easily.
The text was updated successfully, but these errors were encountered: