Conversation
9058f12 to
4dc6a8d
Compare
| 2- new code verification tool added to your pool (in javascript apps this is mostly made of different kinds of tests and lints) | ||
| 3- better development experience: better autocompletion and api discovery | ||
| 4- type checker guided hassle free refactoring | ||
| 5- improve the mind set of developers so that they think more about data structures and their semantic meaning inside the code (as oposed to just have a bunch of unamed and uncategorized objects which is something that tends to happen in bigger javascript apps). |
There was a problem hiding this comment.
| 5- improve the mind set of developers so that they think more about data structures and their semantic meaning inside the code (as oposed to just have a bunch of unamed and uncategorized objects which is something that tends to happen in bigger javascript apps). | |
| 5- improve the mindset of developers so that they think more about data structures and their semantic meaning inside the code (as opposed to just have a bunch of unnamed and uncategorized objects which is something that tends to happen in bigger javascript apps). |
There was a problem hiding this comment.
I think you start making a "review" when I first submit the PR and then finish it when I tell you it is ready to be reviewed (which might take couple of days). This makes your comments be on an outdated piece of code.
You might want to make these comments as "simple comments" instead of reviews or simply submit reviews early on so that your comments don't get outdated.
Or... we might not be using github's UI correctly jajaja
| 4- type checker guided hassle free refactoring | ||
| 5- improve the mind set of developers so that they think more about data structures and their semantic meaning inside the code (as oposed to just have a bunch of unamed and uncategorized objects which is something that tends to happen in bigger javascript apps). | ||
|
|
||
| I plan to talk a lot more about this in a follow up post so that is why I wont focus to much |
|
|
||
| I plan to talk a lot more about this in a follow up post so that is why I wont focus to much | ||
| explaining these points, but please note that most of these come from real world experiences | ||
| handling large production code bases in both Javascript and Typescript, and there is an abysm between the too. |
| } | ||
| ``` | ||
|
|
||
| I wont cover all the options but I do want to cover `strictNullChecks`. |
There was a problem hiding this comment.
I also think it's a good idea to explain what strictNullChecks does before going on to explain how it was problematic.
|
|
||
| ## How to use Typescript in your Gatbsy.js site. | ||
|
|
||
| We are going to install two plugins: |
There was a problem hiding this comment.
first plugin appears to be included in Gatsby which might be worth mentioning
There was a problem hiding this comment.
it is included in the gatsby-starter-blog, Im trying to make this more general to any gatsby application
| ``` | ||
|
|
||
| I wont cover all the options but I do want to cover `strictNullChecks`. | ||
| I found that enabling this option to be a big pain when convining it with the GraphQL codegen tool. |
| ### `declarations.d.ts` | ||
|
|
||
| In most Typescript codebases we have some global types or some untyped modules to declare, | ||
| that is why you most likely will need `src/declaration.d.ts`. Let's see a bair minimum one: |
| declare module "*.svg" | ||
| ``` | ||
|
|
||
| And then you should import this file from your `gatsby-browser.js` which |
There was a problem hiding this comment.
"import from" sounds a little confusing to me, imho it should be "import this file on/in gatsby-browser.js..."
mainly because import statements can be "import * from whatever" which is the other way around
|
|
||
| ### Typechecking | ||
|
|
||
| As the typescript plugin docs state, by default it wont run typechecks on your code, it |
| ### Typechecking | ||
|
|
||
| As the typescript plugin docs state, by default it wont run typechecks on your code, it | ||
| will only strip out any type information and typescript sintax and compile it down to Javascript. |
|
|
||
| ### gatsby-plugin-typescript | ||
|
|
||
| I did not made any special configurations to this plugin. |
| and some components will acess that data layer and that data will | ||
| flow through props and context down the component tree. | ||
|
|
||
| So it is reasonable to expect to somehow have thata data model |
| resolve: `gatsby-plugin-graphql-codegen`, | ||
| options: { | ||
| codegenConfig: { | ||
| // optional if you prefix, as I do, |
There was a problem hiding this comment.
explain why it could be convenient maybe?
I recall seeing that and being unsure regarding why it would be that way when it was first implemented (I still don't really know)
| This evaluates to something like `Type | null | undefined`, so you basically have three potential types instead | ||
| of just the two you actually epect: `Type | null` which is what `Maybe<Type>` resolves to. | ||
|
|
||
| So this will reduce some of the more awkard errors when passing props. |
| ``` | ||
|
|
||
| but the pages that make the query might generate different variantes of this type. Sometime shaving | ||
| some fields off sometimes others and in particular the profilepicture filed whihc maps to an image |
| some fields off sometimes others and in particular the profilepicture filed whihc maps to an image | ||
| might be altered in several ways like asking for a sharp image fluid. | ||
|
|
||
| IN that case this type wont be useful at all. |
This is mostly content complete, I just need to sit down and edit it down to a presentable thing.