5 ms·

Markdown-in-js: inline Markdown for React and JSX

84 points by kylemathews 10y ago

andreasklinger 10y ago
Maybe a stupid Q - i assume there is a good reason - most likely related to syntax clash… Why is this not a component? as in: <Markdown> Text </Markdown>
- tlrobinson 10y ago
  Looks like it's advertised as "zero-overhead", i.e. it gets compiled by Babel at build time. Not sure it would make a big difference for most apps though. I think more importantly it allows you to use JSX inside of your Markdown, and use custom React components in place of normal HTML elements that Markdown would normally emit. I like the idea of a <Markdown> component though.
  - LeanderK 10y ago
    i am not really into this stuff, but would this be a good use for http://webcomponents.org http://webcomponents.org?
    - svachalek 10y ago
      It would not be hard to create a web component that translates markdown at runtime; there are probably a few in there already. But that's a very different use-case than transpilation. Personally, I don't see much need for handling this at compile-time, but it is what it is, and runtime rendering is a different thing entirely.
- Goosey 10y ago
  There already exist multiple Markdown components, for example https://github.com/rexxars/react-markdown https://github.com/rexxars/react-markdown The interesting thing here is that it is inline. edit: No judgement if being inline is a pro or a con. Personally I prefer to keep it in a specific component, but I see the appeal fo this
  - svachalek 10y ago
    If it was passed as "children" rather than a named prop, it should look pretty similar. It just wouldn't be pre-compiled.
true_religion 10y ago
Is there a demo?
nathancahill 10y ago
I'm all for pushing the boundaries of syntax with Babel, but frankly this looks horrible. Is there an appealing reason to use this? I could see it being interesting to render Markdown (like from a CMS) at runtime, but at compile time there's not much benefit over JSX right?
- masterj 10y ago
  It could be very useful for docs sites, blogs, coding books. Anything where ease-of-authoring is the highest priority. You could maintain it in markdown but also inject your custom components for examples or bits of interactivity.
Touche 10y ago
This is a great illustration why using random babel plugins you find on the internet is super dangerous. This works because it assumes you have named your local identifier either `markdown` or `md` and are using that. If you want to use something else you need to specify a custom pragma: https://github.com/threepointone/markdown-in-js#pragma https://github.com/threepointone/markdown-in-js#pragma. And that feature didn't exist until 6 hours ago. Why is this dangerous? Let's imagine you use `markdown` and you chug along for another 5 months on this project and you need to use `mdown` in some file, or maybe a coworker uses `mdown` because why not? So it doesn't work. And you're confused. And you spend hours trying to figure out why your app is broke. People need to realize that by using a bunch AST transforms you are creating your own one-off language, and one that has no visual indicator that this is different in any way. It's just a tagged template literal, right? Stick to babel plugins for official language features that at least have a chance of becoming part of JavaScript. This thing is going to stop working as soon as the developer loses interest, and then you're going to be stuck with your Frankenstein language no one can understand.
- masterj 10y ago
  It's just applying a function to a tagged template literal at compile-time instead of run-time, but it doesn't change the semantics of the language. Calling it a one-off language is hyperbole. Think of it as a compiler optimization step. You bring up a good point with the hard-coded name though. Instead of hardcoding in the pragma it should probably check the name in the require. This wouldn't be difficult to add, and the project is only two days old.
  - Touche 10y ago
    It's not a compiler optimization step. Your code will through without the plugin: https://github.com/threepointone/markdown-in-js/blob/master/src/index.js#L3 https://github.com/threepointone/markdown-in-js/blob/master/...
- phpnode 10y ago
  Here's a PR that fixes this issue - https://github.com/threepointone/markdown-in-js/pull/2 https://github.com/threepointone/markdown-in-js/pull/2
threepointone 10y ago
Hi folks, author here. I wrote this for myself for a docs site I'm building, and didn't want to ship a markdown parser to the browser. It's mostly for aesthetics, without sacrificing performance. Custom components for primitives are a nice addition, especially for styling. I don't know whether it's a good idea, but I like it so far.
- tracker1 10y ago
  I'm pretty happy to see it... IMHO, this is actually a great value add for React, as when typing longer text, I'd rather use MD more often than not... I wish that common markdown was closer to gfm, but to each their own. Still a nice thing to have.
- bsimpson 10y ago
  Sunil is legit.
bArray 10y ago
Slightly related, I wrote some basic JS a while back to convert a page full of markdown into HTML client side, without locking up the client: Original - http://coffeespace.org.uk/loader-orig.js http://coffeespace.org.uk/loader-orig.js Minified - http://coffeespace.org.uk/loader.js http://coffeespace.org.uk/loader.js Why? I don't know, it seemed like a great idea at the time to get my clients doing all the heavy lifting. Page download times are typically less than all other pages given how rich the content is.
b34r 10y ago
I made something similar: https://www.npmjs.com/package/markdown-to-jsx https://www.npmjs.com/package/markdown-to-jsx

