This change hides the quickstart and doc nav bar links when you're on
the docs pages.
This gets around the issue of both of those links being
highlighted when you're on the docs pages.
This should work on 91.66% of browsers (according to [canIUse's data for
the `:has` selector](https://caniuse.com/?search=%3Ahas)). For older
browsers, the links will still be visible.
This PR cleans up the the CSS for the recent academy banners, sharing
styles where it seemed suitable.
Main points:
- share styling of the level badge between the links and the course
banner
- share styling of general banner shape, borders, spacing, between the
main unleash academy banner and the course-specific banner
Also does the following updates:
- change the button colors
- update the link in the main academy banner
This PR fixes the three issues in the nav bar:
1. The GitHub icon was rendered in black in light mode. It should be
white.
2. The toggle theme button's background was white in light mode. It
should be a darker green.
3. The navbar would intersect with the logo due to not compacting
correctly.
The first two issues were caused by using CSS nesting, which is
apparently not supported in Safari yet (and might only be supported if
you have enabled a flag in other browsers).
The last issue was fixed by changing the syntax of a media query. The
new syntax is unsupported in Safari.
Update the Unleash docs navbar according to the new spec:
Changing "estimated time burden" to "estimated time" (or "estimated
reading time"), is just a matter of changing the text in the files.
There's nothing special making it say burden other than plain text. That
can be done in a follow-up PR.
The new nav bar includes the Unleash academy and certification dropdowns
as well as the docs and quickstart items. On smaller screen sizes
(between 997 and 1150 px), we hide the word "Unleash" from "Unleash
academy" and "Unleash certification".
The narrowest nav bar:
![image](https://github.com/Unleash/unleash/assets/17786332/13d05b0b-8668-4ff0-b06e-5c3073f0dda8)
When Unleash pops back in:
![image](https://github.com/Unleash/unleash/assets/17786332/191ae3fe-5fca-4464-b79a-db6995e600c9)
---------
Co-authored-by: markunl <mark@getunleash.io>
This PR does the following:
1. Replaces all images in the anatomy of Unleash doc with new versions
that don't have text on transparent backgrounds. This makes the images
work on both light and dark backgrounds.
2. Removes the white background from images in the docs. This was only
there to make sure the anatomy images worked in dark mode too.
3. Uses the general docs background color (based on your preferred
theme) when zooming in on images.
We don't use the client for anything at the moment, so we can remove it.
While there are things we can use it for in the future, we should
instead add it back in when we get there.
This also removes the docs feedback form (which we haven't used since
the client stopped working)
## What
The main purpose of this PR is to
1. Delete the proxy docs in this repo and replace them with the proxy's
GitHub readme.
2. Add the docs for Unleash Edge.
### Detailed change description
This PR contains a lot of small changes in a large number of files. To
make it easier to get an overview, here's a detailed description of what
happens where:
#### In the `website/docs`directory
Except for the deletion of the proxy doc, all changes in this directory
are rewriting internal links, so that they point to the newly generated
document instead.
#### `package.json` and `yarn.lock`
When including the documentation for Edge, we also want to render the
mermaid diagrams it uses. Docusaurus supports this via a plugin. All
changes in these files are related to installing that plugin.
#### `docusaurus.config.js`
There's two types of changes in this file:
1. Mermaid-related changes: we ask docusaurus to render mermaid in
markdown files and add the plugin
2. Document generation. There's some rewrites to the sdk doc generation
plus an entirely new section that generates docs for Edge and the proxy
#### `sidebars.js`
Two things:
1. Add the edge docs
2. Move both the Edge and the proxy docs up a level, so that they're
directly under "reference docs" instead of nested inside "unleash
concepts".
#### In the `website/remote-content` directory
These are the remote content files. Previously, all of this lived only
in a `readme-fns.js` file, but with the introduction of Edge and proxy
docs, this has been moved into its own directory and refactored into
three files (`shared`, `sdks`, `edge-proxy`).
#### `custom.css`
Style updates to center mermaid diagrams and provide more space around
them.
#### In `static/img`
The image files that were included in the proxy doc and that have been
deleted.
## Why
For two reasons:
1. Reduce duplication for the proxy. Have one source of truth.
2. Add docs for edge.
## Discussion points and review wishes
This is a big PR, and I don't expect anyone to do a line-by-line review
of it, nor do I think that is particularly useful. Instead, I'd like to
ask reviewers to:
1. Visit the [documentation
preview](https://unleash-docs-git-docs-source-proxy-gh-unleash-team.vercel.app/reference/unleash-proxy)
and have a look at both the proxy docs and the Edge docs. Potentially
have a look at the SDK docs too to verify that everything still works.
2. Consider whether they think moving the proxy and edge docs up a level
(in the sidebar) makes sense.
3. Let me know what slug they'd prefer for the Edge docs. I've gone with
`unleash-edge` for now (so that it's
`docs.getunleash.io/reference/unleash-edge`), but we could potentially
also just use `edge`. WDYT?
4. Read through the detailed changes section.
5. Let me know if they have any other concerns or questions.
## Screenies
The new proxy doc:
![image](https://user-images.githubusercontent.com/17786332/219043145-1c75c83e-4191-45a3-acb5-775d05d13862.png)
The new edge doc:
![image](https://user-images.githubusercontent.com/17786332/219043220-1f5daf13-972e-4d56-8aaf-70ff1812863e.png)
This PR builds on the preceding doc auto-generation PRs and generates
documentation for the remaining server-side SDKs.
## Why
Refer to https://github.com/Unleash/unleash/pull/2809 for more context
about generating SDK docs.
## What
- Adds generation for the remaining server-side SDKs
- Moves generated docs from the `/reference/sdks` directory to
`/generated` directory.
- Makes sure that the URLs do not change because of the move by using
the `slug` frontmatter property.
- replaces relative github links in the markdown documents so that they
become absolute github links. (refer to the next section)
- Updates some image styling so that it doesn't apply to readme badges
(we don't need them using `display: block`)
### On link replacing:
This PR adds handling of links in the generated documentation.
Specifically, it changes links in one case:
Relative links to github. Links to code and other files in the
repository. These are prefixed with the repository's URL.
While this should work in most cases, it will fail in cases where the
links to the files are not on the repository's primary branch.
(typically main, but could also be "v3", for instance). In these cases,
the links will get a double branch in the URL and will fail. However, I
see no easy way around this (though suggestions are definitely
accepted!), and think it's a fair tradeoff. It takes the links from
"definitely failing" to "will work in the vast majority of cases".
Note: I originally also wanted to handle the case where the link is an
absolute link to docs.getunleash.io. We could turn these into relative
urls to avoid full page reloads and enjoy a smoother experience.
However, the client-side redirects don't work correctly if the relative
URL goes to a redirect page, so you end up with a 404 page. As such, I
think it's better to leave the links as absolute for now.
# PR 1: add remote content plugin and rust readme
## What
This PR does a few connected things:
1. It adds the ["docusaurus-plugin-remote-content" package](https://github.com/rdilweb/docusaurus-plugin-remote-content).
2. It adds configuration to make it work with Readmes found on GitHub.
3. It adds the Rust SDK's readme (replacing the link we used to have) as a proof of concept on how to do it.
## Why
With documentation split between GitHub readmes and the official docs, it's hard to keep everything up to date and in sync. It's also quite confusing that some information is only available in some places, but not in others.
We've talked about auto-including readmes from GitHub for a while, so here's a proof of concept (finally) 🥳
The intention is to get this merged and then to migrate the other SDK docs one by one, ensuring that everything in the documentation is also in the readme (so that no info is lost).
## Discussion points
### Generation directory
The current generation method generates the files into `/reference/sdks/<sdk name>`. I think this works for now, but it means it adds auto-generated files into a directory that you can't ignore (at least not yet).
We could instead generate them into `/generated/sdks` and update the slugs so that they still match the expected pattern.
However, this would make the sidebar a little harder to work with (for now). That said, there may be ways around it. It's worth exploring.
### Generation method
By default, this plugin will generate files whenever you build. That (probably) means that you need an internet connection _and_ that you'll end up with a bunch of untracked files.
An option is to only generate the files "manually" and commit them to the repo. That would allow you to build the project without an internet connection and would also remove the need for ignoring the files. We could automate the generation if we wanted to.
## Preview / Screenies
Visit [/reference/sdks/rust](https://unleash-docs-git-docs-include-sdk-readmes-unleash-team.vercel.app/reference/sdks/rust) in the preview to see what it looks like live.
![image](https://user-images.githubusercontent.com/17786332/210373446-784b7e69-0f36-4e9e-874a-2b06b863b603.png)
# PR 2: add go readme
This PR changes the docs generation to use the Go SDK's GitHub readme
for the SDK docs instead of a separate document.
## What
The changes in this PR are:
- Delete the existing Go SDK documentation. All the content in this
guide already exists in the Go readme.
- Add the Go SDK to the list of auto-generated readme docs
- Move the readme-related code into a separate module, `readme-fns.js`
(I'm not bullish about the file name: we can change it if you have
suggestions)
- Add a note to the top of all generated readmes saying you'll need an
API url and an API token. The note also links you to the relevant
reference and how-to docs.
## Why
Having two different bits of documentation for the same SDK is
troublesome. By only having the data in one place, we can avoid it going
out of sync and getting stale.
## What
This PR
1. adds a new topic document, "The Anatomy of Unleash", which explains
how Unleash is built up as a system.
2. It also moves the "topic guides" sidebar entry from position 4 to
position 2.
3. Finally, it introduces a new `Figure` component for the
documentation, to be used with images that should be shown with
captions.
## Why
Referring to the same numbers as mentioned above, here's some background
for these changes:
1. We have gotten requests from enterprise users for a way to help new
Unleash users understand the system. Together with customer success and
customer journey, we agreed that an explanatory guide would be suitable.
It aims to give the reader an introduction into what pieces constitute
the Unleash system.
2. As part of a discussion, it was suggested to move topic guides higher
up to make them more visible. There's a few reasons for this:
1. New users of Unleash should be able to keep reading about Unleash
after the basic introductory material. When left at the bottom, topic
guides are often overlooked
2. As a justification, it was proposed that reference docs are often the
last thing you look for, so it makes sense to put that last.
3. Thinking about a new user's flow, it also makes some sense: first
read introductory material, then dive deeper into what Unleash is and
what you can use it for, then look for how-to guides if you're stuck,
and finally consult the reference material for later.
3. These diagrams aren't necessarily very self-explanatory, so adding a
caption makes a lot of sense. We didn't have a component from this
previously, so I added one.
Co-authored-by: NicolaeUnleash <103567375+NicolaeUnleash@users.noreply.github.com>
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
## Commits
* docs: add raw export of anatomy document
* docs: move the topic guides section to near top of sidebar
* docs: add inter-doc links, some reformatting
* docs: fix broken links
* docs: add a Figure element for figures with captions
* docs: add more styling to figures
* docs: align on styles
* Fix: add fuller figure caption
* docs: rephrase heading
* Docs(test): try new way of importing images
* Docs(test): images take 3
* docs: Convert all images to using the figure component
* docs: add projects to list of top-level resources
* docs: add captions for all figures.
* docs: reorder images
* Docs(fix): typo: extra brackets
* Docs(style): remove box shadows and border on fig caption images
* Docs(chore): remove commented-out css
* Docs(refactor): use css variable for small font size.
To facilitate reusability and convey meaning.
* docs: rename anatomy doc
* docs: add note about strategies vs constraints
* Updating the images
* Apply suggestions from code review
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
* Update website/docs/topics/the-anatomy-of-unleash.mdx
* Docs(fix): remove redundant comma
* docs: add link to node js sdk
* docs: mention that a toggle must be active in an env to be enabled
* docs: add note about environments and api keys
* Docs(reword): swap dev and prod in example
* docs: fix typo in the image
* docs: make figures in text full-width
* docs: move environments and API keys call-out to after figure
* docs: add borders to figures
* docs: add image float css idea
* Revert "docs: add image float css idea"
This reverts commit 69f27d304b.
Co-authored-by: NicolaeUnleash <103567375+NicolaeUnleash@users.noreply.github.com>
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
## What
This PR (finally 🎉) adds generated OpenAPI docs to the official Unleash documentation. In addition to generating docs when things get merged to main, it also pushes new doc updates every day at 12:00 AM (cron `@daily`).
## Why
Now that we have OpenAPI'd all the things, we can finally start using it. This will allow us to remove hand-written api docs from the documentation and should make sure everything is always kept up to date.
### Generating from us-hosted (Unleash enterprise)
Unleash has several different versions (open source, pro, enterprise). The versions do not necessarily have the exact same api surface. In fact, the enterprise version has a few endpoints that open source does not.
Because we want to have _all_ endpoints listed in the documentation we need to generated the docs from an enterprise spec. Which brings us into the next point:
### The need for scheduled jobs
Regarding the daily scheduled tasks to update the documentation: why do we need that?
The docs are generated from the tip of the main branch. For most of the docs, this is good and something that we want. However, because the OpenAPI docs are generated from the enterprise edition, it _will not be in sync_ with the open source main branch.
Also, we probably do not want the docs to list the current bleeding edge api changes. Instead, we should prefer to use the latest enterprise release (roughly). However, because we don't get notified when this version is released and deployed, we'll instead run the API generation on a daily cadence.
This isn't the perfect solution, but it's simple and gets us 80% of the way there. More intricate solutions can be set up later.
## How
- By adding a scheduled workflow to the generate docs config.
- By adding .gitignore entries for the generated files
There's also some minor changes in styling etc.
## Dependencies
This is dependent on the changes introduced in #2062 having propagated to the enterprise release, which will probably not be for another week or so.
## Discussion
What should the API reference docs url be? I've set it to be `/reference/api/unleash/*` for now, but I'm on the fence about whether it should be `apis` or `api` in there. I also want to get the proxy and other APIs in there as we grow.
-------
## Commits
* docs: style openapi operation buttons
* docs: minor operation badge adjustments
* docs: use permalink to css snippet i copied
* docs: ignore files related to openapi generation
* docs: re-enable openapi docs
* Docs(#1391): prep for integration
* docs(#1391): run docs generation daily
* docs(#1391): add generation step to doc prs too
* docs(#1391): use the US hosted instance to generate docs
* docs(#1391): move doc generation into build command
* docs(#1391): use `/reference/api/*` instead of `/reference/apis/*`
* Docs: start experimenting with OpenAPI and docusaurus
* Docs: add docusaurus-theme-openapi-docs pkg
* Wip: current status
* Docs: Add 'docusaurus-plugin-api-docs'
* Move openapi into own sidebar; generate from localhost
* Chore: Update docusaurus plugin for OpenAPI
* Add website/yarn.lock to git
* Fix: fix CSS warning by using flex-end instead of end
* docs: make openapi generated code work again
* docs: make tags work properly with openapi sidebar
* Docs/chore: update OpenAPI tag scheme.
Add a whole bunch of new tags to make it easier to understand
available tags in OpenAPI.
* docs: point to new openapi docs from old api docs
* docs: typo
* Docs: link restructure
* docs: add operation indicators to openapi docs
* docs: change badge color for operations
* docs: update openapi-docs package
It now sorts tags the same as the schema
* docs: pluralize APIs in slug
* docs: update links to generated api docs
* docs: update openapi snapshot tests with new tags
* docs: conditionally load spec from localhost or from file
* docs: Remove changes relating to immediate switchover
* refactor: rename types; extract into separate file
* docs: fix api doc links
Because it previously set it via a reducer and submitted the form in
the same step, the customer type wouldn't be set correctly before the
form was submitted, causing it to show up as "undefined".
We're doing double the work now, but I think that's an acceptable
trade-off for now.