-
-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Discussion on tag format #5975
Discussion on tag format #5975
Conversation
Hi @mambax! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks! |
✔️ [V2] 🔨 Explore the source changes: 93593bc 🔍 Inspect the deploy log: https://app.netlify.com/sites/docusaurus-2/deploys/6197df9f3e82360008280138 😎 Browse the preview: https://deploy-preview-5975--docusaurus-2.netlify.app |
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-5975--docusaurus-2.netlify.app/ |
It's not quite my style to do TDD. Tests are always a pain especially with fixtures and mock implementations😅 So not much to offer. There's a Jest extension on vscode made by orta to facilitate TDD I believe, but I never turned it on.
I would prefer a map rather than a list. ---
# instead of this:
tags:
- release
- i18n
- recap
---
# or this:
tags:
- label: release
- label: i18n
- label: recap
---
# I'd like this:
release:
label: release
description: xxx
i18n:
label: i18n
description: xxx
recap:
label: recap
description: xxx
--- Just like authors, you can then reference them in docs/blog using keys: ---
tags: [release, i18n]
--- In this case, these strings are keys, not labels. If there isn't a matching key in the tags definition, Docusaurus would frown at you. |
Thanks @Josh-Cena! I see the map as very handy, I tried to avoid repeating more code but I see clearly the advantage. On it! Regarding TDD; I don't mean real book TDD. I just first want to reproduce the tests from the authors file as it's a better starting point than randomly coding around. I will close this PR as I made a mistake (I committed it from my work GH account and created the PR with my private one). Therefore I also mixed the CLAs. Will reopen. |
Just a first draft to discuss the format (the learning curve is quite steep but I am super motivated 🚀).
The challenge is that
Tag
can be either astring
or aTag
object.Should we account for both or only the
Tag
object?I try to do TDD for once writing the tests first but I feel I need to know the decision here and after that maybe a bit of guidance as when I look at the authors implementation it's not quite a two-liner 😏