first stab at migrating to TypeScript #24
Conversation
|
This looks worth merging so we can take advantage of the Typescript for ongoing development. One question: are the names of the interfaces all automatically generated? (I only skimmed the docs on this.) I would be in favor of not having them all named just |
|
The name of types for queries are generated automatically. For example On the other hand, I added interfaces called |
|
Got it. Yes, I was thinking something along the lines of ComponentNameProps
…On Mon, Jul 29, 2024 at 2:56 PM Raff Viglianti ***@***.***> wrote:
The name of types for queries are generated automatically. For example query
PeoplePast will generate a type called PeoplePastQuery.
On the other hand, I added interfaces called Props. They are limited to
component files and they model the properties that each component will
receive, so it seems a fairly self-explanatory name to me. We could do
something like ComponentNameProps instead?
—
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACVXEF2TUH5FKVXJM6D4ADZO2F6ZAVCNFSM6AAAAABLNC5MDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJWGY3TQNZTGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
This involved a bunch of flaililng until I followed links from a issue to this merged PR: https://github.com/gatsbyjs/gatsby/pull/36405/files#diff-9b4482a4b0c980ba8a14df389f19ca9f9cc347b0e9b2e2ea54e8c516e92cb27e Make the option in gatsby-config an object and then there is a property to generate types on build (which is needed to use in CI). fix: typechecking needs some files from build fix: Adjust npm typecheck script fix: Run build not build-pages in typescript workflow fix: add debugging step for types in GH Actions fix: try again to build types in CI fix: found the option to generate types for build 🫠 fix: whoops, deleted build step by accident
trevormunoz
force-pushed
the
full-typescript
branch
from
0c104f6 to
cbdb0d6
Compare
|
@raffazizzi Being able to run the type checker locally and in GitHub Actions (see cbdb0d6) caught a few additional errors: https://github.com/umd-mith/mith-static/actions/runs/10166800582 |
| </div> | ||
| ) | ||
| } | ||
| // TODO: The speakers list is not currently being displayed. Uncomment this code to display the list and also add to return statement below |
There was a problem hiding this comment.
One additional thing that Typescript checking turned up was a few places where we are going to the trouble of generating a chunk of a page but not returning/rendering it (probably because of data quality issues. I tried to mark these with some TODOs but I probably didn't do them all
|
Thanks for looking at this thoroughly, @trevormunoz. I'll merge for now and I will open a couple of issues for improving the code. |
@trevormunoz I migrated the code base to TypeScript. Dealing with the query results is... complex to put it mildly. I think we can identify better strategies to
string | numbertypes that can more firmly be one or the other.There's always benefits to using TypeScript, and I caught a couple of minor errors where the code looked up the wrong field, or where the field was missing. But dealing with these complex structures from AirTable may be more of a pain than needed.
Take a look if you can and see what you think!
NB the query types are generated the first time you run
yarn developnpm run developso make sure to do that before opening your IDE.