Skip to content
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

docs: Grammar overhaul #20636

Closed
wants to merge 333 commits into from
Closed

Conversation

GalacticHypernova
Copy link
Contributor

@GalacticHypernova GalacticHypernova commented May 2, 2023

Grammatical improvement for the page, with better consistency and punctuation usage.

πŸ”— Linked issue

Also implements #20706 for a unified merge with the overhaul

❓ Type of change

  • πŸ“– Documentation (updates to the documentation, readme or JSdoc annotations)
  • 🐞 Bug fix (a non-breaking change that fixes an issue)
  • πŸ‘Œ Enhancement (improving an existing functionality like performance)
  • ✨ New feature (a non-breaking change that adds functionality)
  • 🧹 Chore (updates to the build process or auxiliary tools and libraries)
  • ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

πŸ“š Description

This PR fixes the grammar throughout the documentation, giving a more professional look to nuxt. (As of latest commits, this has become a general-purpose docs PR)

πŸ“ Checklist

  • I have linked an issue or discussion.
  • I have updated the documentation accordingly.

@codesandbox
Copy link

codesandbox bot commented May 2, 2023

CodeSandbox logoCodeSandbox logoΒ  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

@nuxt-studio
Copy link

nuxt-studio bot commented May 2, 2023

βœ… Live Preview ready!

Name Edit Preview Latest Commit
Nuxt Docs Edit on Studio β†—οΈŽ View Live Preview 00b9eea

@GalacticHypernova GalacticHypernova changed the title docs: Grammatical improvements for the auto-imports guide page docs: Grammatical improvements for the multiple guide pages May 2, 2023
@GalacticHypernova GalacticHypernova changed the title docs: Grammatical improvements for the multiple guide pages docs: Grammatical improvements for multiple guide pages May 2, 2023
@GalacticHypernova GalacticHypernova changed the title docs: Grammatical improvements for multiple guide pages docs: Grammatical improvements for nuxt.com May 3, 2023
@GalacticHypernova GalacticHypernova marked this pull request as draft May 3, 2023 15:04
@GalacticHypernova GalacticHypernova changed the title docs: Grammatical improvements for nuxt.com docs: Grammar overhaul May 4, 2023
@GalacticHypernova
Copy link
Contributor Author

Done with the sixth batch! Noticed the config documentation is a bit lacking so I will work on it in the meantime, but definitely send the 7th batch whenever you can!

@GalacticHypernova
Copy link
Contributor Author

@danielroe Could I please get a confirmation that my latest commit will, in fact, show autoImport?

Comment on lines 32 to 35
/**
* Toggle auto-imports for all composables, components, directories, and all other parts of your application that Nuxt usually handles.
*/
autoImport: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, good catch - this will mean it shows up in the nuxt.config generated markdown... You ca n preview the result by running pnpm build:stub (or pnpm build) and checking packages/schema/schema/config.md which will be generated.

It would be good to sync the docs between here and ../src/types/imports so the text and examples are the same.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, thanks for confirming! Turns out preview was indeed the issue in displaying as it did not generate the page when going there, because at first I thought I broke it haha. Always glad to help! Will sync it.

Copy link
Member

@DamianGlowala DamianGlowala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seventh batch of comments

