Right now, the JS script in the page relies on a test to define if the code of an example should be runnable or not: contains search.addWidget? or /function renderFn\(\S+(, isFirstRendering)?\) {/g.test(exampleContent)?
This gives poor control over what's runnable or not, which seems magical and also lead to inconsistent experience like the new calendar guide. In this guide, we have one runnable example while the others are not. Given the context, none should be runnable in the guide.
Options could be:
I think a comment or wrapping in a class should be a good enough metric do decide whether they're runnable. The credentials done via frontmatter as in #2690 seems good to me!
Here are the solutions that I see with their pros and cons:
---
title: My guide
runnable: false
---
````
@runnable
// code...
````
We can create an extension to our Markdown parser to create a runnable JavaScript language.
````
// My code
````
<pre class="runnable">
<code>
// my code
</code>
</pre>
For now, I'd say that the frontmatter solution (1) is the easiest to implement.
@francoischalifour I agree that 1 should good enough for now and it has a superior DX.
What I meant instead of 4:
<div class="runnable">
```js
console.log('hello there');
```
</div>
Ah, got you, it works and would be easy to parse!
So we got a solution with @Haroenv idea, @francoischalifour ? 馃憤 ?
Yes! What default behavior do we want? (runnable or not runnable)
Having it not runnable by default would be annoying as we'd have to update most of the guides and docs.
Most helpful comment
Here are the solutions that I see with their pros and cons:
1. In the frontmatter
Example
Pros
Cons
2. As a comment/annotation in the code itself
Example
````
````
Pros
Cons
3. As a new Markdown language
We can create an extension to our Markdown parser to create a runnable JavaScript language.
Example
````
````
Pros
Cons
4. As an HTML Element
Example
Pros
Cons
For now, I'd say that the frontmatter solution (1) is the easiest to implement.