Learn Gulp, Mdx and Nightmare

MDX has grown rapidly since the first commit two and a half years ago. We'd like to celebrate our accomplishments so far, and talk about what lies ahead. We've got lots of plans.
Learn how MDX increases developer productivity, improves educational content authoring, and even peek behind the curtains to see how MDX works.

MDX is an authorable format that lets you seamlessly use JSX in your markdown documents. You can import components, like interactive charts or notifications, and export metadata. This makes writing long-form content with components a blast.



MDX Conf 2020

Gulp is a toolkit for automating painful or time-consuming tasks in your development workflow, so you can stop messing around and build something.

gulp

Building upon the `watch` task that we begin this lesson with, we’ll look at how to create a local development server using the `app` directory as the web root. By using Browsersync to achieve this, we can also instruct all connected browsers to automatically reload each time our bundle is re-generated. Browsersync has a public `.stream()` method that is designed exactly for this purpose.

Gulp and Browserify - Adding Live Reload with Browsersync

Nightmare is a high-level browser automation library.

The goal is to expose just a few simple methods, and have an API that feels synchronous for each block of scripting, rather than deeply nested callbacks. It's designed for automating tasks across sites that don't have APIs.

nightmare

Many pages you'll want to grab data from will require you to log in first. This video demonstrates how to log in and grab whatever data off the page you will need.

Scraping Data from Sites with Login Forms with Nightmare

Babel has support for the latest version of JavaScript through syntax transformers. These plugins allow you to use new syntax, right now without waiting for browser support.

babel

What is already a nice workflow using Gulp, Browserify, Watchify & Browsersync to enable auto rebuilds & live browser reloading can be further improved by adding Babelify. A simple wrapper around the popular transpiler Babel, Babelify can ‘transform’ source files as they pass through our stream to enable certain Javascript features not yet available in the Browser or Node. We end the lesson by looking at how to generate & extract sourcemaps using `exorcist`.

Gulp and Browserify - Adding Babel & Source Maps

Many websites have more than just simple static content. Dynamic content which is rendered by JavaScript requires browser to be able to scrape data. This video demonstrates how to use Nightmare (which is a wrapper around Electron) to launch a url and scrape dynamic data.

Scraping Dynamic JavaScript Websites with Nightmare

Browserify lets you require('modules') in the browser by bundling up all of your dependencies.

browserify

Let's look at the basics of setting up Gulp and Browserify. Creating a Gulp task from scratch, we'll cover how to utilise the Browserify API to generate a single `bundle.js` file, catch and log any errors that occur in the compilation process, transform the stream into a format that can be consumed by `gulp.dest` and finish by writing the bundle to a `dist` directory.

Gulp and Browserify - Initial Setup

A brief introduction to using GulpJS in your JavaScript application and creating your first Gulp task.

Installing and Writing a Default Task with Gulp

Beginning with a single Gulp task capable of generating a one-time Browserify bundle, we enable file-watching and incremental rebuilds by incorporating Watchify. We add a second task `watch` & refactor our initial code to enable the bulk of it to be re-used. We’ll look at exactly how to ‘wire’ these tools together and how the relationship between Watchify & Browserify can manifest into a seriously efficient workflow.

Gulp and Browserify - Hooking up Watchify

We will look at bundling your JavaScript files using Gulp, Gulp-Concat, and Gulp-Uglify

Bundling Your JavaScript Files with Gulp

Cole Bemis explains how MDX works by taking us though his own journey digging into what MDX does under the hood.

Demystifying MDX

Laurie Barth walks us through MDX v2's syntax by trying to break it. She starts at markdown syntax and takes us through increasingly complex applications of MDX, including passing dynamic props to .mdx files imported into other .mdx files.

MDX v2 Syntax

Jonathan Bakebwa introduces MDX support for VueJS and NuxtJS while also using Chakra UI Vue for MDX components

MDX and VueJS/NuxtJS

Monica Powell, creator of React Ladies, talks through why someone would migrate from Remark to MDX before going into how to do that and what problems you might run into.

Migrating to MDX

Prince Wilson, MDX contributor, takes us through one aspect of his personal site playground and dives deep into interactive code blocks.

Personal Site Playgrounds with MDX

Rodrigo Pombo introduces [Code Hike](https://codehike.org/) and talks through how Code Hike and MDX empower advanced scrolly telling techniques.

The X in MDX

Kathleen McMahon walks us through a real-world MDX digital garden implementation

Digital Gardening with MDX Magic

Next.js is a minimalistic framework for server-rendered React applications.

Many markdown documents have a metadata section at the very beginning, which contains information such as the title, author and creation date. This section is the so-called "front matter". 

In order to render our markdown-based blog articles on our portfolio site we want to parse them and separate them into the front-matter and main article part. `gray-matter` is a library that helps us with that.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/read-and-render-md-files-with-next-js-and-nx-89a85c1d9b44).

Parse a Markdown Document With gray-matter

By leveraging the [dependency graph](https://nx.dev/l/r/structure/dependency-graph), [Nx](https://nx.dev) is able to understand which parts in the monorepo changed and thus trigger actions on those nodes, such as building an app, running tests or linting. This already works out of the box. However, with our portfolio application, all of our markdown articles reside in the root-level `_articles` folder. Those are not captured by the Nx dependency graph and thus Nx would not correctly detect a change to our Next.js site application whenever we change or add a new markdown article.
In this lesson, we learn how to register our `_articles` folder s.t. it appears as a dedicated node in the Nx dependency graph.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/publishing-a-next-js-app-to-vercel-with-nx-df81916548f5).

Register our Markdown Articles with the Nx Dependency Graph

One cool aspect of Next.js is its [fast refresh](https://nextjs.org/docs/basic-features/fast-refresh) support. Whenever you change some Next.js component it automatically refreshes the page without hard reloading everything. However, you might notice that whenever we change something within our MDX markdown files, fast refresh is not capturing that, hence we need to manually refresh the browser window.

In this lesson, we learn how to leverage a feature of Nx to create a "[custom Next.js development server](https://nx.dev/l/r/next/server#customserverpath)". We are going to use [chokidar](https://www.npmjs.com/package/chokidar) to watch our articles folder and then invoke a private API on the Next.js server instance to trigger a reload command.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/hot-reload-mdx-changes-in-next-js-and-nx-c05252cf450a).

Add Fast Refresh Support to our MDX Files with Nx Support for Custom Next.js Servers

Next.js is all about creating performant web applications. However, the more React components we pull into our MDX via `next-mdx-remote`, the heavier our JavaScript becomes which drains our site's performance. Also, while we might have quite a few React components to be included in our Markdown rendered content, we might not always use all of them in our articles.

In this lesson, we learn how to leverage Next.js dynamic imports to just pull the minimum necessary components into our final JavaScript bundle. Also, we look into why we might want to do deep imports into our Nx library setup to decrease the size of the bundle even more.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/component-hydration-with-mdx-in-next-js-and-nx-90f46ea0431c).

Dynamically Loading React Components with next-mdx-remote and Next.js Dynamic imports

The markdown rendering includes a lot of native HTML tags as well of course. Assume for instance we want to change the behavior of links within our rendered document. We can definitely create a custom component and include that in our MDX document, but we’d rather not want to have to use a specific `<Link>` component and rather be able to keep the native way of rendering links in Markdown, that is `[some link](https://juri.dev)`.

Turns out that with `next-mdx-remote` we are able to automatically replace all rendered `<a>` tags (or really any other tag we want) with a React Component.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/component-hydration-with-mdx-in-next-js-and-nx-90f46ea0431c).

Search

Search Results