docs/2.guide/2.directory-structure/1.pages.md Outdated Show resolved Hide resolved
docs/2.guide/2.directory-structure/1.plugins.md Outdated Show resolved Hide resolved
docs/2.guide/2.directory-structure/1.server.md Outdated Show resolved Hide resolved
docs/2.guide/2.directory-structure/1.server.md Outdated Show resolved Hide resolved
@@ -149,10 +149,10 @@ export default defineEventHandler(async (event) => {
You can now universally call this API using `$fetch('/api/submit', { method: 'post', body: { test: 123 } })`.

::alert{type=warning title=Attention}
We are using `submit.post.ts` in the filename only to match requests with `POST` method that can accept the request body. When using `readBody` within a GET request, `readBody` will throw a `405 Method Not Allowed` HTTP error.
We use `submit.post.ts` in the filename only to match requests with the `POST` method that can accept the request body. When using `readBody` within a GET request, `readBody` will throw a `405 Method Not Allowed` HTTP error.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We use `submit.post.ts` in the filename only to match requests with the `POST` method that can accept the request body. When using `readBody` within a GET request, `readBody` will throw a `405 Method Not Allowed` HTTP error.
We use `submit.post.ts` filename to match requests only with the `POST` method (that can accept the request body). When using `readBody` within a GET request, `readBody` will throw the HTTP `405 Method Not Allowed` response status code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about adding a the before submit.post.ts?

docs/2.guide/3.going-further/3.modules.md Outdated Show resolved Hide resolved
docs/2.guide/3.going-further/3.modules.md Outdated Show resolved Hide resolved
docs/2.guide/3.going-further/3.modules.md Outdated Show resolved Hide resolved
docs/2.guide/3.going-further/3.modules.md Outdated Show resolved Hide resolved
@@ -21,12 +21,12 @@ function useMyComposable () {
Plugins also receive `nuxtApp` as the first argument for convenience. [Read more about plugins.](/docs/guide/directory-structure/plugins)

::alert{icon=πŸ‘‰}
**`useNuxtApp` (on the server) only works during `setup`, inside Nuxt plugins or `Lifecycle Hooks`**.
**`useNuxtApp` (on the server) only works during `setup` inside Nuxt plugins or `Lifecycle Hooks`**.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing comma changed the meaning of the sentence :)

Also, worth having a look: https://www.proofreadnow.com/blog/putting-only-in-its-place

Suggested change
**`useNuxtApp` (on the server) only works during `setup` inside Nuxt plugins or `Lifecycle Hooks`**.
**`useNuxtApp` (on the server) works only during component's `setup` function, lifecycle hooks and inside Nuxt plugins.**

@danielroe
Copy link
Member

This is such a big PR, and therefore could easily get out of sync with main branch.

What do you think about splitting it up into smaller concept-based chunks which can be more easily reviewed and merged in incrementally?

@DamianGlowala
Copy link
Member

It certainly is, and I am only halfway through the reviewing process. It will be equally time-consuming for anyone to review once we're done with amendments.

I like this idea. Let's wait for what Michael says. We could continue making amendments here until I'm done, and then start splitting this finalised big PR into smaller chunks which can be more easily reviewed.

@GalacticHypernova
Copy link
Contributor Author

If you guys think it would be the smarter idea, I'm down. It's just that I read that docs updates should be grouped and sent as a batch which is what I did. The bigger question here would be how to split this now that it has gotten this big.

GalacticHypernova and others added 3 commits May 13, 2023 08:27
Co-authored-by: Damian GΕ‚owala <48835293+DamianGlowala@users.noreply.github.com>
Co-authored-by: Damian GΕ‚owala <48835293+DamianGlowala@users.noreply.github.com>
@Barbapapazes
Copy link
Contributor

Barbapapazes commented May 13, 2023

If you guys think it would be the smarter idea, I'm down. It's just that I read that docs updates should be grouped and sent as a batch which is what I did. The bigger question here would be how to split this now that it has gotten this big.

Maybe you could split by folder?

  1. 1.getting-started/**
  2. 2.guides/1.concepts/**
  3. 2.guides/2.directory-structure/**
  4. 2.guides/3.going-further/**
  5. 3.api/1.composables/**
  6. 3.api/2.components/**
  7. 3.api/5.commands/**
  8. 3.api/**
  9. 4.exemples/**
  10. 5.community/**
  11. 6.bridge/**
  12. 7.migration/**

(each item could be a PR)

which will make a good number of pr!

@GalacticHypernova
Copy link
Contributor Author

GalacticHypernova commented May 13, 2023

If you guys think it would be the smarter idea, I'm down. It's just that I read that docs updates should be grouped and sent as a batch which is what I did. The bigger question here would be how to split this now that it has gotten this big.

Maybe you could split by folder?

  1. 1.getting-started/**
  2. 2.guides/1.concepts/**
  3. 2.guides/2.directory-structure/**
  4. 2.guides/3.going-further/**
  5. 3.api/1.composables/**
  6. 3.api/2.components/**
  7. 3.api/5.commands/**
  8. 3.api/**
  9. 4.exemples/**
  10. 5.community/**
  11. 6.bridge/**
  12. 7.migration/**

(each item could be a PR)

which will make a good number of pr!

Hmm, it might be good, but that would mean I'll have to open multiple PR's, wouldn't it? I dont want to be a bother and spam too much. And would I be able to open a PR and just drag and drop the files I have in this branch to each PR accordingly?

@Barbapapazes
Copy link
Contributor

Barbapapazes commented May 15, 2023

If you guys think it would be the smarter idea, I'm down. It's just that I read that docs updates should be grouped and sent as a batch which is what I did. The bigger question here would be how to split this now that it has gotten this big.

Maybe you could split by folder?

  1. 1.getting-started/**
  2. 2.guides/1.concepts/**
  3. 2.guides/2.directory-structure/**
  4. 2.guides/3.going-further/**
  5. 3.api/1.composables/**
  6. 3.api/2.components/**
  7. 3.api/5.commands/**
  8. 3.api/**
  9. 4.exemples/**
  10. 5.community/**
  11. 6.bridge/**
  12. 7.migration/**

(each item could be a PR)
which will make a good number of pr!

Hmm, it might be good, but that would mean I'll have to open multiple PR's, wouldn't it? I dont want to be a bother and spam too much. And would I be able to open a PR and just drag and drop the files I have in this branch to each PR accordingly?

I think it's not spam because PR are meaning full.

And yes, you can easily create a PR with drag and drop. (https://docs.github.com/en/repositories/working-with-files/managing-files/adding-a-file-to-a-repository)

@danielroe
Copy link
Member

See my comment in #21040 (comment). I hate to close this as it has so many good changes, but it will be too tricky to merge + review. 😒

@danielroe danielroe closed this Apr 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants