-
Notifications
You must be signed in to change notification settings - Fork 15
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
TypeScript versions of the homepage starters #95
TypeScript versions of the homepage starters #95
Conversation
Gatsby Cloud Build Reporthomepage-starters-dev 🎉 Your build was successful! See the Deploy preview here. Build Details🕐 Build time: 29s PerformanceLighthouse report
|
… transpilation on necessary repos and calling prettier before writing to file
…e .ts extension - update webpack resolve alias for ui.js
…te webpack alias in conjunction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why you're not doing it all in one PR but, i've added some comments
__dirname, | ||
"plugins", | ||
plugin, | ||
"src", | ||
"colors.css.ts" | ||
"colors.css" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason why you don't add ts extension here? Or you remove them anywhere or you add them everywhere but I think the goal here is to remove them everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, we don't want them around anywhere. For VSCode users (myself included), you need to omit the .ts
extension in the import
statement in order for VSCode's in-IDE type checking and auto-complete functionality to work properly. And when I did that across the board in this PR, the webpack alias also needed updating.
If I were to add the .ts
back to this line, I consistently get this build error:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds like Vanilla Extract still handles these correctly without the extension, right? It's unclear from the documentation whether that's a requirement versus just a convention, but 👍 if this all works
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lennart's example repo omits .ts
from import statements as well
jobTitle?: string | ||
} | ||
|
||
function AboutProfile(props: AboutProfileProps) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't you get type warnings? In React land with typescript, you should do
function AboutProfile(props: AboutProfileProps) { | |
const AboutProfile: React.FC<AboutProfileProps> = function AboutProfile(props: AboutProfileProps) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, no type warnings!
I can certainly update to type all the components with React.FC
, however I was trying to minimize the changes to the source code in my effort to convert over to TypeScript, and additionally, I tend to agree with the opinions articulated in this article: https://fettblog.eu/typescript-react-why-i-dont-use-react-fc/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what the correct answer to this would be, but I'd say we should follow any "blessed" practices that might exist from React and ensure that our Gatsby style is consistent across the board. @wardpeet do we have much of a precedent set with other starters or TS docs, etc.?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking great so far! I'll take another pass at this in the morning, but wanted to comment mostly around the UI components and leave some notes about some of the things we chatted about earlier for consideration/discussion
jobTitle?: string | ||
} | ||
|
||
function AboutProfile(props: AboutProfileProps) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what the correct answer to this would be, but I'd say we should follow any "blessed" practices that might exist from React and ensure that our Gatsby style is consistent across the board. @wardpeet do we have much of a precedent set with other starters or TS docs, etc.?
|
||
export default function CaretDown({ | ||
direction = "down", | ||
size = 9, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we use the size
prop at all; I'd be keen to remove it to simplify the API a little
…working dependency versions are installed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think this is looking very close. Left a few comments and questions but nothing major from what I can see
scripts/publish.js
Outdated
const dest = path.join( | ||
dir.dist, | ||
name, | ||
srcFilename.replace(extension, ".js") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will likely work, but I think the better way to replace the extension is by using path.basename
(i.e. in the odd case that you had a file named foo.ts.bar.ts
)
@@ -125,8 +128,8 @@ For this example, we'll create a new "Banner" component. | |||
|
|||
1. Next, create the Banner component: | |||
|
|||
```jsx | |||
// src/components/banner.js | |||
```jsx fileExt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't checked yet, but I'm guessing the jsx
syntax highlighting on GitHub works for tsx syntax, but if it doesn't 100%, I would guess it'd work the other way around. Then again, maybe it doesn't matter because there are significant changes to the code examples' contents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I thought about that, but didn't think it was worth the trouble because the syntax highlighting won't be different. If we did add in an interface for the props, that wouldn't be highlighted the same way with jsx
and tsx
but I figure people will be able to figure out adding:
interface BannerProps {
heading: string;
text: string;
}
without us holding their hands on this one.
export const radii = styleVariants(theme.radii, (borderRadius) => ({ | ||
overflow: "hidden", | ||
borderRadius, | ||
})) | ||
export const order = styleVariants([0, 1, 2, 3], (order) => ({ | ||
export const order = styleVariants({ 0: 0, 1: 1, 2: 2, 3: 3 }, (order) => ({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this not typed to accept array objects in vanilla extract?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, styleVariants
is typed to accept a Record
as it's first argument
{ | ||
...theme.space, | ||
auto: "auto", | ||
}, | ||
(marginTop) => ({ marginTop }) | ||
) | ||
margin.bottom = styleVariants( | ||
|
||
export const marginBottom = styleVariants( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a problem, but this just feels less elegant than grouping into an object, but keeps things more consistent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
styles.margin.right[-right], | ||
styles.margin.top[-top], | ||
styles.margin.bottom[-bottom], | ||
left && styles.marginLeft[-left], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought these props could be 0
, but I might be wrong
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They could, but there would be no point in passing 0
as the value since you wouldn't be "nudging" at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In which case, this would pass a 0
to the className
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, no I'm wrong, this goes through .filter(Boolean)
…the note about TS & JS sister repos
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks for getting this all together and getting the readme generation in there as well!
) | ||
} | ||
node.value = node.value.replace("$fileExt", opts.fileExt) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! A lot simpler and doesn't mix up the directive syntax
Purpose
This PR sets up the ability to handle publishing TS and JS "source" versions of the starters. It also converts all the components over to
.tsx
as the first step to add type safety to the front-end of the starter.Testing
These are currently deployed to Gatsby Cloud:
Contentful: https://gatsbycontentfulhomepagets.gatsbyjs.io/
DatoCMS: https://gatsbydatocmshomepagets.gatsbyjs.io/
Drupal: https://gatsbydrupalhomepagets.gatsbyjs.io/
WP: https://gatsbywordpresshomepagets.gatsbyjs.io/
What's included?
publish.js
script to support transpiling the TS source to "source" JS as well as publishing the four new TS flavors of the starters