From 7fc4f3b186c74be07c41214036a1369638812bac Mon Sep 17 00:00:00 2001 From: Ilya Azin Date: Tue, 6 Sep 2022 15:52:43 +0300 Subject: [PATCH] setup draft --- README.md | 2 +- docusaurus.config.js | 95 +++++----- .../current/about/promote/integration.mdx | 2 +- .../current/get-started/basics.md | 142 --------------- .../current/get-started/index.mdx | 6 +- .../current/get-started/overview.md | 172 ++++++++++++++++++ .../current/intro.mdx | 89 +-------- i18n/en/docusaurus-theme-classic/footer.json | 2 +- .../current/about/promote/integration.mdx | 2 +- .../current/intro.mdx | 1 + i18n/ru/docusaurus-theme-classic/footer.json | 2 +- routes.config.js | 22 +-- src/app/index.scss | 13 +- src/features/header/ui.jsx | 2 +- src/pages/versions/index.jsx | 2 +- 15 files changed, 257 insertions(+), 297 deletions(-) delete mode 100644 i18n/en/docusaurus-plugin-content-docs/current/get-started/basics.md create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/get-started/overview.md diff --git a/README.md b/README.md index c811ba051d..c2953fd182 100644 --- a/README.md +++ b/README.md @@ -238,7 +238,7 @@ If there are variations, how best to place indents-welcome:) [refs-contributing]: CONTRIBUTING.md -[refs-docs]: https://feature-sliced.design/docs/intro +[refs-docs]: https://feature-sliced.design/docs [refs-motivation]: https://feature-sliced.design/docs/about/motivation [refs-motivation-why]: https://feature-sliced.design/docs/about/motivation#-почему-не-хватает-существующих-решений diff --git a/docusaurus.config.js b/docusaurus.config.js index 552584ebbe..11ccedf18e 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -31,47 +31,57 @@ const navbar = { }, items: [ // left + // { + // type: "dropdown", + // label: "📖 Docs", + // position: "left", + // items: [ + // // { + // // label: "🔎 Intro", + // // to: SECTIONS.INTRO.fullPath, + // // activeBasePath: SECTIONS.INTRO.fullPath, + // // }, + // { + // label: "🚀 Get Started", + // to: SECTIONS.GET_STARTED.shortPath, + // activeBasePath: SECTIONS.GET_STARTED.shortPath, + // }, + // { + // label: "🎯 Guides", + // to: SECTIONS.GUIDES.shortPath, + // activeBasePath: SECTIONS.GUIDES.shortPath, + // }, + // { + // label: "🧩 Concepts", + // to: SECTIONS.CONCEPTS.shortPath, + // activeBasePath: SECTIONS.CONCEPTS.shortPath, + // }, + // { + // label: "📚 Reference", + // to: SECTIONS.REFERENCE.shortPath, + // activeBasePath: SECTIONS.REFERENCE.shortPath, + // }, + // { + // label: "🍰 About", + // to: SECTIONS.ABOUT.shortPath, + // activeBasePath: SECTIONS.ABOUT.shortPath, + // }, + // { + // label: "💫 Community", + // to: SECTIONS.COMMUNITY.fullPath, + // activeBasePath: SECTIONS.COMMUNITY.fullPath, + // }, + // ], + // }, { - type: "dropdown", label: "📖 Docs", + to: "/docs", + position: "left", + }, + { + label: "📝 Blog", + to: "/blog", position: "left", - items: [ - { - label: "🔎 Intro", - to: SECTIONS.INTRO.fullPath, - activeBasePath: SECTIONS.INTRO.fullPath, - }, - { - label: "🚀 Get Started", - to: SECTIONS.GET_STARTED.shortPath, - activeBasePath: SECTIONS.GET_STARTED.shortPath, - }, - { - label: "🎯 Guides", - to: SECTIONS.GUIDES.shortPath, - activeBasePath: SECTIONS.GUIDES.shortPath, - }, - { - label: "🧩 Concepts", - to: SECTIONS.CONCEPTS.shortPath, - activeBasePath: SECTIONS.CONCEPTS.shortPath, - }, - { - label: "📚 Reference", - to: SECTIONS.REFERENCE.shortPath, - activeBasePath: SECTIONS.REFERENCE.shortPath, - }, - { - label: "🍰 About", - to: SECTIONS.ABOUT.shortPath, - activeBasePath: SECTIONS.ABOUT.shortPath, - }, - { - label: "💫 Community", - to: SECTIONS.COMMUNITY.fullPath, - activeBasePath: SECTIONS.COMMUNITY.fullPath, - }, - ], }, { label: "🛠 Examples", @@ -83,11 +93,6 @@ const navbar = { to: "/nav", position: "left", }, - { - label: "📝 Blog", - to: "/blog", - position: "left", - }, // right { type: "docsVersionDropdown", @@ -145,7 +150,7 @@ const footer = { { title: "Specs", items: [ - { label: "Documentation", to: "/docs/intro" }, + { label: "Documentation", to: "/docs" }, { label: "Discussions", to: `${GITHUB_DOCS}/discussions` }, ], }, @@ -374,7 +379,7 @@ module.exports = { }, i18n: { defaultLocale: DEFAULT_LOCALE, - locales: ["ru", "en"], + locales: ["en"], localeConfigs: { ru: { label: "Русский", diff --git a/i18n/en/docusaurus-plugin-content-docs/current/about/promote/integration.mdx b/i18n/en/docusaurus-plugin-content-docs/current/about/promote/integration.mdx index cc3189c22c..cc29cd4d75 100644 --- a/i18n/en/docusaurus-plugin-content-docs/current/about/promote/integration.mdx +++ b/i18n/en/docusaurus-plugin-content-docs/current/about/promote/integration.mdx @@ -13,7 +13,7 @@ First 5 minutes (RU): ## Also **Advantages**: -- [Overview](/docs/intro#overview) +- [Overview](/docs/get-started/overview) - CodeReview - Onboarding diff --git a/i18n/en/docusaurus-plugin-content-docs/current/get-started/basics.md b/i18n/en/docusaurus-plugin-content-docs/current/get-started/basics.md deleted file mode 100644 index 93645469cd..0000000000 --- a/i18n/en/docusaurus-plugin-content-docs/current/get-started/basics.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Basics - -:::caution - -Only basic information on the methodology is presented here - -For a more competent application, it is worth getting acquainted with each concept in more detail in the corresponding section of the documentation - -::: - -## Concepts - -### [`Public API`][refs-public-api] - -Each module must have a **declaration of its public API** at the top level - -- To connect to other modules, without the need to refer to the internal structure of this module -- To isolate the implementation details from the consumer modules -- Also, the Public API should protect the module interface after refactoring - in order to avoid unforeseen consequences - -### [`Isolation`][refs-isolation] - -The module should not **depend directly** on other modules of the same layer or overlying layers - -- The concept is also known as [Low Coupling & High Cohesion][refs-low-coupling] - to prevent implicit connections / side effects during development and refactoring - -### [`Needs driven`][refs-needs-driven] - -Orientation **to the needs of the business and the user** - -- Also includes splitting the structure by business domains *(["layers"][refs-splitting-layers] and ["slices"][refs-splitting-slices])* - -## Abstractions - -For [architecture design][refs-splitting] the methodology suggests operating with [familiar abstractions][refs-adaptability], but in a more consistent and consistent order. - -### [`Layers`][refs-splitting-layers] - -The first level of abstraction is **according to the scope of influence** - -- `app` - initializing the application *(init, styles, providers,...)* -- `processes` - the business processes of the application control pages *(payment, auth, ...)* -- `pages` application page *(user-page, ...)* -- `features` - part of application functionality *(auth-by-oauth, ...)* -- `entities` - the business entity *(viewer, order, ...)* -- `shared` - reusable infrastructure code *(UIKit, libs, API, ...)* - -### [`Slices`][refs-splitting-slices] - -The second level of abstraction is **according to the business domain** - -The rules by which the code is divided into slices *depend on the specific project and its business rules* and are not determined by the methodology - -### [`Segments`][refs-splitting-segments] - -The third level of abstraction is **according to the purpose in the implementation** - -- `ui` - UI-representation of the module *(components, widgets, canvas,...)* -- `model` - business logic of the module *(store, effects/actions, hooks/contracts,...)* -- `lib` - auxiliary libraries -- `api` - the logic of interaction with the API -- `config` - the configuration module of the application and its environment - -:::note - -In most cases, [it is recommended][ext-disc-api] to place `api` and `config` only in the shared layer - -::: - -## Structure - -```sh -└── src/ - ├── app/ # Layer: Application - | # - ├── processes/ # Layer: Processes (optional) - | ├── {some-process}/ # Slice: (e.g. CartPayment process) - | | ├── lib/ # Segment: Infrastructure-logic (helpers/utils) - | | └── model/ # Segment: Business Logic - | ... # - | # - ├── pages/ # Layer: Pages - | ├── {some-page}/ # Slice: (e.g. ProfilePage page) - | | ├── lib/ # Segment: Infrastructure-logic (helpers/utils) - | | ├── model/ # Segment: Business Logic - | | └── ui/ # Segment: UI logic - | ... # - | # - ├── widgets/ # Layer: Widgets - ├── {some-widget}/ # Slice: (e.g. Header widget) - | | ├── lib/ # Segment: Infrastructure-logic (helpers/utils) - | | ├── model/ # Segment: Business Logic - | | └── ui/ # Segment: UI logic - ├── features/ # Layer: Features - | ├── {some-feature}/ # Slice: (e.g. AuthByPhone feature) - | | ├── lib/ # Segment: Infrastructure-logic (helpers/utils) - | | ├── model/ # Segment: Business Logic - | | └── ui/ # Segment: UI logic - | ... # - | # - ├── entities/ # Layer: Business Entities - | ├── {some-entity}/ # Slice: (e.g. entity User) - | | ├── lib/ # Segment: Infrastructure-logic (helpers/utils) - | | ├── model/ # Segment: Business Logic - | | └── ui/ # Segment: UI logic - | ... # - | # - ├── shared/ # Layer: Reused resources - | ├── api/ # Segment: Logic of API requests - | ├── config/ # Segment: Application configuration - | ├── lib/ # Segment: Infrastructure-application logic - | └── ui/ # Segment: UIKit of the application - | ... # - | # - └── index.tsx/ # -``` - -## See also - -- [(Section) Fundamental concepts of the methodology][refs-concepts] -- [(Section) Guides and examples on the application of the methodology][refs-guides] -- [(Article) About splitting the logic in the application. Modularization][refs-splitting] - -[ext-disc-api]: https://github.com/feature-sliced/documentation/discussions/66 - -[refs-concepts]: /docs/concepts -[refs-public-api]: /docs/concepts/public-api -[refs-isolation]: /docs/concepts/cross-communication -[refs-needs-driven]: /docs/concepts/needs-driven -[refs-adaptability]: /docs/concepts/naming-adaptability - -[refs-splitting]: /docs/concepts/app-splitting -[refs-splitting-layers]: /docs/concepts/app-splitting#group-layers -[refs-splitting-slices]: /docs/concepts/app-splitting#group-slices -[refs-splitting-segments]: /docs/concepts/app-splitting#group-segments - -[refs-guides]: /docs/guides -[refs-low-coupling]: /docs/concepts/low-coupling diff --git a/i18n/en/docusaurus-plugin-content-docs/current/get-started/index.mdx b/i18n/en/docusaurus-plugin-content-docs/current/get-started/index.mdx index 7a9ff24199..b3be2459fd 100644 --- a/i18n/en/docusaurus-plugin-content-docs/current/get-started/index.mdx +++ b/i18n/en/docusaurus-plugin-content-docs/current/get-started/index.mdx @@ -20,9 +20,9 @@ import Row from "@site/src/shared/ui/row/tmpl.mdx" import { RocketOutlined, BuildOutlined, SettingOutlined } from "@ant-design/icons"; + +## Basics + +In FSD, a [project consists][refs-splitting] of layers, each layer is made up of slices and each slice is made up of segments. + +![themed--scheme](/img/visual_schema.jpg) + +The layers are standardized across all projects and vertically arranged. Modules on one layer can only interact with modules from the layers strictly below. There are currently seven of them (bottom to top): + +1. `shared` — reusable functionality, detached from the specifics of the project/business. + (e.g. UIKit, libs, API) +2. `entities` — business entities. + (e.g., User, Product, Order) +3. `features` — user interactions, actions that bring business value to the user. + (e.g. SendComment, AddToCart, UsersSearch) +4. `widgets` — compositional layer to combine entities and features into meaningful blocks. + (e.g. IssuesList, UserProfile) +5. `pages` — compositional layer to construct full pages from entities, features and widgets. +6. `processes` — complex inter-page scenarios. + (e.g., authentication) +7. `app` — app-wide settings, styles and providers. + + +Then there are slices, which partition the code by business domain. This makes your codebase easy to navigate by keeping logically related modules close together. Slices cannot use other slices on the same layer, and that helps with high cohesion and low coupling. + +Each slice, in turn, consists of segments. These are tiny modules that are meant to help with separating code within a slice by its technical purpose. The most common segments are `ui`, `model` (store, actions), `api` and `lib` (utils/hooks), but you can omit some or add more, as you see fit. + +:::note + +In most cases, [it is recommended][ext-disc-api] to place `api` and `config` only in the shared layer + +::: + +**Also, FSD have few core-concepts:** +- [Public API][refs-public-api] - each module must have a *declaration of its public API* at the top level - without access to internal structure of modules with isolation of implementation +- [Isolation][refs-isolation] (Low Coupling & High Cohesion) - the module should not *depend directly* on other modules of the same layer or overlying layers (to prevent implicit connections and side effects during development and refactoring) +- [Domain Driven][refs-needs-driven] - orientation *to the needs of the business and the user* with [app splitting][refs-splitting] by business domains + +## Example + +Let's consider a social network application. + +* `app/` contains setup of routing, store and global styles. +* `processes/` contains the part of authentication that is responsible for reading/writing authentication tokens. +* `pages/` contains the route components for each page in the app, mostly composition, hardly any logic. + +Within that application, let's consider a post card in a news feed. + +* `widgets/` contains the "assembled" post card, with content and interactive buttons that are wired up to the relevant calls on the back-end. +* `features/` contains the interactivity of the card (e.g., like button) and the logic of processing those interactions. +* `entities/` contains the shell of the card with slots for content and the interactive elements. The tile representing the post author is also here, but in a different slice. + + +```sh +└── src/ + ├── app/ # Layer: Application + | # + ├── processes/ # Layer: Processes (optional) + | ├── {some-process}/ # Slice: (e.g. CartPayment process) + | | ├── lib/ # Segment: Utility logic (utils/hooks) + | | └── model/ # Segment: Business Logic + | ... # + ├── pages/ # Layer: Pages + | ├── {some-page}/ # Slice: (e.g. ProfilePage page) + | | ├── lib/ # Segment: Utility logic (utils/hooks) + | | ├── model/ # Segment: Business Logic + | | └── ui/ # Segment: UI logic + | ... # + ├── widgets/ # Layer: Widgets + | ├── {some-widget}/ # Slice: (e.g. Header widget) + | | ├── lib/ # Segment: Utility logic (utils/hooks) + | | ├── model/ # Segment: Business Logic + | | └── ui/ # Segment: UI logic + | ... # + ├── features/ # Layer: Features + | ├── {some-feature}/ # Slice: (e.g. AuthByPhone feature) + | | ├── lib/ # Segment: Utility logic (utils/hooks) + | | ├── model/ # Segment: Business Logic + | | └── ui/ # Segment: UI logic + | ... # + ├── entities/ # Layer: Business Entities + | ├── {some-entity}/ # Slice: (e.g. entity User) + | | ├── lib/ # Segment: Utility logic (utils/hooks) + | | ├── model/ # Segment: Business Logic + | | └── ui/ # Segment: UI logic + | ... # + ├── shared/ # Layer: Reused resources + | ├── api/ # Segment: Logic of API requests + | ├── config/ # Segment: Application configuration + | ├── lib/ # Segment: General utility logic + | └── ui/ # Segment: UIKit of the application + | ... # + └── index.tsx/ # +``` + +## Advantages + +- **Uniformity** + The code is organized by scope of influence (layers), by domain (slices), and by technical purpose (segments). + This creates a standardized architecture that is easier to comprehend for newcomers. + +- **Controlled reuse of logic** + Each architectural component has its purpose and predictable dependencies. + This keeps a balance between following the **DRY** principle and adaptation possibilities. + +- **Stability in face of changes and refactoring** + A module on a particular layer cannot use other modules on the same layer, or the layers above. + This enables isolated modifications without unforeseen consequences. + + +## Incremental adoption + +The power of FSD lies in _structured_ decomposition. At its finest, it enables to locate any part of code near-deterministically. However, the level of decomposition is a parameter, and each team can tweak it to strike a balance between simple adoption and the amount of benefits. + +Here's a proposed strategy to migrate an existing codebase to FSD, based on experience: + +1. Start by outlining the `app` and `shared` layers to create a foundation. Usually, these layers are the smallest. + +2. Distribute all of the existing UI across `widgets` and `pages`, even if they have dependencies that violate the rules of FSD. + +3. Start gradually increasing the precision of decomposition by separating `features` and `entities`, turning pages and widgets from logic-bearing layers into purely compositional layers. + +It's advised to refrain from adding new large entities while refactoring or refactoring only certain parts of the project. + +## See also + +- [(Section) Fundamental concepts of the methodology][refs-concepts] +- [(Section) Guides and examples on the application of the methodology][refs-guides] +- [(Article) About splitting the logic in the application. Modularization][refs-splitting] + +[ext-disc-api]: https://github.com/feature-sliced/documentation/discussions/66 + +[refs-concepts]: /docs/concepts +[refs-public-api]: /docs/concepts/public-api +[refs-isolation]: /docs/concepts/cross-communication +[refs-needs-driven]: /docs/concepts/needs-driven +[refs-adaptability]: /docs/concepts/naming-adaptability + +[refs-splitting]: /docs/concepts/app-splitting +[refs-splitting-layers]: /docs/concepts/app-splitting#group-layers +[refs-splitting-slices]: /docs/concepts/app-splitting#group-slices +[refs-splitting-segments]: /docs/concepts/app-splitting#group-segments + +[refs-guides]: /docs/guides +[refs-low-coupling]: /docs/concepts/low-coupling +[refs-examples]: /examples +[refs-clean-architecture]: https://medium.com/codex/clean-architecture-for-dummies-df6561d42c94 diff --git a/i18n/en/docusaurus-plugin-content-docs/current/intro.mdx b/i18n/en/docusaurus-plugin-content-docs/current/intro.mdx index c16d79f968..2c158f4496 100644 --- a/i18n/en/docusaurus-plugin-content-docs/current/intro.mdx +++ b/i18n/en/docusaurus-plugin-content-docs/current/intro.mdx @@ -1,94 +1,15 @@ --- sidebar_position: 1 +slug: / pagination_next: get-started/index --- -# 🔎 Intro - -OVERVIEW-ORIENTED +# Documentation ![feature-sliced-banner](/img/banner.jpg) **Feature-Sliced Design** (FSD) is an architectural methodology for scaffolding front-end applications. Simply put, it's a compilation of rules and conventions on organizing code. The main purpose of this methodology is to make the project more understandable and structured in the face of ever-changing business requirements. -## Is it right for me? - -FSD can be implemented in projects and teams of any size, but there are a few things to keep in mind: - -- This methodology is for front-end projects only. If you're looking for a back-end architecture, consider [Clean Architecture][refs-clean-architecture]. -- A very simple app of a single page might not need the benefits of FSD and suffer from the overhead. However, FSD promotes a nice way of thinking, so feel free to use on the tiniest projects if you want. -- A huge app, the size of the Google Cloud admin dashboard, will require a custom architecture. It could still be based on FSD, by the way. - -FSD doesn't enforce a particular programming language, UI framework or state manager — bring your own or see some [examples][refs-examples]. - -If you have an existing project, fear not — FSD can be adopted incrementally. Just make sure that your team is **in pain** from the current architecture, otherwise a switch might not be worth it. - -## Overview - -In FSD, a project consists of _layers_, each layer is made up of _slices_ and each slice is made up of _segments_. - -![themed--scheme](/img/visual_schema.jpg) - -The layers are standardized across all projects and vertically arranged. Modules on one layer can only interact with modules from the layers strictly below. There are currently seven of them (bottom to top): - -1. **Shared** — reusable functionality, detached from the specifics of the project/business. -2. **Entities** — business entities (e.g., User, Product, Order). -3. **Features** — user interactions, actions that bring business value to the user. -4. **Widgets** — compositional layer to combine entities and features into meaningful blocks. -5. **Pages** — compositional layer to construct full pages from entities, features and widgets. -6. **Processes** — complex inter-page scenarios (e.g., authentication). -7. **App** — app-wide settings, styles and providers. - -Then there are slices, which partition the code by business domain. This makes your codebase easy to navigate by keeping logically related modules close together. Slices cannot use other slices on the same layer, and that helps with high cohesion and low coupling. - -Each slice, in turn, consists of segments. These are tiny modules that are meant to help with separating code within a slice by its technical purpose. The most common segments are `ui`, `model`, `api` and `lib`, but you can omit some or add more, as you see fit. - -### Decomposition example - -Let's consider a social network application. - -* `app/` contains setup of routing, store and global styles. -* `processes/` contains the part of authentication that is responsible for reading/writing authentication tokens. -* `pages/` contains the route components for each page in the app, mostly composition, hardly any logic. - -Within that application, let's consider a post card in a news feed. - -* `widgets/` contains the "assembled" post card, with content and interactive buttons that are wired up to the relevant calls on the back-end. -* `features/` contains the interactivity of the card (e.g., like button) and the logic of processing those interactions. -* `entities/` contains the shell of the card with slots for content and the interactive elements. The tile representing the post author is also here, but in a different slice. - -### Advantages - -- **Uniformity** - The code is organized by scope of influence (layers), by domain (slices), and by technical purpose (segments). - This creates a standardized architecture that is easier to comprehend for newcomers. - -- **Controlled reuse of logic** - Each architectural component has its purpose and predictable dependencies. - This keeps a balance between following the **DRY** principle and adaptation possibilities. - -- **Stability in face of changes and refactoring** - A module on a particular layer cannot use other modules on the same layer, or the layers above. - This enables isolated modifications without unforeseen consequences. - - -## Incremental adoption - -The power of FSD lies in _structured_ decomposition. At its finest, it enables to locate any part of code near-deterministically. However, the level of decomposition is a parameter, and each team can tweak it to strike a balance between simple adoption and the amount of benefits. - -Here's a proposed strategy to migrate an existing codebase to FSD, based on experience: - -1. Start by outlining the `app` and `shared` layers to create a foundation. Usually, these layers are the smallest. - -2. Distribute all of the existing UI across `widgets` and `pages`, even if they have dependencies that violate the rules of FSD. - -3. Start gradually increasing the precision of decomposition by separating `features` and `entities`, turning pages and widgets from logic-bearing layers into purely compositional layers. - -It's advised to refrain from adding new large entities while refactoring or refactoring only certain parts of the project. - - -## What's next? - import Row from "@site/src/shared/ui/row/tmpl.mdx" import { RocketOutlined, ThunderboltOutlined, FundViewOutlined } from "@ant-design/icons"; import Link from "@docusaurus/Link"; @@ -98,7 +19,7 @@ import Link from "@docusaurus/Link"; description="A tour over the basic concepts and structure as well as a comprehensive review of a React sample project" to="/docs/get-started" Icon={"🚀"} - tags={['Basics', 'Quick start', 'FAQ']} + tags={['Overview', 'Quick start', 'FAQ']} /> - -[refs-examples]: /examples - -[refs-clean-architecture]: https://medium.com/codex/clean-architecture-for-dummies-df6561d42c94 diff --git a/i18n/en/docusaurus-theme-classic/footer.json b/i18n/en/docusaurus-theme-classic/footer.json index f129408d11..48cb65f586 100644 --- a/i18n/en/docusaurus-theme-classic/footer.json +++ b/i18n/en/docusaurus-theme-classic/footer.json @@ -13,7 +13,7 @@ }, "link.item.label.Documentation": { "message": "Documentation", - "description": "The label of footer link with label=Documentation linking to /docs/intro" + "description": "The label of footer link with label=Documentation linking to /docs" }, "link.item.label.Discussions": { "message": "Discussions", diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/about/promote/integration.mdx b/i18n/ru/docusaurus-plugin-content-docs/current/about/promote/integration.mdx index 6083b4387e..edcc78549a 100644 --- a/i18n/ru/docusaurus-plugin-content-docs/current/about/promote/integration.mdx +++ b/i18n/ru/docusaurus-plugin-content-docs/current/about/promote/integration.mdx @@ -13,7 +13,7 @@ sidebar_position: 1 ## Также {#also} **Преимущества**: -- [Overview](/docs/intro#overview) +- [Overview](/docs/get-started/overview#advantages) - CodeReview - Onboarding diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/intro.mdx b/i18n/ru/docusaurus-plugin-content-docs/current/intro.mdx index 23b217c4fb..7a2690ffc3 100644 --- a/i18n/ru/docusaurus-plugin-content-docs/current/intro.mdx +++ b/i18n/ru/docusaurus-plugin-content-docs/current/intro.mdx @@ -1,5 +1,6 @@ --- sidebar_position: 1 +slug: / pagination_next: get-started/index --- diff --git a/i18n/ru/docusaurus-theme-classic/footer.json b/i18n/ru/docusaurus-theme-classic/footer.json index 818084af3f..ac656a8817 100644 --- a/i18n/ru/docusaurus-theme-classic/footer.json +++ b/i18n/ru/docusaurus-theme-classic/footer.json @@ -13,7 +13,7 @@ }, "link.item.label.Documentation": { "message": "Документация", - "description": "The label of footer link with label=Документация linking to /docs/intro" + "description": "The label of footer link with label=Документация linking to /docs" }, "link.item.label.Discussions": { "message": "Обсуждения", diff --git a/routes.config.js b/routes.config.js index ba6d8745dd..e697d250e9 100644 --- a/routes.config.js +++ b/routes.config.js @@ -3,10 +3,10 @@ // FIXME: Clean up urls format (with new index-pages) const SECTIONS = { - INTRO: { - shortPath: "/docs", - fullPath: "/docs/intro", - }, + // INTRO: { + // shortPath: "/docs", + // fullPath: "/docs/intro", + // }, GET_STARTED: { shortPath: "/docs/get-started", fullPath: "/docs/get-started", @@ -55,11 +55,11 @@ const LEGACY_ROUTES = [ group: "🚀 Get Started", details: "Simplified and merged", children: [ - { - title: "Overview", - from: "/docs/get-started/overview", - to: "/docs/intro", - }, + // { + // title: "Overview", + // from: "/docs/get-started/overview", + // to: "/docs/intro", + // }, { title: "QuickStart", from: "/docs/get-started/tutorial/quick-start", @@ -296,7 +296,7 @@ const _TOTAL_ROUTES = [ "/docs/concepts/public-api", "/docs/concepts/signals", "/docs/get-started", - "/docs/get-started/basics", + "/docs/get-started/overview", "/docs/get-started/cheatsheet", "/docs/get-started/faq", "/docs/get-started/quick-start", @@ -319,7 +319,7 @@ const _TOTAL_ROUTES = [ "/docs/guides/migration/from-legacy", "/docs/guides/migration/from-v1", "/docs/guides/tech/with-nextjs", - "/docs/intro", + "/docs/", "/docs/privacy", "/docs/reference", "/docs/reference/glossary", diff --git a/src/app/index.scss b/src/app/index.scss index c2de09ac63..aee867e5e0 100644 --- a/src/app/index.scss +++ b/src/app/index.scss @@ -117,6 +117,13 @@ iframe { border-radius: 16px; } +mark { + padding: 2px; + color: #ffffff; + background-color: var(--ifm-color-primary); + border-radius: 4px; +} + /* media */ /* TODO: connect as file */ @@ -237,7 +244,7 @@ a[download] { } } - &__logo { - margin-right: 0; - } + // &__logo { + // margin-right: 0; + // } } diff --git a/src/features/header/ui.jsx b/src/features/header/ui.jsx index f9d99ba833..ff164691cc 100644 --- a/src/features/header/ui.jsx +++ b/src/features/header/ui.jsx @@ -14,7 +14,7 @@ export function Header() {

{siteConfig.title}

{translate({ id: "features.hero.tagline" })}

- + {translate({ id: "features.hero.get_started" })} diff --git a/src/pages/versions/index.jsx b/src/pages/versions/index.jsx index b8887f78e7..bfa7ff1d2f 100644 --- a/src/pages/versions/index.jsx +++ b/src/pages/versions/index.jsx @@ -39,7 +39,7 @@ function Version() { hrefTitle="Release Notes" > - Documentation + Documentation