[WIP]: Gatsby remark prismjs/line range #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
DSchau
commented
Nov 1, 2018
| @@ -0,0 +1,36 @@ | |||
| "use strict" | |||
There was a problem hiding this comment.
ugh, these are being transpiled.... will fix!
DSchau
changed the title
phacks
added a commit
to phacks/gatsby
that referenced
this pull request
Nov 3, 2018
Heavily inspired by DSchau#2
DSchau
pushed a commit
that referenced
this pull request
Nov 13, 2018
This is the first step towards gatsby themes. It is low level and defines the way multiple gatsby sites compose by defining the way in which gatsby-config's compose. Everything else will build on top of this composition model so it's important to make it extensible and maintainable for the future.
For those that are mathematically inclined, this defines a monoid for the gatsby-config data structure such that `(siteA <> siteB) <> siteC === siteA <> (siteB <> siteC)`. This makes it nice when thinking about sub-theming in the future (imagine a complex `ThemeA <> subthemeA <> ThemeB <> subthemeB <> user-site` situation)
This method of composition opens the door to themes and sub-themes and allows us to get more user input into how to deal with potentially conflicting artifacts (such as two singleton plugins being defined), test out approaches to generic overriding the rendering of components in user-land, and more.
## Themes
A theme is defined as a parameterizable gatsby site. This means that gatsby-config can be a function that accepts configuration from the end user or a subtheme. This is important because in the current state of the world when setting up plugins like `gatsby-source-filesystem`, we need them to be configured with a `__dirname` from the user's site (we could have a special `__inTheCurrentSite` value in the future instead).
In the end-user's site, we declare a "theme" using the `__experimentalThemes` keyword in gatsby-config. We use this keyword so that people are aware this functionality is experimental and may change without warning. A theme can be configured in the same way plugins are configured (TODO: change `[theme, config]` syntax to match plugin `{resolve:,options}` form) so that the userland APIs match up.
```js
// gatsby-config.js
module.exports = {
__experimentalThemes: [[`blog-theme`, { dir: __dirname }]],
}
```
The theme then includes a gatsby-config.js which allows it to defined all of the expected fields, such as plugins, and also configure them based on user input. (TODO: looks like gatsby-config.js is ignored in the .gitignore file for the theme package in commit #2)
```js
// blog-theme gatsby-config.js
module.exports = ({ dir }) => ({
siteMetadata: {},
plugins: [
`gatsby-mdx`,
{
resolve: `gatsby-source-filesystem`,
options: {
name: "blog-posts",
path: `${dir}/blog-posts/`,
},
},
],
})
```
### Composing themes
Multiple themes can be used, although there is (intentionally) nothing included in this PR to stop or resolve potential conflicts (for example if a gatsby plugin needs a singleton instance for some reason).
```js
// gatsby-config.js
module.exports = {
__experimentalThemes: [`blog-theme`, `store-theme`],
}
```
### Themes as plugins
Themes are also included in the plugin list, so they can take advantage of using files such as `gatsby-node`. When being used as plugins, themes receive the full themeConfig as the options object. As an example, a blog theme could be instantiated multiple times on a site, once for blog posts and once for product reviews.
```js
// gatsby-config.js
module.exports = {
__experimentalThemes: [
[`blog-theme`, { baseUrl: '/posts' }},
[`blog-theme`, { baseUrl: '/reviews' }]
],
}
```
# etc
##### Commits
This PR contains two commits. The first is the actual functionality, the second is a set of examples (a theme defined as an npm package and an example site using said theme). I expect to remove the second commit before merging, but am open to other approaches to keep an example, etc around and develop it further as we progress.
##### This PR intentionally does not cover:
- Defining data types in any way different than the current sourcing patterns
- Any official sub-theming support for overriding components, etc
* the only way to "override" things right now is to use gatsby lifecycles (ex: on-create-page hooks) to replace the full page component.
* still technically possible in user-land, planned but not included in core yet
phacks
added a commit
to phacks/gatsby
that referenced
this pull request
Nov 17, 2018
Heavily inspired by DSchau#2
DSchau
pushed a commit
to gatsbyjs/gatsby
that referenced
this pull request
Nov 26, 2018
…y line highlighting (#9696) * feat: allow highlight directives in prismjs plugin Heavily inspired by DSchau#2 * fix: Fix multiline plain-text for directives * tests: test highlight-range directive * Add built version * feat: rely on prismjs plugin for embed-snippet directive highlighting * Add console.warn if invalid range is specified * docs: document highlight directives * fix: fix endless loop when multiple highlight-start/end directives * Add kitchen sink directive test * Remove built version * docs: better directive example * fix: existing highlight ranges behavior now working again * fix: JSX directive not removed after highlight * fix: highlight-range directive removing a line * Add comment explaining priority between top-level declaration and directives * fix lint error * Add more explicit example in README * Fix HTML opening comment not being stripped * Add `./highlight-line-range.js to .gitignore * Remove extraneous <span> tags * Add comment for big regex
gpetrioli
pushed a commit
to gpetrioli/gatsby
that referenced
this pull request
Jan 22, 2019
…y line highlighting (gatsbyjs#9696) * feat: allow highlight directives in prismjs plugin Heavily inspired by DSchau#2 * fix: Fix multiline plain-text for directives * tests: test highlight-range directive * Add built version * feat: rely on prismjs plugin for embed-snippet directive highlighting * Add console.warn if invalid range is specified * docs: document highlight directives * fix: fix endless loop when multiple highlight-start/end directives * Add kitchen sink directive test * Remove built version * docs: better directive example * fix: existing highlight ranges behavior now working again * fix: JSX directive not removed after highlight * fix: highlight-range directive removing a line * Add comment explaining priority between top-level declaration and directives * fix lint error * Add more explicit example in README * Fix HTML opening comment not being stripped * Add `./highlight-line-range.js to .gitignore * Remove extraneous <span> tags * Add comment for big regex
DSchau
pushed a commit
that referenced
this pull request
Apr 16, 2020
RFC: Remove special layouts from v2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.