-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Automatically create JS versions of our TS code in the docs #2638
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
Changes from all commits
3e59636
e0ee478
793b50f
4002350
3bd0591
fd19f6a
b255f6b
56112f3
b954e89
49d7321
1f68723
f41ef1e
d24c7ed
027943d
3f3dfe3
0fafea8
2bc974e
c9d54e2
2abdc9b
429bcdb
d968565
aeec5a8
36eb43a
f7f3d69
dbed0a0
beed6b9
0154adc
7d4bd83
3d6253d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -23,6 +23,97 @@ $ npm start | |||||||||||||||||||
This command starts a local development server and opens up a browser window. | ||||||||||||||||||||
Most changes are reflected live without having to restart the server. | ||||||||||||||||||||
|
||||||||||||||||||||
### Writing docs | ||||||||||||||||||||
|
||||||||||||||||||||
To write docs, you can use Markdown or MDX. The docs are located in the `docs` directory. | ||||||||||||||||||||
Remember to refer to the [Writing Guide](https://wasp.sh/docs/writingguide) for an explanation | ||||||||||||||||||||
of how we like to write docs. You can check | ||||||||||||||||||||
[Docusaurus' documentation](https://docusaurus.io/docs/2.x/markdown-features) to see which special | ||||||||||||||||||||
Markdown features available (e.g. line highlighting). | ||||||||||||||||||||
Comment on lines
+28
to
+32
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You will notice that in the rest of the markdown we (me for sure, I think others also) don't stick to 80/100 lines as the max col, but take as much space as we need. That is because editors do good job of visually wrapping long lines and it makes writing text easier (you don't need to keep formatting it as you edit it).
Suggested change
|
||||||||||||||||||||
|
||||||||||||||||||||
#### Polyglot code blocks | ||||||||||||||||||||
infomiho marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||||||
|
||||||||||||||||||||
For examples that have a JavaScript and TypeScript version, add a `auto-js` meta attribute | ||||||||||||||||||||
cprecioso marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||||||
to the code block, like so: | ||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||||||
|
||||||||||||||||||||
~~~mdx | ||||||||||||||||||||
```ts title="src/apis.ts" auto-js | ||||||||||||||||||||
export const validatePassword = (password: string) => password.length > 8; | ||||||||||||||||||||
``` | ||||||||||||||||||||
~~~ | ||||||||||||||||||||
|
||||||||||||||||||||
And it will automatically generate a JS and TS version with a selector to switch between them: | ||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
otherwise it sound slike it generates both js and ts version, which is not what we wanted to say, right? |
||||||||||||||||||||
|
||||||||||||||||||||
~~~mdx | ||||||||||||||||||||
<Tabs groupId="js-ts"> | ||||||||||||||||||||
<TabItem value="js" label="JavaScript"> | ||||||||||||||||||||
|
||||||||||||||||||||
```js title="src/apis.js" | ||||||||||||||||||||
export const validatePassword = (password) => password.length > 8; | ||||||||||||||||||||
``` | ||||||||||||||||||||
|
||||||||||||||||||||
</TabItem> | ||||||||||||||||||||
<TabItem value="ts" label="TypeScript"> | ||||||||||||||||||||
|
||||||||||||||||||||
```ts title="src/apis.ts" | ||||||||||||||||||||
export const validatePassword = (password: string) => password.length > 8; | ||||||||||||||||||||
``` | ||||||||||||||||||||
|
||||||||||||||||||||
</TabItem> | ||||||||||||||||||||
</Tabs> | ||||||||||||||||||||
~~~ | ||||||||||||||||||||
|
||||||||||||||||||||
> [!NOTE] | ||||||||||||||||||||
> You can create a language switcher manually as described in | ||||||||||||||||||||
> [Docusaurus docs](https://docusaurus.io/docs/2.x/markdown-features/code-blocks#multi-language-support-code-blocks). | ||||||||||||||||||||
|
||||||||||||||||||||
If you need to omit some part of the code in a code example, you can use the `with-hole` meta attribute | ||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is under "polyglot code blocks", but it has nothing to do with polyglot code blocks, right? It would make more sense to put explanation about "hole" under separate header. Or maybe you can rename the header to "code blocks". Even then, each of these parts, auto-js and with-hole, might benefit from their own headers. |
||||||||||||||||||||
which will add an ellipsis wherever you write the identifier `hole` in the code block, so you can keep | ||||||||||||||||||||
it syntactically valid. You can combine it with the `auto-js` tag. | ||||||||||||||||||||
|
||||||||||||||||||||
For example, the following input: | ||||||||||||||||||||
|
||||||||||||||||||||
~~~mdx | ||||||||||||||||||||
```ts title="src/apis.ts" auto-js with-hole | ||||||||||||||||||||
infomiho marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||||||
export const validatePassword = (password: string) => password.length > 8 && hole; | ||||||||||||||||||||
``` | ||||||||||||||||||||
~~~ | ||||||||||||||||||||
|
||||||||||||||||||||
Will be transformed to: | ||||||||||||||||||||
|
||||||||||||||||||||
~~~mdx | ||||||||||||||||||||
<Tabs groupId="js-ts"> | ||||||||||||||||||||
<TabItem value="js" label="JavaScript"> | ||||||||||||||||||||
|
||||||||||||||||||||
```js title="src/apis.js" | ||||||||||||||||||||
export const validatePassword = (password) => password.length > 8 && ...; | ||||||||||||||||||||
``` | ||||||||||||||||||||
|
||||||||||||||||||||
</TabItem> | ||||||||||||||||||||
<TabItem value="ts" label="TypeScript"> | ||||||||||||||||||||
|
||||||||||||||||||||
```ts title="src/apis.ts" | ||||||||||||||||||||
export const validatePassword = (password: string) => password.length > 8 && /* ... */; | ||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh interesting that it is comment in TS but just raw ellipsis in JS (as stated above), how is that? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just a typo |
||||||||||||||||||||
``` | ||||||||||||||||||||
|
||||||||||||||||||||
</TabItem> | ||||||||||||||||||||
</Tabs> | ||||||||||||||||||||
|
||||||||||||||||||||
##### Caveats | ||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would instead split this into two pieces and add put each piece under the corresponding plugin's instructions above, because they don't share much actually. If I am reading about how to use auto-js, I want to read this extra information also, not find it later somewhere below, grouped with info about other plugins, if I even find it. |
||||||||||||||||||||
|
||||||||||||||||||||
The `auto-js` and `with-hole` meta attributes are custom Docusaurus plugins that we wrote, implemented at | ||||||||||||||||||||
[./src/remark/auto-js-code.ts](./src/remark/auto-js-code.ts) and [./src/remark/code-with-hole.ts](./src/remark/code-with-hole.ts). | ||||||||||||||||||||
|
||||||||||||||||||||
`auto-js` specifically is backed by [ts-blank-space](https://github.com/bloomberg/ts-blank-space), which will _only_ remove the | ||||||||||||||||||||
type annotations and not process anything else. Thus, some edge-cases can arise, so we recommend to run `npm run start` and | ||||||||||||||||||||
check the output JS in the browser to see if everything looks good. | ||||||||||||||||||||
|
||||||||||||||||||||
Known caveats are: | ||||||||||||||||||||
- Run `prettier` on the code before pasting it in the document, as `auto-js` will enforce it. | ||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not completely clear to me. Why would I want to do this? Because I want the code in the source too look the same as it will render in docs? Does that matter? Even if I care about that, how should I run it through prettier exactly -> should I copy it to a dummy file and run our shared config of prettier on it (which we have yet or not)? Maybe we should give up on this, if it is hard to enforce? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is based on a comment by Miho #2638 (comment), correctly calling out that the code is being prettified, and we should be attentive of it, because what we write might not be what comes out. The comment thread also explains why it is needed. "Enforcing it" in this case means that code will be prettified anyway, so it's better to have it already "pretty" in the file. |
||||||||||||||||||||
- Remember to add a `type` specifier to `import`s we don't want to appear in the JS | ||||||||||||||||||||
- `// highlight-next-line` comment before a TS-only line will hang around and highlight the wrong line. Use `// highlight-start` and `// highlight-end` instead. | ||||||||||||||||||||
cprecioso marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||||||
- It doesn't replace file names' extensions in clarification comments (this is mostly unique to the tutorial pages). | ||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What should we do in that case? Just avoid that situation, or is there same way to handle that without going manual? |
||||||||||||||||||||
|
||||||||||||||||||||
### Build | ||||||||||||||||||||
|
||||||||||||||||||||
``` | ||||||||||||||||||||
|
@@ -56,14 +147,14 @@ We deploy the website to Cloudflare Pages. When you want to deploy changes from | |||||||||||||||||||
git checkout release | ||||||||||||||||||||
``` | ||||||||||||||||||||
|
||||||||||||||||||||
The website should be live within a few minutes at https://wasp.sh. | ||||||||||||||||||||
The website should be live within a few minutes at https://wasp.sh. | ||||||||||||||||||||
|
||||||||||||||||||||
You can track the deployment progress on Cloudflare Pages (https://dash.cloudflare.com/). Credentials are in the 1Password vault. | ||||||||||||||||||||
|
||||||||||||||||||||
### Preview docs from the `main` branch | ||||||||||||||||||||
|
||||||||||||||||||||
We set up automatic deployment of docs from the `main` branch on Cloudflare Pages. This means that every time you push to the `main` branch, the docs will be built and deployed to https://wasp-docs-on-main.pages.dev. | ||||||||||||||||||||
|
||||||||||||||||||||
### Multiple documentation versions | ||||||||||||||||||||
|
||||||||||||||||||||
We maintain docs for multiple versions of Wasp. | ||||||||||||||||||||
|
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -128,47 +128,23 @@ For example, if your app is running at `https://example.com` then from the above | |||
|
||||
To use the API from your client, including with auth support, you can import the Axios wrapper from `wasp/client/api` and invoke a call. For example: | ||||
|
||||
<Tabs groupId="js-ts"> | ||||
<TabItem value="js" label="JavaScript"> | ||||
```jsx title="src/pages/SomePage.jsx" | ||||
import React, { useEffect } from "react"; | ||||
import { api } from "wasp/client/api"; | ||||
|
||||
async function fetchCustomRoute() { | ||||
const res = await api.get("/foo/bar"); | ||||
console.log(res.data); | ||||
} | ||||
|
||||
export const Foo = () => { | ||||
useEffect(() => { | ||||
fetchCustomRoute(); | ||||
}, []); | ||||
|
||||
return <>// ...</>; | ||||
}; | ||||
``` | ||||
</TabItem> | ||||
|
||||
<TabItem value="ts" label="TypeScript"> | ||||
```tsx title="src/pages/SomePage.tsx" | ||||
import React, { useEffect } from "react"; | ||||
import { api } from "wasp/client/api"; | ||||
|
||||
async function fetchCustomRoute() { | ||||
const res = await api.get("/foo/bar"); | ||||
console.log(res.data); | ||||
} | ||||
|
||||
export const Foo = () => { | ||||
useEffect(() => { | ||||
fetchCustomRoute(); | ||||
}, []); | ||||
|
||||
return <>// ...</>; | ||||
}; | ||||
``` | ||||
</TabItem> | ||||
</Tabs> | ||||
```tsx title="src/pages/SomePage.tsx" auto-js with-hole | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nice, awesome! I am curious, in which situations do we need this Hm I will also have to take this into account in the coderef checker plugin -> I will probably want to run it after the with-hole, so I can work with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Indeed in this specific example the plugin is not that useful, as you can manually write the comment. But it is useful in situations such as the one explained in the Readme: const foo = myBool && /* ... */; // not syntactically valid
const bar = myBool && hole; // syntactically valid We need examples to be syntactically valid as |
||||
import React, { useEffect } from "react"; | ||||
import { api } from "wasp/client/api"; | ||||
|
||||
async function fetchCustomRoute() { | ||||
const res = await api.get("/foo/bar"); | ||||
console.log(res.data); | ||||
} | ||||
|
||||
export const Foo = () => { | ||||
useEffect(() => { | ||||
fetchCustomRoute(); | ||||
}, []); | ||||
|
||||
return <>{hole}</>; | ||||
}; | ||||
``` | ||||
Comment on lines
+131
to
+147
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One thing I noticed that when I try to auto format this code in VS Code, the code block doesn't get formatted and the code in the output is of course formatted. ![]() Is there a way for us to configure Prettier to format the code blocks in the MDX files? I think it makes sense for code blocks in the source code to look as similar as possible to the rendered code blocks for easier searching later on. If it's not possible to run Prettier on MDX files (this issue suggests so) should we make it a part of the docs authoring process to format the code before including it in the code blocks? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, as you found out, Prettier is stuck in MDXv1 so I'd rather not run it on our MDXv3 files, it will mess up its delicate whitespace situation 😑
You mean just adding that to the readme? I can do that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd rather not have to run Prettier at all if we don't have it at the source, but it needs to run on the JS so it removes the blank space (I didn't find another type stripper that doesn't leave the whitespace), and then on the TS for consistency. 😔 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, I thought maybe about adding a note in the README to say, hey, format it so the source code and the rendered code look as close as possible for better searchablity. Too bad about missing MDX 3 support, since Docusaurus moved, you'd expect it to be more demand for it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe one for the future, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added it here BTW Line 112 in beed6b9
|
||||
|
||||
#### Making Sure CORS Works | ||||
|
||||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
There are quite a few headers already in this README about dealing with docs. They are also level 3 headers. It somehow feels like this specific header is the entry header for docs though. Would it make more sense to make this one level 2 header, call it ## Docs, and then put this at the start and the rest of the headers under it (which is already happening actually)?
Further question is if some of this content would be better suited in writingguide.md or even docs/README.md (which doesn't exist yet), but we don't have to deal with that now (but maybe in the future we will want to move most of this content into docs/README.md).
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.
We have
web/readme.md#writing docs
,web/writing-docs.md
andweb/docs/writingguide.md
. It seems like there's an opportunity for centralization here but tbh I don't know where to start from, the end result would be a monster doc