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. 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.
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.
It seems to me that this is nearly universal among nontrivial front and projects. Each one, through its build configuration, has a slightly different subset of all the language features supported by the current crop of JavaScript derived languages.
I believe this is a much underappreciated risk, that some projects will pay a significant price for, a few years from now.
We are managing it on our projects by preferring TypeScript, which appears to be advancing forward at a healthy yet careful pace, and which offers some configurability of the exact meaning of the language (in the form of settings in one file), yet does not offer unlimited arbitrary combinations of add-ons.
(That said, the Babel ecosystem is amazing, with lots of very interesting work by very smart people.)
It don't know what you mean, but it's certainly avoidable. You can do a few things:
* Only use language features of the browsers you are targeting. If you are targeting evergreen browsers (not IE) you can use most of ES2015 including classes, arrow functions, and template literals.
* Or use a transpiler but stick to some sane judgment of presets, preferable Stage 3 or greater, but at least stuff that's on the standards track.
* Don't use stuff like this: https://www.npmjs.com/package/babel-root-import that exists only to save yourself a couple of keystrokes.
Why is this not a component?
as in:
<Markdown> Text </Markdown>
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.
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
I don't know whether it's a good idea, but I like it so far.
Original - http://coffeespace.org.uk/loader-orig.js Minified - 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.
