JS Nation

JSNation 2022

Full Stack Documentation

Rich Harris

React Finland

React Finland 2021

Opensource Documentation—Tales from React and React Native

Rachel Nabors

TS Congress

TypeScript Congress 2022

TypeScript for Library Authors: Harnessing the Power of TypeScript for DX

Daniel Roe

React Advanced

React Advanced Conference 2021

The Legendary Fountain of Truth: Componentize Your Documentation!

Hi everyone, nice to have you here. Welcome to this session about documentation in a component-driven development era. So we're going to talk about documentation as a key success of your project. I mean, nevertheless you are working on a library, a single component, a whole design system or a final interface of an application. Your documentation is the key to the success of your project because without a proper documentation, no one is going to have a single clue about how is it working and how you are supposed to use your project or use any parts of your project. So you have to keep your documentation properly associated with your code. Fact is, leaving documentation is a pain today just because if you have to duplicate your code from your code base to your documentation, you obviously lead to a desynchronization at some point of your documentation versus your code base. So you have to keep them in sync. If you want to be ready to just simply use and sustain your documentation in time, so to have your project ready to be used by anyone in the past and in the future. So we tried many things to keep things organized between your documentation and your code base. We tried things like Storybook, we tried things like Embed, ERPL in your documentation by itself. We tried many things, but the real truth is that we need a single source of truth. And this single source is your code base by itself, not your documentation, not your examples that will be outdated at some point. You need something that is definitely the single point where everything leaves and this is directly in your code base. So we do have to do something to keep the documentation in sync with the code base. And we do need something to embed your code base in your documentation. So just a reminder about the DATX's framework. This is a documentation framework that many companies are using right now. This documentation framework is oriented in four parts. All these four parts are the dedicated parts to your documentation. And all you have to do is split different elements of your documentation in the same area. So first entry is the readme's. Readme's are the entry point of your documentation. When a user is coming to your new documentation and doesn't have any clue where to start, the readme's are the correct entry point. There are something like getting started guys, this kind of stuff. Something where you can replay all the time the same path and the same steps in your development process and you will have the same result at your hand. This is the really good way to just put your hands in your project. The second part is the O2's. The O2's are more guides or recipes and they are dedicated at how you want to work with this part of the project. How can I embed my project in a React app? How can I use my library with this kind of backend and so on? So the guides presume that you have a preset and in this particular preset, there are guides, there are different recipes on how you could use your project in different aspects of the development. The third part is the FAQ's. You have all the discussions, all the histories. Why is this project of this choice, this particular use of this tool or this preset and so on. This is where all the history of the project is living and it helps to understand why did we choose this particular setup at some point. And it helps to understand how everything interacts together. Then the final parts are main pages in the Unix era or more specifically advanced documentation about a dedicated part. How this component is working, how this library is using at some point in the project. And this is a comprehensive guide of particular deep technical content. So these four parts are attached to four different areas. Readmes and O2s are the practices points. Each time you are asking, okay, I'm working on a new part of documentation and I want to add some new content in it. Which topic is it related on? If it's related to practices, then this is the right point to have a look at. So is it something like an entry point, like a getting started stuff or is it a guide dedicated to more different access in the specific area of specific parts of the development process? So readmes and O2s, this is practice. Where the facts and the main pages are more dedicated to understanding the project and the base of the project. But the readmes and the FAQs are also the learning parts where you are learning how it is working and why it is working this way. Where the O2s are more dedicated to and the main pages are more dedicated to where I want to use the project. Which part do I have to keep an eye on? Is it on the O2s? Is it on the main pages? I am looking for a deep dive technical content or I'm looking to a dedicated guide on this particular topic because this is what I am looking for at this point. So when you have this framework in mind, you are working on a well-fitted documentation for any kind of project. So I do recommend you to keep an eye on the Ataxis framework if you don't know it right now and to try to stack your documentation to it because this is something really, really useful in your everyday work. But we are now working in a component-driven development area. So in this environment, I'm working on components more than any other parts. And this component-driven development brings us a new way to develop and to sync our application because it involves faster development, a simpler maintenance, better reusability, better CDD because every part of your application is separated in small parts, in small components. And when you split your whole front-end interface in components only, then you are able to work on all parts that are isolated in your application. And you are able to just extract your content and to have it running isolated in a sandbox environment. And in this sandbox, your component could be easily maintained, tested, and documented. And this is the part that we are looking for right now. So in this Diataxis framework, with a component-driven development era, how could we mix them all to get the most of the two worlds? What is really interesting is that when you are working like that, this is really easy to extract your component from your application and to put it in a dedicated sandbox, working in it, making some tests, making some live use of this new component, and having it available to be embedded in different parts, different era of your documentation. So your documentation can now be fully exhaustive on why is it working like that, how is this component really useful, how could we really rely on this component in this particular context and so on. So in my Diataxis framework, putting some stuff dedicated to my component in the guides of the READMEs and the O2s and so on is really, really useful because it's easy now to understand, where I could put my documentation for this particular part of my application that is this component, my dropdown, my gallery view, my hero, my button. This is exactly how I want to perform my documentation because when I am looking for a new documentation on a project, what I am looking for is, okay, what are the different components available in my library, how could I use them, how could I make them all, how could I plug them all to just interact between my components, how could I use them in React, in Vue, in Vue Is Veld, in whatever you want. So this is exactly how we have to twist our mind to just put the documentation related to a component in the right parts of our overall documentation at all. So with that, we are now able to play with the docs live because we could embed our components that is properly isolated from our final application in our documentation at hand. So it's really easy now to just play in our component in a sandbox with this component in our documentation, play with it and just try it, test it, have some kind of experiment, like it at some point. But this is not, it is no matter just because you could use your component in a dedicated area that is a living documentation. So we need to mix this component in our documentation, import it in our documentation and having it lively in here. So how could we do that right now? This is the answer brought by the MDX environment. So MDX is Markdown, but a glorified Markdown. So writing your docs. Right now you are probably using Markdown to write your documentation. This is just syntactic sugar on HTML. You probably know Markdown because it's almost everywhere right now from GitHub to any CMS or documentation platform or document production platforms. So it's a really simple syntax, easy to read, easy to contribute, even if you're not technical at all, because this is just writing text with some kind of markups that is just simple characters. So it's not that complex. It's compatible with any text editor. It's really simple to use, but it's too simple to use with really complex document. I mean, with Markdown, I can't handle my component in it. So I have to do some stuff. Okay, I can embed HTML right in my Markdown, but it's not enough. I need something more advanced and I need something more useful when I want to work with it. So this is why we have now the MDX syntax, and the MDX is just JSX embedded in Markdown. Or more than that, this is Markdown converted to JSX that is now converted to HTML. So this is a step more between the Markdown and the HTML in the rendering process. This is not just linear from Markdown to HTML, but this is from Markdown to JSX to HTML. And in this environment, when I'm working on my Markdown, in fact, I'm working in a JS or more a JSX document so I can import, export any kind of document in it. I could write Markdown in it, but I could also put my document, my component in my document right now in the end. And this is now embedded in my Markdown. And this is rendered in my Markdown at the final process. So this is really useful because now we have components in Markdown directly. So under the hood, this is just the standard Markdown level with the JSX native syntax all mixed together. We could embed external components. We could embed function rendering and external function rendering. We could pass props. We could have TypeScript native support. We could have anything that we are used to with JSX, but directly in our Markdown. Because in the final steps, this is just a rendering process where I have a Markdown syntax, an MDX syntax. Then this is converted to an AST. This is a JSX AST. Then this JSX AST is converted to an HTML AST. Then this HTML AST is converted to HTML. So this is just a process of different conversion. And this is exactly what we are looking for. We now have syntax, Markdown syntax that is flexible enough to be used to embed any kind of component. So I got a simple MDX layout. I could embed any props in it, any components in it, and I could render anything that I want. That is a regular JSX syntax or a regular Markdown syntax and mix them all. So we now have different environments that are ready to embed the MDX. MDX is really simple. This is just adding a single line of configuration in your webpack config or your webapp config. So this is really easy to do. This is not a complex setup to have. But we now split this environment into two worlds. We have in one side the naked tools that are ready to embed the MDX. I could do MDX with any kind of static generator, from Gatsby to React Static to whatever you want. I just have to embed my MDX configuration in my webpack or webapp, and everything will work freely. But this is totally naked in the sense of I don't have any preset. I don't have any layout, any playgrounds, any props, more on that later. So you do have to do anything that you want by yourself. You are totally free. This is completely flexible. But this is a lot of work at first just to have something working and documentation working. But this is really, really handy if you just want to produce a Magdon with JSX syntax. On the other hand, you have documentation-oriented solutions that are embedding MDX at first and that are providing any kind of tools that you need to embed your documentation at some point with proper layouts, proper props table, proper playgrounds, and so on. This is a solution like Storybook with native support of MDX pages or WD. It comes with more constraints because this is a documentation framework. But this is really useful. What you are looking for is producing documentation and just not producing Magdon with components in them. So if you are looking for a documentation solution, I do encourage you to have a look on documentation tools oriented like Storybook, Dougsy, and so on with MDX native support in them because they are producing every way they give you anything you need to just produce your proper documentation with them. Now you have to organize your project. When you are working on a documentation that is related to components, this is common sense that embedding the documentation in the component itself rather than having a documentation that is decorated from the components. So you have to embed everything in there. This is the Backlight view. Backlight is a tool that we are working to at DeepRiot. This is a design system editor. So it's totally components-oriented. And each part of the interface of separation of concerns oriented to components. So when I have my components, I could write my code in my components. But more specifically, I could have my stories, my tests, my documentation, my design tools, everything is embedded in my component. So I have top one where I have a big readme or a big overview of my application. That is my top components, finally. And each time I want to have a documentation related to a dedicated component like my button, I just have to go in my button, open the doc folder in my component folder, that is my button folder, and in my documentation folder, I have everything related to my component, to my button, written directly in my DOM with JSC support in MaddX. And with this MDX syntax, I could import my button directly in my documentation. Let's see how. So we have JSX components. They run in isolated environment that reacting on the wrapping environment of our components. So I just want to embed everything in the same way. So how to work with them with your home playground? Fact is, MDX is too low-level. You need something more advanced to work with them. I talked about playgrounds and table props. So playgrounds are finally some kind of sandboxes I could use to directly render any kind of components directly in my documentation. So with my playground, I could write my component or embed it directly, and my playground will be ready to extract any part of it to my rendering process. I could have a single view, a single import of my components, and I could have it in the rendering view, the compile view, an EST view, whatever I want. And this playground allows me to just have one import in my MDX, and this is rendering every part of my different views of my components and what I want. Another thing is the props table. Because my component is coming with different props that allow me to customize it, I want to have them directly in my documentation to see how my component is supposed to work. So this is a kind of reflector for component properties. This is auto-build with any kind of properties that I could expose from my component. So this is up to date because all I had to do is just to put something like, give me the props table of this component, and everything is working. This is the view of the storybook props table system. This is just a single line. You just embed a single component that is a reflector of my component. And in my documentation, I have access to any part of the properties of my component at all. So this is really handy if I want to have it. Then you could code from your docs. You could import your component that you want to document. You could write your Mac down as you are used to when you are working in documentation. Then you could embed any kind of elements related to this component. Description, the playground, the props table, everything will be in the single line, aligned with my code because the documentation is not decorated for my components right now. It embeds my component in it. So finally, MDX plus component stories format plus playgrounds plus props table. Boom! This is the best world. You could just have a documentation that is totally related to your components at all. So how to migrate to MDX? You're probably already working on the documentation in the Mac form. So you don't have to add up anything. You just have to organize your documentation from the ADDX framework to your different components. So have it properly isolated, each documentation to each component at the side. Then you could pick your right tool or a naked or a documentation framework tool or a documentation platform. Then you could start to play with your components. And that's all because MDX is just paving the way. This is just the first tool of a new era. And I'm pretty sure that we will have a lot of other formats and a lot of other tools to embed our documentation and improve our components or Yanti documentation. But writing documentation outside of writing is just nonsense. We do have to embed our code in our documentation. And this is the premise of the MDX format. This is what we are looking for. You do have now to focus on advanced and integrated dev tools rather than just reinventing the wheel at some point. You just have to be focused on what you are looking for. This is exactly what we are doing with the tools we are working at DevRiot, like Backlight, of webcomponents.dev. If you have any questions, we will meet in a Q&A session just right now. For everything else, thank you very much. I'm Mads, I'm a principal developer advocate at DevRiot, where we're working on document and components-oriented solutions like webcomponents.dev or Backlight.dev. So that's our design systems-oriented IDE in your browser, directly in your browser, with anything you need in it, like documentation process with MDX, playgrounds, props, table, and so on. Have a look at them. Thank you very much.


