Skip to content

Commit 2528d2c

Browse files
tsutomitsutomi
authored
Enhance Docusaurus documentation with versioning and autogenerated sidebar (#80)
* feat: prepare docs for Docusaurus versioning with autogenerated sidebar - Replace static sidebars.ts with autogenerated sidebar - Add sidebar_position frontmatter to all docs - Add _category_.json files for senders, connectors, samples * feat: add Docusaurus docs versioning for v1.0.5 through v1.1.2 - Snapshot versioned docs at tags v1.0.5, v1.0.6, v1.1.1, v1.1.2 - Add version config with labels, paths, and banners - Replace static navbar links with docsVersionDropdown - Each version has an autogenerated sidebar from its own files * fix: remove confusing Next version, show only released versions The 'Next' version represented unreleased in-development docs with no corresponding NuGet package. Set includeCurrentVersion: false to hide it. * fix: restore Next version with clearer label and unreleased banner * fix: use absolute path for logo in versioned docs Versioned READMEs from git tags used relative path src='ratatosk-full-logo.png' which Docusaurus doesn't serve at the resolved position. Changed to /img/... to point to the global static asset.
1 parent 088834e commit 2528d2c

171 files changed

Lines changed: 25668 additions & 61 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎docs/README.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
1+
---
2+
sidebar_position: 1
3+
---
4+
15
[![NuGet](https://img.shields.io/nuget/v/Ratatosk.Abstractions.svg?label=NuGet)](https://www.nuget.org/packages/Ratatosk.Abstractions/)
26
[![codecov](https://codecov.io/gh/deveel/ratatosk/graph/badge.svg)](https://codecov.io/gh/deveel/ratatosk)
37
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://github.com/deveel/ratatosk/blob/main/LICENSE)

‎docs/advanced.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
1+
---
2+
sidebar_position: 14
3+
---
4+
15
# Advanced Configuration
26

37
The basic patterns — register a connector, build a message, send it — cover the common cases. Production deployments introduce additional concerns: keeping credentials secure, monitoring connector health, understanding performance characteristics, and testing thoroughly without sending real messages.

‎docs/authentication.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
1+
---
2+
sidebar_position: 9
3+
---
4+
15
# Authentication
26

37
Every messaging provider requires some form of authentication — an API key, a bearer token, a username and password pair, or an OAuth 2.0 client credentials flow. If every connector handled auth internally, each would duplicate logic for token refresh, credential caching, and error handling. Authentication would be inconsistent across connectors, and adding a new auth scheme would require modifying every connector.

‎docs/channel-schema.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
1+
---
2+
sidebar_position: 6
3+
---
4+
15
# Channel Schema
26

37
A connector without a schema is a black box: you have no way to know what parameters it needs, what capabilities it offers, what message shapes it accepts, or what authentication it requires without reading its source code. The schema solves this by making every connector self-describing.

‎docs/connector-implementation.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
1+
---
2+
sidebar_position: 10
3+
---
4+
15
# Connector Implementation
26

37
Not every messaging provider has a ready-made connector in the framework. When you need to integrate with a custom or niche provider — an internal notification gateway, a legacy SMTP server, a proprietary chat system — you build a connector. The framework provides `ChannelConnectorBase`, an abstract base class that implements the `IChannelConnector` contract and handles all cross-cutting concerns so you only write the provider-specific translation layer.

‎docs/connectors/_category_.json‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
{
2+
"position": 20,
3+
"label": "Connectors"
4+
}

‎docs/connectors/facebook-messenger.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
1+
---
2+
sidebar_position: 5
3+
---
4+
15
# Facebook Messenger Connector
26

37
Send and receive messages through the Facebook Messenger Platform API using a Facebook Page.

‎docs/connectors/firebase-push.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
1+
---
2+
sidebar_position: 4
3+
---
4+
15
# Firebase Push Connector
26

37
Push notifications via Firebase Cloud Messaging (FCM) HTTP v1 API.

‎docs/connectors/sendgrid-email.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
1+
---
2+
sidebar_position: 3
3+
---
4+
15
# SendGrid Email Connector
26

37
Transactional and bulk email via the SendGrid v3 API.

‎docs/connectors/telegram-bot.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,7 @@
1+
---
2+
sidebar_position: 6
3+
---
4+
15
# Telegram Bot Connector
26

37
Send and receive messages through the Telegram Bot API.

0 commit comments

Comments
 (0)