-
Notifications
You must be signed in to change notification settings - Fork 23
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: Replace broken, sprawling jsonschema2md
output with 3 compact guides generated by Fadroma
#276
Conversation
Huh, more build fail. Guess it's time for me to have another go at running the whole Docusaurus locally. Btw, kudos for sticking with Yarn 1 👍 Newer versions of that package manager completely jumped the shark. I have reasons to suspect yall would love https://pnpm.io if you gave it a try though |
Okay, so the docusaurus is looking good!
I think this is ready for another CI run. Let 'er rip! |
@egasimus AFAIU, the job No worries. We can go through this error and still proceed with the merge. |
@egasimus My feedback: The result is impressive, and I love the presentation of the documentation, which is not only readable but also highly useful and capable of enhancing the Developer Experience (DX)! 🤩 After the initial review with @amimart, we identified the following areas for improvement:
|
Hoped so! :)
Yeah, this one stood out to me as well. It's the same in the input schema, missing newlines and all: Maybe
Good catch. This is because Docusausus lowercases the anchor ids. I'll make the script do likewise, and update the PR. |
Okay, this seems to have fixed the inner links.
|
Hey guys, any progress on merging this? |
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.
Hey @egasimus ! Sorry for the delay ! That seems wonderful for the rendering 😍.
On the other hand I prefer to remove all the rendering (render.sh
) generation from this docs
repository. I suggest you to remove it and let the new generated documentation like you have done. The generation should be done inside the contracts
repository (in the makefile), because it could be useful inside this repository to have a well formatted documentation (like is done today with json2schema
). Then once the contracts is released, docs
repository will fetch and updated the contracts documentation with the new generated ones.
I can take care of the contracts
parts if you want.
Agreed! Since you already have a setup that copies the Markdown files from
Yes, please proceed with what is necessary to finalize this :-) |
I've regenerated the schema docs for old versions and added a footer containing links to the doc generation tool as well as SHA256 checksum of the source schema. See also: axone-protocol/contracts#342 |
Please decide if the footer should be removed and let me know here, so we can finally fix your API docs for good :-) |
Let's keep as it is, with the footer :) |
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.
Good job!
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.
Awesome, thank you for bringing this, it has great value 🙏
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.
Great! Thanks so much ❤️
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.
Thanks for this 🙏 ! Nice 👍
My pleasure! 🙇♂️ |
I wrote a custom JSONSchema renderer over the last few days; it can be found here.
The script is native ES with zero dependencies, so it imposes no new limitations on the doc gen workflow. It can be copied it into the repo, or (once published), it can be consumed from a JS CDN on Node 18+.
The goal was to remove all things that are not relevant to practical usage of the contract API. For example:
As an API consumer, I care about literally none of this JSONSchema metadata which is on every page of the current docs:
And why does each string constant/enum variant need its own page just to be mentioned in the corner at the end of it?
Instead, let's keep the original JSON schemas available to anyone who has a preferred JSON Schema viewer, or wants to use the schemas for validation, etc.
But let's also generate a more concise Markdown overview of each contract and make that the API reference. Here's what those Markdowns look like, as of today.
okp4/docs
next):Invaluable benefit of throwing out the frameworks: once again, things start at the beginning.
Compact yet detailed descriptions, incl. enum definitions and cross-linking of non-primitive types:
All messages of a kind are in one place:
More type definitions (previously affected by #273) now render correctly - even the newlines in the tables.
Same as above but some
Execute
messages:As a finisher, here's how much code it takes (total, no dependencies other than Node):
Overall, I'm quite happy with how this doc rendering thingy is turning out. I believe this format of API docs makes it way easier to find info on how to interact with the contracts, and is much closer to what a newcomer would need to get started with the OKP4 platform.
Please review this PR and point out if something is missing, wrong, or needs to be clarified further.
P.S. Progress on the interactive schema-browser that I mentioned in #273 can be followed here - and it looks even better than the Hedgedoc screenshots ;-) Since its stack is slightly more complex, for now let's see how the Markdowns go though