m4dz 🥑🦄

Your Second Source of Truth

Okay, so a little awkward. I'm totally crashing these lightning talks and I've disrupted the chain of events that should play out. I don't even know how long I'm supposed to be talking. So if I go on too long and I am in my old age telling far too many stories, you are welcome to just start shouting, we're very bored, please get off the stage now. I will do that. But I will try not to take up too darn much space today. Hi, there. I'm Rachel Neighbors, documentation manager for React and React Native and Relay, who is also a part of the React family, although he may not have heard of it, you know, at GraphQL, anyway, that's for a future talk. And today I've come to chat with you a little bit about something that, well, a couple of things. First off, I don't know if you noticed, but we just kind of had a whole year of dead air. Like, I mean, what was that? My concept of time has completely gone out the door, hence why I might run a little long. But there was actually something I wanted to share with you before the pandemic wiped out all the talks and all the conferences, and that is what I'm here to talk with you today about. Documentation as your second source of truth. There's a little project back in 2019 with React Native, and I want to tell you a little bit about it. But first, docs. Your first source of truth is your source, of course. Your first source of truth is your source code, of course. But very few code bases can be read through in one hour. I remember the era of jQuery where you could learn JavaScript and jQuery by reading the jQuery source code. If only we were so lucky today. So your first source of truth might be your source code, but you're going to need a second source of truth. And the next best thing is your documentation that shows how all these different pieces work together and how people can implement them and work with them and build things, et cetera. Because otherwise you don't have time to read all the source. That is not the right animation. Oh, well. Carry on. We're getting back into the groove here. I'm surprised that the emcees have still got it, even though they've been off the air for like a year. Like, dang. Let's see if I've still got some, too. So when I first joined the React team, I had the task of taking React Native, React Natives and a lot of React Native folks here today, and its documentation site, and making the docs rock even more. It was a fun project. User testing. I used to be a UXer back in the day, so I start all the projects I get assigned with, like, let's talk to real people. And these conversations revealed that, you know, we needed more refresher material on React, learners wanted more visual content, we lacked in-depth content on some specific specialized topics, our high traffic component and API documentation needed a little update, and people kept saying we want more interactive code. When can I run these examples? I'm not going to set up an Android SDK. I'm an iOS developer. Come on. All right. We also learned a little bit more about our audience and things we didn't know before. For instance, 41 per cent of React Native developers, they come from a mobile background. Some folks, they didn't have any background in anything before they came, or even web. These were very interesting people to talk with. And it also made us realise that, you know, probably should build in things like literal context switchers to speak to people from different backgrounds. Before we were like you probably know React, here's React for your mobile device, which was cool except for people who were already developing from mobile and didn't know what React was. So nice, took care of that. We added these really cool interactive examples everywhere to get people up and running, React refresher to introduce them to reintroduce folks to React really quickly which kind of inspired a future project we will get to in a moment. And because the docs, well, they weren't automatically generated, that meant driving an entire community drive to update the documentation which was a lot of fun because people really want to get engaged in their favourite project. Sometimes these projects are so far matured, there's no more low-hanging fruit, but there's still a way to participate in contributing to documentation. So we got everything back up to date, we brought in some experts as guest writers to patch up places where we needed some deep dives, added colourful illustrations that turned out to be very popular. And since rebooting React Native's documentation with the new content, we saw a 70 per cent increase in, you know, thumbs-up metrics across the board on the page. That was really nice. It felt great. So bad documentation can lead to bad developer experiences. It makes it hard for devs to get from good to great, and it makes it even harder for them to teach others, to spread the word about the thing that they love and that they've found. For instance, big communities need great docs. 86 per cent of React developers, they've learned using the documentation at React.js.org. That's kind of incredible. React.js has been investing in its documentation since day one, and people often say that the docs were where they first got into UI development in the first place. So you think, well, with that kind of power, you should spend a lot of time on your documentation, investing in your second source of truth to empower your community to build out an entire ecosystem of reliable up-to-date content to teach each other, to dive deep, to build on top of what you've made, and to trust that what they're teaching is true and correct, and something they can build a career or community or a training course or boot camp off of. That's scaling knowledge. And we're putting these lessons from before the pandemic, the things that we have learned from React Native and from the React community and what worked with the React.js docs, we've been putting them to action over the past, well, since the before times. And today, we want to share with you a little sneak peek of what we've been working on. This is super, super beta, but if you go to beta.reactjs.org, you can see the latest iteration of the React documentation. We would love to know what you think about it. There's places on the site for you to leave feedback, and we really hope that we hope to hear from you. If you like it, that's awesome. If you don't like it, tell us why. We're waiting for your feedback. Thank you, and welcome back. Thank you. Thank you.