84 points by kylemathews 10y ago

Maybe a stupid Q - i assume there is a good reason - most likely related to syntax clash… Why is this not a component? as in: <Markdown> Text </Markdown>

tlrobinson 10y ago
Looks like it's advertised as "zero-overhead", i.e. it gets compiled by Babel at build time. Not sure it would make a big difference for most apps though. I think more importantly it allows you to use JSX inside of your Markdown, and use custom React components in place of normal HTML elements that Markdown would normally emit. I like the idea of a <Markdown> component though.
- LeanderK 10y ago
  i am not really into this stuff, but would this be a good use for http://webcomponents.org http://webcomponents.org?
  - svachalek 10y ago
    It would not be hard to create a web component that translates markdown at runtime; there are probably a few in there already. But that's a very different use-case than transpilation. Personally, I don't see much need for handling this at compile-time, but it is what it is, and runtime rendering is a different thing entirely.
Goosey 10y ago
There already exist multiple Markdown components, for example https://github.com/rexxars/react-markdown https://github.com/rexxars/react-markdown The interesting thing here is that it is inline. edit: No judgement if being inline is a pro or a con. Personally I prefer to keep it in a specific component, but I see the appeal fo this
- svachalek 10y ago
  If it was passed as "children" rather than a named prop, it should look pretty similar. It just wouldn't be pre-compiled.

true_religion 10y ago

Is there a demo?

nathancahill 10y ago

I'm all for pushing the boundaries of syntax with Babel, but frankly this looks horrible. Is there an appealing reason to use this? I could see it being interesting to render Markdown (like from a CMS) at runtime, but at compile time there's not much benefit over JSX right?

masterj 10y ago
It could be very useful for docs sites, blogs, coding books. Anything where ease-of-authoring is the highest priority. You could maintain it in markdown but also inject your custom components for examples or bits of interactivity.

Touche 10y ago

This is a great illustration why using random babel plugins you find on the internet is super dangerous. This works because it assumes you have named your local identifier either `markdown` or `md` and are using that. If you want to use something else you need to specify a custom pragma: https://github.com/threepointone/markdown-in-js#pragma https://github.com/threepointone/markdown-in-js#pragma. And that feature didn't exist until 6 hours ago. Why is this dangerous? Let's imagine you use `markdown` and you chug along for another 5 months on this project and you need to use `mdown` in some file, or maybe a coworker uses `mdown` because why not? So it doesn't work. And you're confused. And you spend hours trying to figure out why your app is broke. People need to realize that by using a bunch AST transforms you are creating your own one-off language, and one that has no visual indicator that this is different in any way. It's just a tagged template literal, right? Stick to babel plugins for official language features that at least have a chance of becoming part of JavaScript. This thing is going to stop working as soon as the developer loses interest, and then you're going to be stuck with your Frankenstein language no one can understand.

masterj 10y ago
It's just applying a function to a tagged template literal at compile-time instead of run-time, but it doesn't change the semantics of the language. Calling it a one-off language is hyperbole. Think of it as a compiler optimization step. You bring up a good point with the hard-coded name though. Instead of hardcoding in the pragma it should probably check the name in the require. This wouldn't be difficult to add, and the project is only two days old.
- Touche 10y ago
  It's not a compiler optimization step. Your code will through without the plugin: https://github.com/threepointone/markdown-in-js/blob/master/src/index.js#L3 https://github.com/threepointone/markdown-in-js/blob/master/...
phpnode 10y ago
Here's a PR that fixes this issue - https://github.com/threepointone/markdown-in-js/pull/2 https://github.com/threepointone/markdown-in-js/pull/2

threepointone 10y ago

Hi folks, author here. I wrote this for myself for a docs site I'm building, and didn't want to ship a markdown parser to the browser. It's mostly for aesthetics, without sacrificing performance. Custom components for primitives are a nice addition, especially for styling. I don't know whether it's a good idea, but I like it so far.

tracker1 10y ago
I'm pretty happy to see it... IMHO, this is actually a great value add for React, as when typing longer text, I'd rather use MD more often than not... I wish that common markdown was closer to gfm, but to each their own. Still a nice thing to have.
bsimpson 10y ago
Sunil is legit.

bArray 10y ago

Slightly related, I wrote some basic JS a while back to convert a page full of markdown into HTML client side, without locking up the client: Original - http://coffeespace.org.uk/loader-orig.js http://coffeespace.org.uk/loader-orig.js Minified - http://coffeespace.org.uk/loader.js http://coffeespace.org.uk/loader.js Why? I don't know, it seemed like a great idea at the time to get my clients doing all the heavy lifting. Page download times are typically less than all other pages given how rich the content is.

b34r 10y ago

I made something similar: https://www.npmjs.com/package/markdown-to-jsx https://www.npmjs.com/package/markdown-to-jsx