|
4 | 4 |
|
5 | 5 | `MDXTag`, for those that aren’t aware, is a critical piece in the way |
6 | 6 | MDX replaces HTML primitives like `<pre>` and `<h1>` with custom React |
7 | | -Components. [I’ve previously |
| 7 | +Components. [I’ve previously |
8 | 8 | written](https://www.christopherbiscardi.com/post/codeblocks-mdx-and-mdx-utils) |
9 | 9 | about the way `MDXTag` works when trying to replace the `<pre>` tag |
10 | 10 | with a custom code component. |
@@ -39,7 +39,7 @@ exports.preToCodeBlock = preProps => { |
39 | 39 | ``` |
40 | 40 |
|
41 | 41 | So `MDXTag` is a real Component in the middle of all of the other MDX |
42 | | -rendered elements. All of the code is included here for reference. |
| 42 | +rendered elements. All of the code is included here for reference. |
43 | 43 |
|
44 | 44 | ```js |
45 | 45 | import React, {Component} from 'react' |
@@ -86,7 +86,7 @@ export default withMDXComponents(MDXTag) |
86 | 86 |
|
87 | 87 | `MDXTag` is used in the [mdx-hast-to-jsx |
88 | 88 | conversion](https://github.com/mdx-js/mdx/blob/e1bcf1b1a352c9728424b01c1bb5d62e450eb48d/packages/mdx/mdx-hast-to-jsx.js#L163-L165), |
89 | | -which is the final step in the MDX AST pipeline. Every renderable |
| 89 | +which is the final step in the MDX AST pipeline. Every renderable |
90 | 90 | element is wrapped in an `MDXTag`, and `MDXTag` handles rendering the |
91 | 91 | element later. |
92 | 92 |
|
@@ -171,12 +171,12 @@ wrapping `MDXTag`. |
171 | 171 |
|
172 | 172 | Now that we’ve cleaned up the intermediary representation, we need to |
173 | 173 | make sure that we have the same functionality as the old |
174 | | -`MDXTag`. This is done through a custom `createElement` |
175 | | -implementation. Typically when using React, we use |
176 | | -`React.createElement` to render the elements on screen. This is even |
177 | | -true if you're using JSX because JSX tags such as `<div>` compile to |
178 | | -`createElement` calls. So this time instead of using |
179 | | -`React.createElement` we’ll be using our own. [Check it out in the MDX |
| 174 | +`MDXTag`. This is done through a custom `createElement` |
| 175 | +implementation. Typically when using React, we use |
| 176 | +`React.createElement` to render the elements on screen. This is even |
| 177 | +true if you’re using JSX because JSX tags such as `<div>` compile to |
| 178 | +`createElement` calls. So this time instead of using |
| 179 | +`React.createElement` we’ll be using our own. [Check it out in the MDX |
180 | 180 | repo](https://github.com/mdx-js/mdx/blob/0506708bed0ac787f605b0a97ef77d1954fa1275/packages/react/src/create-element.js) |
181 | 181 |
|
182 | 182 | Reproduced here is our `createElement` function and the logic for how |
@@ -220,7 +220,7 @@ export default function(type, props) { |
220 | 220 |
|
221 | 221 | One really cool application of the new output format using a custom |
222 | 222 | `createElement` is that we can now write versions of it for Vue and |
223 | | -other frameworks. Since the pragma insertion is the responsibility of |
| 223 | +other frameworks. Since the pragma insertion is the responsibility of |
224 | 224 | the webpack (or other bundlers) loader, swapping the pragma can be an |
225 | 225 | option in mdx-loader as long as we have a Vue `createElement` to point |
226 | 226 | to. |
|
0 commit comments