How to structure, style and document your components for maximum effectiveness

Dragos Bilaniuc

Documenting components with stories

Michael Shilman

The Story of ReScript's Documentation Platform

Patrick Ecker

React Summit

React Summit 2020

Smoothly Inclusive Component Library Documentation

♪ Hello, my name is Kathleen McMahon, and I'm here today to tell you how Gatsby and NDX makes your component library documentation smoothly inclusive. Before we begin, let's get some details out of the way. My slide deck will be posted unnoticed, including links to resources that I briefly touch upon. The full URL will be available later today on Twitter. But for now, if you want to download, if you want to take a look, you can look at https://noti.st/.resource11. You can also find me at resource11 on Twitter, Instagram, and GitHub. Before we dig into Gatsby and NDX, let's back up a bit so I can introduce myself a little bit better. I'm a principal engineer at CarGurus, and I race bikes very badly. Mostly you'll see me in costume racing two laps to your six at the back of the pack on a single speed bike. Mostly. Unless something happens. Like a pandemic kicking in our doors. Then your racing season is postponed. So while I'm an engineer and a super slow bike racer, I am a super fan of design systems, especially the component library parts. Before CarGurus, I was a tech lead for the O'Reilly Media Design System. While I was there, I learned a lot about streamlining component libraries and optimizing documentation. If you've never worked on a design system before, let's just say there are a lot of moving parts. And if your core team is small and you are rebooting your component library, you really have to choose your focus and rely on your contributors. In our case, our focus was to extract the business logic out of our components and get the accessibility in. We fixed our colors, our components, our patterns, and rebooted our docs. Once that was done, we realized that part of our system was becoming a hindrance to our team and a barrier to entry for our contributors. Our documentation. Our process was spread across two projects, the design system repo and the design system docs repo. In the design system repo, the documentation content was stored in two locations, while the docs repo held the site scaffolding and the docs layout components. To get up and running, you had to follow a detailed series of steps to sync, run scripts, grab files, parse information, generate data, and render the docs into a React app. That's a lot. Just getting started working with these repos was overwhelming for new contributors, to say the least. And there was more. The scripts were set up in such a way that you had to write your markdown in a very specific order for your component and your content to show up in the docs. Your button heading could be paired with an intro paragraph, but only one paragraph. Same with the variants, only one paragraph, and then a code block. Best practices had to be written as an unordered list, always. Same with the related component section, always an unordered list. So while our docs scripts were great for generating color swatches and details about which props were available in components, the process was not great for creating our component documentation. Which frustrated everyone. One mistake and if not whole chunks of documentation would be missing from the component pages. We had the freedom of using markdown, yet we were not taking advantage of it. This was a serious cognitive lift, even for someone who was very familiar with the code base. Now imagine if you have a new contributor to your project, not exactly a welcoming experience. We decided to review our process and see what wasn't working. One of our biggest issues, we chose to show one component variant at a time, rather than all at once. This forced our users to access a select menu over and over again to compare component variants, which increased the time they needed to look up information. It didn't make sense. In retrospect, that decision was about as questionable as a recipe that combines Jell-O with shellfish. So we decided it was time to make our docs contribution process more user friendly in terms of structure and in terms of how we authored. Especially the component example pages. We wanted the users to have the confidence that whatever content they wrote on the docs page would make it into that docs page. If we made our docs more user friendly, we'd have more contributors rather than fewer. We considered our options for making our docs better and decided upon Gatsby for a few reasons. One, Gatsby gave us a way to migrate all our main documentation pages right into the site without much fuss. Two, Gatsby provides a web pack and Babel config similar to create React app. So we could start with a scaffolded project and extend as needed. And three, Gatsby supports MDX. So we could write component documentation using Markdown, import React components right into the file, and it just works. Even better, MDX compiles down into semantic HTML, which in turn gives the site improved accessibility. Better support for users that rely on assistive technology to access the docs. If a design system is promoting inclusivity in general, it really should. It follows that inclusive docs make sense. As a bonus, Gatsby restreamed our site from two repos to one and reduced the amount of CLI commands dramatically. The default setup for Gatsby is great. However, we needed to make some adjustments so Gatsby worked for our needs. In the Gatsby config file, we added Gatsby plugin post CSS to support post CSS. Gatsby plugin compile ES6 packages to support our design system package. Gatsby plugin MDX so the site would recognize MDX files. Gatsby remark auto link headers to generate auto links for page headings for better screen reader and keyboard support. Gatsby plugin page creator to create pages from the source pages folder. And Gatsby plugin file system so we could pull in our data file and point Gatsby to the folder where all our component MDX files lived. In the Gatsby node file, we added a GraphQL query to find the component MDX content and a create page action to route and pages for the component docs. In the Gatsby browser file, we added things we wanted to apply throughout the site, like our global CSS styles and the wrap root element component. The wrap root element component acts as a wrapper around the site's root element and imports the MDX provider. This way, the entire site would recognize MDX content. We had to do one extra thing for our component docs page template, though. Since our component MDX files were located outside of source, MDX renderer was needed to wrap the contents of our component page template. Otherwise, MDX files would render like this in the browser. Now that our layout template used MDX renderer, our component MDX pages would render as we want in the browser. Now we could pop in React components next to code blocks in our MDX, and they would render, no problem. We could even wrap a button component with a display box component and add a more cohesive look to the component code block pairing. If we wanted to add a props table to show which props can be used with the component and created a component that pulled in data to render as a data table of a props table component, pop that component into the docs MDX file, I can speak today, passed in the name of the component to render, voila, the docs would show a props table. For our component dos and don'ts, we used to have to write out an unordered list in the markdown file. And the links and the list rendered like this. With MDX support, we instead created a custom component that renders unordered lists. We could pass in a dos list and a don'ts list array into that component. And boom, a nicely styled dos and don'ts list. Code blocks. Markdown has great code block support. MDX makes those even more powerful. So we were psyched to add this feature. You can override the styling of a code block in an MDX file with a custom code block or even display different types of code blocks. You can use Prism React Renderer in a custom code block component and import a theme with good color contrast like Sarah Drasner's night owl theme. Then you can wrap your code block and theme it, import that code block component into your wrap root element along with the pre-code block utility, and override the default pre-tagged styling at the app level by passing it in as a component to the root wrap element. So now when you write a code block in MDX, instead of the baseline styling, the custom code block will render with syntax highlighting. Fun fact, you can pass in a prop to that code block and do really cool things if you use custom code blocks. For example, if you abstract this MDX into a dryer pattern in our custom code block component and pass the display box prop into that code block, if you add the display box prop to the code block in MDX, you'll get a code, you'll get a display box paired with a code block. Now, what about if you want your code block to be an editable code block? You can add a React live option to the component and show the component inside a display box pairing with an editable code block. So if you add the React live prop to your MDX code block, you'll get an editable code block and see your changes in real time. So if we write something like this, where we have three code blocks in MDX, one with the React live prop, one with no prop, just the name of the language, and the third one with the display box prop passed in, this is what you will see. So over here is I comped up a quick MDX file in my blog site to demo. If you pass in, this one is the JSX with the React live prop passed in. This one is with just JSX passed in as the code, and this one is passing in the display box prop to the JSX code block. What is great about the one with the React live prop is we are combining the display box fanciness and the block here, but this is now editable. So I can do things with it, and if I know what props my component supports, I could make this button. If you look at there, it actually has error handling, but small button, wow, and I could also, I know I support icons, so the icon I could use is the right arrow, because I'm using React font awesome components under the hood. Look at that, I just added a icon to my button, but this, adding this type of editable block, editable React live support to your code blocks is very powerful, because your developers will be able to go into your component, into your documentation, and play with the properties right there and understand how to use your component right away, versus having to try, you know, look through all your props tables. This is another way for learners that need to type things to see how things break. So editable block component, editable code blocks are amazing. Now, I'm going to go back to the slides and wrap this up. So, to wrap up, if your documentation setup is brittle, your contributors will flee. But Gatsby and MDX helps make your docs inclusively smooth in both setup and execution. And your contributors will return. And they will be happy to be part of your team. Thank you. ♪♪♪


Kathleen McMahon

#documentation