Support for docs website

[EchoEllet]

Currently, one of the things that need to be improved in this project is the documentation, in this issue we're mainly talking about the usage docs and not internal docs, providing docs in Dart doc comment is essential however users are often prefer to have something that they can search in search engine. A fast solution that makes navigating between pages and sections easier without going to the doc directory or us having to provide links and manage them manually, also search functionality is essential.

The doc directory and the README.md also might also some details and usage docs, currently our first priority is to document the internal code itself to make it more readable and understandable with clear labels without hardcoding things. We do have a lot of questions about the code itself and there are many answers to each questions, we're not sure since we can easily introduce a regression.

We do need the following to provide for the users:

• Search functionality, that's fast, and all the HTML files are already cached and generated and search between different pages or at least sections or info within the same page
• Support for SEO, all relevant info should be found when searching in popular search engines like Google. Due to how Flutter Web works, this is not a feature, and providing it will require workarounds.
• Markdown support, all existing markdown files should be compatible, and should not use anything specific that's not commonly used, the website generates the HTML files from the markdown, and using Quill Delta is also an option for writing the docs. Maybe we will use the editor itself to write docs for the editor's usage?
• Being able to contribute to the docs, update and edit it directly in this repo if the docs website is separated, while this is not a requirement, it would be nice to have.
• Other features, such as switching between dark and light mode, embedding the editor using Flutter web (see Adding Flutter to any web application), maybe a playground, we might remove light mode support though dark mode should be the default.
• We don't need localizations anytime soon for the docs, localization of the docs doubles the efforts that are required to maintain the docs, the project is in active development and when we change something, we need to update all references in the code itself, example, README.md and doc directory to ensure to reference the latest supported code, the easiest way to localize the website is to extract the code and share it across different pages for different locals (for SEO), so when we change something for the default language, we need to update it for 40 locals, we prefer to not use AI and automate such tasks especially when we don't have a reason to, currently all localizations in flutter_quill itself is community driven and are not reviewed with cautious, we only ensure that it doesn't have anything inappropriate, no review for the quality itself. We need to improve this before thinking about localizing the website, as such our solution will be simplified and not meant for multi-languages.

We have many options:

• GitBook which automates this whole process with a few clicks, the only issue is that only one member can access and manage the docs, having an organization do require billing and more setup we want to avoid when we don't need to.
• MkDocs and other docs generators which also automate the process, we only need to deploy the website.
• Kobweb which has API that's similar to Jetpack Compose using Compose HTML, even though Compose HTML is part of the Compose multiplatform repo it's not the same as Compsoe for web which also in the same repo, Compose HTML will be similar to building web apps using HTML, CSS and Javascript, instead having them all in one language in a type-safe way, it will generate the HTML files with all the related assets. Embedding Flutter web can also be a feature, not as simple as calling and importing the QuillEditor from flutter_quill though it's possible to showcase the editor quickly in the website without having to build the example, also will be helpful to confirm if a bug was fixed quickly without switching to a branch from fork and build the app if the issue is not platform specific, will also help us improve the web support if we have usage for it.
• Flutter Web, why not Flutter web itself? The main issue is the lack of support for SEO, loading times, and performance, we might consider using Flutter/WASM target, still, SEO is an essential feature.
• Many other Javascript frameworks, Javascript is full of frameworks and I see news about new frameworks every day even when I don't use Javascript, CSS libraries should be minimal to use in Kobweb and Compose HTML, however anything that uses Javascript needs to have an adapter for Kotlin to support Type check and type safety, dukat is an experimental tool to automate the process of generating those adapters from Typescript declarations, we might also consider using JS framework with TypeScript with all the modern features for front end web app (we don't need a backend and shouldn't be a feature). Some projects are already started to write Kotlin adapters for modern JS and CSS (with Sass frameworks) which are wrappers to the library. Since Kotlin is not known here in this repo, we might also consider not using it if most of the developers here are familiar with JS or TypeScript.

Note that we should focus on the project itself to prioritize critical issues and not build our own front-end solution from scratch since that's not the point of this issue.

[EchoEllet]

@CatHood0 I remember you mentioned that we should consider alternatives other than GitBook because we can only have one maintainer to manage it, maybe we could consider using GitBook once again even if this is not a feature, if it's compatible with our existing Markdown files and doesn't require any changes special to their platform, we can use other solution at any time.

[CatHood0]

@EchoEllet I will admit that GitBook is not bad. It is easy to use and doing anything quickly requires very little time, in addition to making Markdown convertion directly into the format that they use in the GitBook documents. I don't like that you can only invite other maintainers if you pay, but I can't fault it either.

I can restore the entire page I created in GitBook again. I have no problem with them.

I will leave the decision to you. If we should use it for now, I will restore the changes and add the missing documentation to the page.

[EchoEllet]

This is currently not a critical issue, so we can delay it if you want.

As long as it doesn't require maintenance, doesn't require any changes to the repo or require having any data on their service website, and it can sync the data we have here, then we should good to go.

Also, we should not heavily depend on it, so we don't use links as reference in the code from the docs website from them, so we can migrate smoothly later.

My question is, does it fully manage everything and sync it from the dco directory, or does it require some changes and adjustments to fit some need? The last time I used it, the result looked slightly different from yours. Did you change some things manually? If yes, then we need to know what we might need to change manually so we can decide if we should use it or find another alternative.