-
Notifications
You must be signed in to change notification settings - Fork 607
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
Help us migrate & improve 🍉 documentation #1481
Comments
mdbook
to Docusaurusmdbook
to Docusaurus
I can help but would probably just need some direction since I've never done this before! Would be nice if there were more comprehensive tutorials & examples that way there'll probably be less issues opened where people ask how to do things (myself included haha). A couple things that I have found myself struggling / unable to really figure out personally would be:
A troubleshooting page of common problems (like #615) and a FAQ (dealing with the sync when offline, possibility of multiple relations to the same table, expo related questions, etc) would be useful as well. Also, there's someone with a PR open that is trying to add info to the observables section: #1447 which might be good as well I'll try to put together an example project that does the full front and backend sync if I can get some free time haha. It would be nice if people could submit their own example projects too and that way there could be a couple different kinds of examples (simple & complex) Also the demo is down: #1415 (comment) Some other things I noticed were that the migrations page is under the Advanced section but says:
If it is essential, I think it should be moved up closer to setup. My idea for sections with the current information would be something like:
Let me know what you think! Also, not sure if there are any other maintainers (with privileges to merge in PRs & close issues) on the repo? As far as I could tell, it's just you? Not sure if this is an option for 🍉 since it's a Nozbe repo but having more maintainers would probably help. I could probably put in a PR at https://github.com/pickhardt/maintainers-wanted if you were looking for active maintainers or just pin an issue to recruit some. |
I want to help too, do you have anything in mind related to how it should be structured in the repo? The current setup has the docs-master/ with the .md files and the generated docs/ folder. Can it be changed to something like the structure found in the react-native-navigation repo, it features the API reference you mentioned or even react-native-website Both of these examples also have versioning, is that something useful here? |
@ErickLuizA Yes, I'd like to change the structure a bit, it seems to confuse a lot of people that docs-master/ is the current version of docs that matches code on master, while Regarding versioning, it's a nice to have, but not super important to me. I think we can start with a simple docusaurus setup, then add API reference, and then maybe think about how to ship versioned docs. |
We have this! @ErickLuizA thank you for your contribution. The new website will be shipped alongside 0.26.0 release, for now you can view it locally like so:
|
@KrisLau Your help would be definitely appreciated. One thing you could start with if you're unsure about drafting new articles is just cleaning up the existing docs:
|
@radex Will do, I'll try to get to it as soon as I get some free time! |
@ErickLuizA Can you help out with that? In general, JSDoc or something similar to annotate symbols with text seems good. JSDoc has the advantage that is has been around for a very long time, so even if one breaks, there's always going to be some tool to extract it and format it somehow. It would be great not to have to duplicate types and just take function signatures automatically, and I think I've seen somewhere one-off scripts to help with that for Flow, but Flow just isn't that popular anymore, so it might be hard to maintain. Typedoc on the other hand looks interesting (though I don't really like how it formats the output), but I'm not sure it's a good idea to keep the main in-code documentation not in the main code but in the d.ts files. So I think it would be great to start with a working demo of jsdoc-to-mdx, and then iterate from there |
mdbook
to Docusaurus
I added some JSDoc comments to Database, Collection, etc. cc @ErickLuizA |
Also to Model, Schema, sync |
I have not been able to open a PR with the API Reference because I didn't find a way to make jsdoc-to-mdx work properly I will try to work on another solution, maybe with jsdoc-to-markdown, it does not work out of the box with docusaurus but it's more popular, I will see if it can work. |
I will help. |
@lucaswitch Much appreciated, do you need guidance as for where to start? |
I added JSDoc to Query class as well |
@KrisLau Nice, appreciated. A few nitpicks and the README, and we'll get that merged. |
Hi, would love to help if still possible! I don't know if that's the appropriate place to say this but I just tried the lib for the first time and I must say that getting a new app to work correctly with 🍉 following the documentation was a pain. Anyway, let me know if I can contribute! |
@adblanc You can! |
@radex I was busy, is there any new docs job left to do? |
@lucaswitch Some suggestions:
|
I'm starting on the task "Add TypeScript types to examples in the docs" not quite done yet. |
@radex |
Hey,
I'd like to migrate WatermelonDB docs from
mdbook
to Docusaurus, a de facto standard in the React/React Native community for project websites. With that, I'd also like documentation to feature an actual API reference, and not just guides. I hope that will help 🍉 users a lot.But with many other maintenance responsibilities on my mind, I'd like help from the community with this. Can you help?
The text was updated successfully, but these errors were encountered: