-
-
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 | ||
---|---|---|---|---|
|
@@ -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 | ||||
Martinsos marked this conversation as resolved.
Show resolved
Hide resolved
|
||||
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).
Uh oh!
There was an error while loading. Please reload this page.
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 docThere 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.
Oh crap, we also have web/writing-docs.md! I forgot about that one.
OK, in that case, we probably shouldn't have Writing docs here also, right? With this header you added, confusion increases then I think.
My suggestion:
I wrote it in 4 bullet points hah but it is rather simple change I think so should be ok for this PR, and it helps others in the future. What do you think, would you do it differently?
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.
Done