Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code span highlighting #89

Merged
merged 5 commits into from
May 4, 2020
Merged

Code span highlighting #89

merged 5 commits into from
May 4, 2020

Conversation

andrewbranch
Copy link
Owner

@andrewbranch andrewbranch commented Apr 25, 2020

Closes #76

Copying implementation instructions from issue:

  • Make the changes to types.d.ts I mentioned above.
  • Introduce a new type into schema.graphql to represent inline code. It should look just like GRVSCCodeBlock, bet can replace preClassName and codeClassName with just className, omit meta, and replace tokenizedLines with tokens: [GRVSCToken!]!. (Run npm run build after this to update schema.d.ts.)
  • Add validation for “if options.inlineCode exists, options.inlineCode.marker must exist in validateOptions.js.
  • Update the AST visitor to look for both code and inlineCode nodes, if options.inlineCode is defined. (I think you can replace the string 'code' test with a callback function that accepts a node, where you can check its type. API)
  • In the initial loop over code nodes, you’ll need to branch on node.type for some things. E.g., instead of calling parseCodeFenceHeader, you’ll need to call a new similar parsing function that separates the node text into language and text. If you don’t detect a language (i.e., you never see inlineCode.marker), I think you can just continue and be done with that node. The call to getPossibleThemes needs to use inlineCode.theme || theme if node.type === 'inlineCode'. Otherwise, I think most of that loop body stays the same. In the registerCodeBlock function, I think we should probably not run line transformers on inline code nodes.
  • The next loop, registry.forEachCodeBlock, goes back over the nodes and generates HTML for them. The actual HTML generation is in getCodeBlockDataFromRegistry. Probably about half the stuff in here is actually specific to code blocks, and I think it might be too messy to make it polymorphic, so I would probably recommend making registry.forEachInlineCode and getInlineCodeDataFromRegistry functions instead, and repeating/extracting the relevant things from what’s there now. While generating HTML is the bulk of the work in this function, its full purpose is to generate a JavaScript object matching the new type you added to the GraphQL schema in step 2.
  • Back in index.js in your [codeBlockRegistry.forEachInlineCode] loop, you can finish generating the GraphQL node in the same way as registry.forEachCodeBlock and push it onto the same graphQLNodes array.
  • Write some integration tests. Try to cover the API surface.

And a step I forgot:

  • Add a new GraphQL resolver for GRVSCCodeSpan in gatsby-config.js

@andrewbranch andrewbranch marked this pull request as ready for review May 4, 2020 02:37
@andrewbranch andrewbranch merged commit e4a237f into master May 4, 2020
@andrewbranch andrewbranch deleted the feat/inline branch May 4, 2020 02:46
@andrewbranch andrewbranch mentioned this pull request May 17, 2020
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature request: Inline code blocks
1 participant