Draft
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a richer “Resource” display and Decap CMS preview support by rendering resource descriptions as Markdown and introducing styling/utilities needed for CMS + frontend parity.
Changes:
- Update the resource template to use a new
CustomReactMarkdowncomponent and new page/card styling. - Extend the VariableTypeWidget to support a
markdownfield type and normalize Decap Immutable values via a shared utility. - Register a
ResourcePreviewfor theresource_unionwidget in Decap CMS.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| src/templates/resource.tsx | Switches resource rendering to a styled card layout and renders description via Markdown |
| src/style/resource.css | Adds styles for the new resource page/card UI |
| src/style/markdown.css | Adds styles for Markdown code blocks/inline code |
| src/style/index.css | Adds an @import for the Raleway font |
| src/components/CustomReactMarkdown.tsx | Adds Markdown rendering helper with code block styling hooks |
| src/cms/widgets/VariableTypeWidget/types.ts | Adds markdown as a supported field type |
| src/cms/widgets/VariableTypeWidget/VariableTypeWidgetControl.tsx | Adds Markdown widget rendering and uses shared Immutable normalization |
| src/cms/utils/immutable.ts | Introduces fromImmutable helper + minimal Immutable-like typing |
| src/cms/preview-templates/ResourcePreview.tsx | Adds preview component that reuses the site’s Resource template |
| src/cms/cms.js | Registers ResourcePreview as the widget preview for resource_union |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
interim17
commented
Mar 17, 2026
Comment on lines
+1
to
+24
| .resource-page { | ||
| font-family: "Raleway", sans-serif; | ||
| line-height: 1.7; | ||
| max-width: 680px; | ||
| margin: 40px auto; | ||
|
|
||
| .resource-card { | ||
| background: var(--WHITE); | ||
| border: 1.5px solid var(--border-color); | ||
| border-radius: 4px; | ||
| padding: 28px 32px; | ||
|
|
||
| .resource-description { | ||
| font-size: 15px; | ||
| line-height: 1.7; | ||
| color: var(--BLUE_70); | ||
| margin-bottom: 20px; | ||
| } | ||
| } | ||
|
|
||
| a { | ||
| overflow-wrap: break-word; | ||
| } | ||
| } |
Contributor
Author
There was a problem hiding this comment.
example of using nested selectors in plain CSS to get a bit of modularity
interim17
commented
Mar 17, 2026
Comment on lines
+1
to
+30
| .code-block { | ||
| background-color: var(--color-bg-secondary, #f6f8fa); | ||
| border: 1px solid var(--color-border, #e0e0e0); | ||
| border-radius: 4px; | ||
| padding: 12px 16px; | ||
| overflow-x: auto; | ||
| font-family: "Courier New", Courier, monospace; | ||
| font-size: 13px; | ||
| line-height: 1.6; | ||
| white-space: pre; | ||
| margin: 8px 0; | ||
| code { | ||
| background: none; | ||
| border: none; | ||
| padding: 0; | ||
| font-size: inherit; | ||
| font-family: inherit; | ||
| } | ||
| } | ||
|
|
||
| /* :global is required because react-markdown renders <code> without a class we can target. | ||
| Fenced blocks are excluded via :not(pre > code) since those are handled by .code-block above. */ | ||
| :global(code:not(pre > code)) { | ||
| background-color: var(--color-bg-secondary, #f6f8fa); | ||
| border: 1px solid var(--color-border, #e0e0e0); | ||
| border-radius: 3px; | ||
| padding: 1px 5px; | ||
| font-family: "Courier New", Courier, monospace; | ||
| font-size: 0.875em; | ||
| } |
Contributor
Author
There was a problem hiding this comment.
brought these rules over from the design-pass branch
interim17
commented
Mar 17, 2026
Comment on lines
+17
to
+23
| <ResourceTemplate | ||
| type={v.type} | ||
| name={v.name} | ||
| description={v.description} | ||
| link={v.link} | ||
| status={v.status} | ||
| /> |
Contributor
Author
There was a problem hiding this comment.
This is the real benefit of the vanilla CSS vs modules change, getting to use the same template here in the preview as we do in the template.
This file contains hidden or 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
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.
Problem
Advances #55
Provides a basic preview (design pending) for resources, and a pattern for further previews.
We want decently looking preview components in the CMS so that scientist can anticipate how their entries will look.
I was hitting two major road blocks on this:
Solution
The solution I found to the styling issue was to use vanilla CSS and not use modules.
gatsby-plugin-decap-cmsseems like it can handle the styling with minimal/zero configuration if we use vanilla CSS. I tried a number of approaches to get the module scoped CSS into the preview components and had no success.I think the main risk of plain CSS over modules is namespace collisions. Two mitigations here are
a) we can continue to use modules wherever the components are not needed in previews
b) a reasonably unique out class name and nested CSS rules provides a good degree of modularity
Personally I haven't been taking good advantages of nested CSS to date, it's quite nice. In the following example we have nicely encapsulated selectors, even for generic class names like
.cardor.descriptionso long as.resource-pageis a unique class name in our application:The other issue, the stale data from some widgets, is solved by using
valueinside Decap after changes have been made, but normalizing the data fromentrywhich is an Immutable.js Map and not a plain object. We had some related code already in theVariableTypeWidgetControlso I pulled some of it into a util file.There are a couple other odds and ends in here, like rendering a Markdown widget for resource widget descriptions, and some markdown styling. The styling applied to resources is fairly arbitrary/not final.