You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] dcc.Markdown with a <dccLink children="..." /> does not render children #3951
Hi @KoolADE85, I'd be happy to help out on this if it's still up for grabs, or if you'd like a second pair of hands on it. I can dig into the react-jsx-parser upgrade (1.21.0 → 2.4.1) and see how the children prop handling changed for JSX-like tags. Let me know if you're already working on a fix or if you'd like me to take a stab at it, happy to submit a PR either way.
Hi @shahbhavya7, thanks for offering here!
Do you have an approach in mind? Or a use-case that you are trying to resolve? As the issue is more nuanced than it appears, we have discussed a few approaches internally but haven't landed on anything yet. If you have an idea, we'd be happy to discuss here in the ticket ahead of a PR.
Thanks for the context! I dug into how DccLink is wired up in Markdown.react.js it's registered as DccLink: props => <DccLink {...props} />, so it relies entirely on whatever props react-jsx-parser builds internally.
My guess: in 1.21.0, a children="..." attribute on a self-closing tag was passed through as a normal string prop, so the spread picked it up. In 2.4.1, the parser likely now treats children as reserved and derives it only from actual nested JSX nodes, which are empty for a self-closing tag so it overrides/strips the attribute before our transform ever sees it.
If that's right, a couple of possible fixes:
In Markdown.react.js: in the DccLink transform, explicitly check for a raw children string on the parsed attributes (if react-jsx-parser exposes them separately) and merge it back in before spreading.
Avoid relying on the children attribute at all update our docs/examples to use nested content instead (<dccLink href="...">Go to page 2</dccLink>) and treat children="..." as unsupported going forward, since it's relying on parser internals that clearly aren't guaranteed to stay stable.
I lean toward option 2 as more robust long-term, but happy to prototype option 1 first if you'd rather preserve the existing API. Which direction do you want to explore in a PR?
This appears to be an AI-generated comment that we won't engage with.
We welcome your own thoughts on this issue, and it will be easier to come to a decision if we talk to each other directly rather than through an LLM. We'll be happy to consider your own ideas in your own words.
Activity
shahbhavya7 commentedon Aug 20, 2026
Hi @KoolADE85, I'd be happy to help out on this if it's still up for grabs, or if you'd like a second pair of hands on it. I can dig into the react-jsx-parser upgrade (1.21.0 → 2.4.1) and see how the children prop handling changed for JSX-like tags. Let me know if you're already working on a fix or if you'd like me to take a stab at it, happy to submit a PR either way.
KoolADE85 commentedon Aug 20, 2026
Hi @shahbhavya7, thanks for offering here!
Do you have an approach in mind? Or a use-case that you are trying to resolve? As the issue is more nuanced than it appears, we have discussed a few approaches internally but haven't landed on anything yet. If you have an idea, we'd be happy to discuss here in the ticket ahead of a PR.
shahbhavya7 commentedon Aug 21, 2026
Thanks for the context! I dug into how DccLink is wired up in Markdown.react.js it's registered as
DccLink: props => <DccLink {...props} />, so it relies entirely on whatever props react-jsx-parser builds internally.My guess: in 1.21.0, a
children="..."attribute on a self-closing tag was passed through as a normal string prop, so the spread picked it up. In 2.4.1, the parser likely now treats children as reserved and derives it only from actual nested JSX nodes, which are empty for a self-closing tag so it overrides/strips the attribute before our transform ever sees it.If that's right, a couple of possible fixes:
In Markdown.react.js: in the DccLink transform, explicitly check for a raw children string on the parsed attributes (if react-jsx-parser exposes them separately) and merge it back in before spreading.
Avoid relying on the children attribute at all update our docs/examples to use nested content instead (
<dccLink href="...">Go to page 2</dccLink>) and treatchildren="..."as unsupported going forward, since it's relying on parser internals that clearly aren't guaranteed to stay stable.I lean toward option 2 as more robust long-term, but happy to prototype option 1 first if you'd rather preserve the existing API. Which direction do you want to explore in a PR?
KoolADE85 commentedon Aug 21, 2026
This appears to be an AI-generated comment that we won't engage with.
We welcome your own thoughts on this issue, and it will be easier to come to a decision if we talk to each other directly rather than through an LLM. We'll be happy to consider your own ideas in your own words.