Currently it picks up code fragments automatically and skips static ones (i.e. those with language defined). This isn't cool in all cases as you might want to map static to dynamic in order to preserve GitHub highlighting for example.
It would be good if there was a way to define custom mappings against languages and adjust this behavior.
You can see how Catalog does it for reference.
Catalog names custom markdown content definitions as specimens. If you would like, we can do here the same. Let's say, that here will be a new option in styleguide.config.js:
module.exports = {
specimens: {
html: (content) => {/* implementation */},
color: (content) => {/* implementation */}
}
};
By default, we are also going to enable example and html specimens by default, to make backwards-compatible behavior.
I have analyzed examples.loader.js source to check how hard it would be to implement and it seems like it needs big refactoring to accomplish this. Basically, we need to split up code evaluation logic and static highlight. Now they are both in the same module and depend on each other.
Before start actually doing this, I'd like to gather more demand from users, to be sure that it actually worths that efforts.
Related to #269
Also related to #267
I have an idea how to solve at least some of this issues:
javascript js, jsx fenced code blocks are rendered as playgrounds by default.Fist line can have a comment to change default behavior:
jsx // noeditor
<Button>Push me tender</Button>
Possible modifiers (names could be changed):
In that case specimens could be implemented as React components, like this:
```jsx // noeditor
<Color hex="#f00" name="red" />
```
Custom modifiers will be easy to support too. This also fixes an issue with syntax highlight in editors and GitHub (for some reason GitHub don’t even show the comment):
jsx noeditor
<Button>Push me tender</Button>
This will be a breaking change. What do you think?
(Thanks @ndelangen for the idea)
What will happen to non-tagged code blocks?
Nothing, I think but we won’t recommend them anymore. Will make transition easier.
Non-tagged code blocks can't have comments, because if the parser can't know the language, it can't know the syntax for comments.
Just tag your code blocks 👍
I guess you could just assume the syntax is // comment-here.
@ndelangen Non-tagged code blocks is the current way of writing comment, we’ll leave them as is and change the behavior of the fenced ones ;-)
Awesome news, we have an implementation from @stepancar — #511. I’m not sure how flexible (read complex) the API should be so feel free to have a look and leave you comments on the PR.
🍕 6.0.0 beta is out!! 🍕
🍕 6.0.0 is out!!!! 🥓