-
+
-
+
+ {{ comment.text }} +
+
{user.name}
;
+}
+```
+
+For example, prevent `features/profile` from importing from paths like `features/auth/model/internal/*`. Restrict usage to only what `features/auth` explicitly exposes as its Public API.
+
+## When should cross-imports be treated as a problem?
+
+After reviewing these strategies, a natural question is:
+
+> When is a cross-import acceptable to keep, and when should it be treated as a code smell and refactored?
+
+Common warning signs:
+- directly depending on another slice's store/model/business logic
+- deep imports into another slice's internal files
+- **bidirectional dependencies** (A imports B, and B imports A)
+- changes in one slice frequently breaking another slice
+- flows that should be composed in `pages` / `app`, but are forced into cross-imports within the same layer
+
+When you see these signals, treat the cross-import as a **code smell** and consider applying at least one of the strategies above.
+
+## How strict you are is a team/project decision
+
+How strictly to enforce these rules depends on the team and project.
+
+For example:
+- In **early-stage products** with heavy experimentation, allowing some cross-imports may be a pragmatic speed trade-off.
+- In **long-lived or regulated systems** (for example, fintech or large-scale services), stricter boundaries often pay off in maintainability and stability.
+
+Cross-imports are not an absolute prohibition here. They are dependencies that are **generally best avoided**, but sometimes used intentionally.
+
+If you do introduce a cross-import:
+- treat it as a deliberate architectural choice
+- document the reasoning
+- revisit it periodically as the system evolves
+
+Teams should align on:
+- what strictness level they want
+- how to reflect it in lint rules, code review, and documentation
+- when and how to reevaluate existing cross-imports over time
+
+## References
- [(Thread) About the supposed inevitability of cross-ports](https://t.me/feature_sliced/4515)
- [(Thread) About resolving cross-ports in entities](https://t.me/feature_sliced/3678)
diff --git a/i18n/en/docusaurus-plugin-content-docs/current/guides/issues/desegmented.mdx b/i18n/en/docusaurus-plugin-content-docs/current/guides/issues/desegmented.mdx
index 1ba2b6e2e9..ed1de2d012 100644
--- a/i18n/en/docusaurus-plugin-content-docs/current/guides/issues/desegmented.mdx
+++ b/i18n/en/docusaurus-plugin-content-docs/current/guides/issues/desegmented.mdx
@@ -1,97 +1,140 @@
---
sidebar_position: 2
-sidebar_class_name: sidebar-item--wip
---
-import WIP from '@site/src/shared/ui/wip/tmpl.mdx'
-
-# Desegemented
-
-| Theme | +Logo (Ctrl/Cmd + Click for download) | +Usage | +
| primary (#29BEDC, #517AED) |
+  |
+ Preferred in most cases | +
| flat (#3193FF) |
+  |
+ For one-color context | +
| monochrome (#FFF) |
+  |
+ For grayscale context | +
| square (#3193FF) |
+  |
+ For square boundaries | +
+
+
+## Social Preview
+
+Work in progress...
+
+## Presentation template
+
+Work in progress...
+
+## See also
+
+- [Discussion (github)](https://github.com/feature-sliced/documentation/discussions/399)
+- [History of development with references (figma)](https://www.figma.com/file/RPphccpoeasVB0lMpZwPVR/FSD-Brand?node-id=0%3A1)
diff --git a/src/content/docs/docs/get-started/faq.mdx b/src/content/docs/docs/get-started/faq.mdx
new file mode 100644
index 0000000000..9f1f00c4fb
--- /dev/null
+++ b/src/content/docs/docs/get-started/faq.mdx
@@ -0,0 +1,68 @@
+---
+# pagination_next: guides/examples/auth
+title: FAQ
+sidebar:
+ order: 20
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+
+
+### Is there a toolkit or a linter?
+
+Yes! We have a linter called [Steiger][ext-steiger] to check your project's architecture and [folder generators][ext-tools] through a CLI or IDEs.
+
+### Where to store the layout/template of pages?
+
+If you need plain markup layouts, you can keep them in `shared/ui`. If you need to use higher layers inside, there are a few options:
+
+- Perhaps you don't need layouts at all? If the layout is only a few lines, it might be reasonable to duplicate the code in each page rather than try to abstract it.
+- If you do need layouts, you can have them as separate widgets or pages, and compose them in your router configuration in App. Nested routing is another option.
+
+### What is the difference between a feature and an entity?
+
+An _entity_ is a real-life concept that your app is working with. A _feature_ is an interaction that provides real-life value to your app’s users, the thing people want to do with your entities.
+
+For more information, along with examples, see the Reference page on [slices][reference-entities].
+
+### Can I embed pages/features/entities into each other?
+
+Yes, but this embedding should happen in higher layers. For example, inside a widget, you can import both features and then insert one feature into another as props/children.
+
+You cannot import one feature from another feature, this is prohibited by the [**import rule on layers**][import-rule-layers].
+
+### What about Atomic Design?
+
+The current version of the methodology does not require nor prohibit the use of Atomic Design together with Feature-Sliced Design.
+
+For example, Atomic Design [can be applied well](https://t.me/feature_sliced/1653) for the `ui` segment of modules.
+
+### Are there any useful resources/articles/etc. about FSD?
+
+Yes! https://github.com/feature-sliced/awesome
+
+### Why do I need Feature-Sliced Design?
+
+It helps you and your team to quickly overview the project in terms of its main value-bringing components. A standardized architecture helps to speed up onboarding and resolves debates about code structure. See the [motivation][motivation] page to learn more about why FSD was created.
+
+### Does a novice developer need an architecture/methodology?
+
+Rather yes than no
+
+*Usually, when you design and develop a project in one person, everything goes smoothly. But if there are pauses in development, new developers are added to the team - then problems come*
+
+### How do I work with the authorization context?
+
+Answered [here](/docs/guides/examples/auth)
+
+[ext-steiger]: https://github.com/feature-sliced/steiger
+[ext-tools]: https://github.com/feature-sliced/awesome?tab=readme-ov-file#tools
+[import-rule-layers]: /docs/reference/layers#import-rule-on-layers
+[reference-entities]: /docs/reference/layers#entities
+[motivation]: /docs/about/motivation
+[telegram]: https://t.me/feature_sliced
+[discord]: https://discord.gg/S8MzWTUsmp
+[github-discussions]: https://github.com/feature-sliced/documentation/discussions
diff --git a/src/content/docs/docs/get-started/overview.mdx b/src/content/docs/docs/get-started/overview.mdx
new file mode 100644
index 0000000000..7cd85d42ad
--- /dev/null
+++ b/src/content/docs/docs/get-started/overview.mdx
@@ -0,0 +1,166 @@
+---
+title: Overview
+sidebar:
+ order: 1
+---
+
+import { FileTree, LinkCard, Aside } from '@astrojs/starlight/components';
+
+**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 stable in the face of ever-changing business requirements.
+
+Apart from a set of conventions, FSD is also a toolchain. We have a [linter][ext-steiger] to check your project's architecture, [folder generators][ext-tools] through a CLI or IDEs, as well as a rich library of [examples][examples].
+
+## Is it right for me? \{#is-it-right-for-me\}
+
+FSD can be implemented in projects and teams of any size. It is right for your project if:
+
+- You're doing **frontend** (UI on web, mobile, desktop, etc.)
+- You're building an **application**, not a library
+
+And that's it! There are no restrictions on what programming language, UI framework, or state manager you use. You can also adopt FSD incrementally, use it in monorepos, and scale to great lengths by breaking your app into packages and implementing FSD individually within them.
+
+If you already have an architecture and you're considering a switch to FSD, make sure that the current architecture is **causing trouble** in your team. For example, if your project has grown too large and inter-connected to efficiently implement new features, or if you're expecting a lot of new members to join the team. If the current architecture works, maybe it's not worth changing. But if you do decide to migrate, see the [Migration][migration] section for guidance.
+
+## Basic example \{#basic-example\}
+
+Here is a simple project that implements FSD:
+
+Pictured above: three pillars, labeled left to right as "Layers", "Slices", and "Segments" respectively.
+The "Layers" pillar contains seven divisions arranged top to bottom and labeled "app", "processes", "pages", "widgets", "features", "entities", and "shared". The "processes" division is crossed out. The "entities" division is connected to the second pillar "Slices" in a way that conveys that the second pillar is the content of "entities".
+The "Slices" pillar contains three divisions arranged top to bottom and labeled "user", "post", and "comment". The "post" division is connected to the third pillar "Segments" in the same way such that it's the content of "post".
+The "Segments" pillar contains three divisions, arranged top to bottom and labeled "ui", "model", and "api".
+
+
+ );
+}
+```
+
+Then re-export this component in the feed page’s public API, the `pages/feed/index.ts` file:
+
+
+
+```ts title="pages/feed/index.ts"
+export { FeedPage } from "./ui/FeedPage";
+```
+
+Now connect it to the root route. In Remix, routing is file-based, and the route files are located in the `app/routes` folder, which nicely coincides with Feature-Sliced Design.
+
+Use the `FeedPage` component in `app/routes/_index.tsx`:
+
+```tsx title="app/routes/_index.tsx"
+import type { MetaFunction } from "@remix-run/node";
+import { FeedPage } from "pages/feed";
+
+export const meta: MetaFunction = () => {
+ return [{ title: "Conduit" }];
+};
+
+export default FeedPage;
+```
+
+Then, if you run the dev server and open the application, you should see the Conduit banner!
+
+
+
+### API client
+
+To talk to the RealWorld backend, let’s create a convenient API client in Shared. Create two segments, `api` for the client and `config` for variables like the backend base URL:
+
+```bash
+npx fsd shared --segments api config
+```
+
+Then create `shared/config/backend.ts`:
+
+```tsx title="shared/config/backend.ts"
+export { mockBackendUrl as backendBaseUrl } from "mocks/handlers";
+```
+
+```tsx title="shared/config/index.ts"
+export { backendBaseUrl } from "./backend";
+```
+
+Since the RealWorld project conveniently provides an [OpenAPI specification](https://github.com/gothinkster/realworld/blob/main/api/openapi.yml), we can take advantage of auto-generated types for our client. We will use [the `openapi-fetch` package](https://openapi-ts.pages.dev/openapi-fetch/) that comes with an additional type generator.
+
+Run the following command to generate up-to-date API typings:
+
+```bash
+npm run generate-api-types
+```
+
+This will create a file `shared/api/v1.d.ts`. We will use this file to create a typed API client in `shared/api/client.ts`:
+
+```tsx title="shared/api/client.ts"
+import createClient from "openapi-fetch";
+
+import { backendBaseUrl } from "shared/config";
+import type { paths } from "./v1";
+
+export const { GET, POST, PUT, DELETE } = createClient
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+ );
+}
+```
+
+The like button doesn’t do anything for now, we will fix that when we get to the article reader page and implement the liking functionality.
+
+Now we can fetch the articles and render out a bunch of these cards. Fetching data in Remix is done with *loaders* — server-side functions that fetch exactly what a page needs. Loaders interact with the API on the page’s behalf, so we will put them in the `api` segment of a page:
+
+```tsx title="pages/feed/api/loader.ts"
+import { json } from "@remix-run/node";
+
+import { GET } from "shared/api";
+
+export const loader = async () => {
+ const { data: articles, error, response } = await GET("/articles");
+
+ if (error !== undefined) {
+ throw json(error, { status: response.status });
+ }
+
+ return json({ articles });
+};
+```
+
+To connect it to the page, we need to export it with the name `loader` from the route file:
+
+```tsx title="pages/feed/index.ts"
+export { FeedPage } from "./ui/FeedPage";
+export { loader } from "./api/loader";
+```
+
+```tsx title="app/routes/_index.tsx"
+import type { MetaFunction } from "@remix-run/node";
+import { FeedPage } from "pages/feed";
+
+export { loader } from "pages/feed";
+
+export const meta: MetaFunction = () => {
+ return [{ title: "Conduit" }];
+};
+
+export default FeedPage;
+```
+
+And the final step is to render these cards in the feed. Update your `FeedPage` with the following code:
+
+```tsx title="pages/feed/ui/FeedPage.tsx"
+import { useLoaderData } from "@remix-run/react";
+
+import type { loader } from "../api/loader";
+import { ArticlePreview } from "./ArticlePreview";
+
+export function FeedPage() {
+ const { articles } = useLoaderData
+
+ 
+
+
+
+
+
+ {article.author.username}
+
+
+ {new Date(article.createdAt).toLocaleDateString(undefined, {
+ dateStyle: "long",
+ })}
+
+
+
+ {article.title}
+{article.description}
+ Read more... +-
+ {article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+
+ );
+}
+```
+
+### Filtering by tag
+
+Regarding the tags, our job is to fetch them from the backend and to store the currently selected tag. We already know how to do fetching — it’s another request from the loader. We will use a convenience function `promiseHash` from a package `remix-utils`, which is already installed.
+
+Update the loader file, `pages/feed/api/loader.ts`, with the following code:
+
+```tsx title="pages/feed/api/loader.ts"
+import { json } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+ );
+}
+```
+
+Then we need to use the `tag` search parameter in our loader. Change the `loader` function in `pages/feed/api/loader.ts` to the following:
+
+```tsx title="pages/feed/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+
+
+
+ Popular Tags
+ + +
+
+ );
+}
+```
+
+So that’s also done. There’s also the tab list that can be similarly implemented, but let’s hold on to that until we implement authentication. Speaking of which!
+
+### Authentication
+
+Authentication involves two pages — one to login and another to register. They are mostly the same, so it makes sense to keep them in the same slice, `sign-in`, so that they can reuse code if needed.
+
+Create `RegisterPage.tsx` in the `ui` segment of `pages/sign-in` with the following content:
+
+```tsx title="pages/sign-in/ui/RegisterPage.tsx"
+import { Form, Link, useActionData } from "@remix-run/react";
+
+import type { register } from "../api/register";
+
+export function RegisterPage() {
+ const registerData = useActionData
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+
+
+
+ Popular Tags
+ + +
+
+ );
+}
+```
+
+We have a broken import to fix now. It involves a new segment, so create that:
+
+```bash
+npx fsd pages sign-in -s api
+```
+
+However, before we can implement the backend part of registering, we need some infrastructure code for Remix to handle sessions. That goes to Shared, in case any other page needs it.
+
+Put the following code in `shared/api/auth.server.ts`. This is highly Remix-specific, so don’t worry too much about it, just copy-paste:
+
+```tsx title="shared/api/auth.server.ts"
+import { createCookieSessionStorage, redirect } from "@remix-run/node";
+import invariant from "tiny-invariant";
+
+import type { User } from "./models";
+
+invariant(
+ process.env.SESSION_SECRET,
+ "SESSION_SECRET must be set for authentication to work",
+);
+
+const sessionStorage = createCookieSessionStorage<{
+ user: User;
+}>({
+ cookie: {
+ name: "__session",
+ httpOnly: true,
+ path: "/",
+ sameSite: "lax",
+ secrets: [process.env.SESSION_SECRET],
+ secure: process.env.NODE_ENV === "production",
+ },
+});
+
+export async function createUserSession({
+ request,
+ user,
+ redirectTo,
+}: {
+ request: Request;
+ user: User;
+ redirectTo: string;
+}) {
+ const cookie = request.headers.get("Cookie");
+ const session = await sessionStorage.getSession(cookie);
+
+ session.set("user", user);
+
+ return redirect(redirectTo, {
+ headers: {
+ "Set-Cookie": await sessionStorage.commitSession(session, {
+ maxAge: 60 * 60 * 24 * 7, // 7 days
+ }),
+ },
+ });
+}
+
+export async function getUserFromSession(request: Request) {
+ const cookie = request.headers.get("Cookie");
+ const session = await sessionStorage.getSession(cookie);
+
+ return session.get("user") ?? null;
+}
+
+export async function requireUser(request: Request) {
+ const user = await getUserFromSession(request);
+
+ if (user === null) {
+ throw redirect("/login");
+ }
+
+ return user;
+}
+```
+
+And also export the `User` model from the `models.ts` file right next to it:
+
+```tsx title="shared/api/models.ts"
+import type { components } from "./v1";
+
+export type Article = components["schemas"]["Article"];
+export type User = components["schemas"]["User"];
+```
+
+Before this code can work, the `SESSION_SECRET` environment variable needs to be set. Create a file called `.env` in the root of the project, write `SESSION_SECRET=` and then mash some keys on your keyboard to create a long random string. You should get something like this:
+
+```bash title=".env"
+SESSION_SECRET=dontyoudarecopypastethis
+```
+
+Finally, add some exports to the public API to make use of this code:
+
+```tsx title="shared/api/index.ts"
+export { GET, POST, PUT, DELETE } from "./client";
+
+export type { Article } from "./models";
+
+export { createUserSession, getUserFromSession, requireUser } from "./auth.server";
+```
+
+Now we can write the code that will talk to the RealWorld backend to actually do the registration. We will keep that in `pages/sign-in/api`. Create a file called `register.ts` and put the following code inside:
+
+```tsx title="pages/sign-in/api/register.ts"
+import { json, type ActionFunctionArgs } from "@remix-run/node";
+
+import { POST, createUserSession } from "shared/api";
+
+export const register = async ({ request }: ActionFunctionArgs) => {
+ const formData = await request.formData();
+ const username = formData.get("username")?.toString() ?? "";
+ const email = formData.get("email")?.toString() ?? "";
+ const password = formData.get("password")?.toString() ?? "";
+
+ const { data, error } = await POST("/users", {
+ body: { user: { email, password, username } },
+ });
+
+ if (error) {
+ return json({ error }, { status: 400 });
+ } else {
+ return createUserSession({
+ request: request,
+ user: data.user,
+ redirectTo: "/",
+ });
+ }
+};
+```
+
+```tsx title="pages/sign-in/index.ts"
+export { RegisterPage } from './ui/RegisterPage';
+export { register } from './api/register';
+```
+
+Almost done! Just need to connect the page and action to the `/register` route. Create `register.tsx` in `app/routes`:
+
+```tsx title="app/routes/register.tsx"
+import { RegisterPage, register } from "pages/sign-in";
+
+export { register as action };
+
+export default RegisterPage;
+```
+
+Now if you go to [http://localhost:3000/register](http://localhost:3000/register), you should be able to create a user! The rest of the application won’t react to this yet, we’ll address that momentarily.
+
+In a very similar way, we can implement the login page. Give it a try or just grab the code and move on:
+
+```tsx title="pages/sign-in/api/sign-in.ts"
+import { json, type ActionFunctionArgs } from "@remix-run/node";
+
+import { POST, createUserSession } from "shared/api";
+
+export const signIn = async ({ request }: ActionFunctionArgs) => {
+ const formData = await request.formData();
+ const email = formData.get("email")?.toString() ?? "";
+ const password = formData.get("password")?.toString() ?? "";
+
+ const { data, error } = await POST("/users/login", {
+ body: { user: { email, password } },
+ });
+
+ if (error) {
+ return json({ error }, { status: 400 });
+ } else {
+ return createUserSession({
+ request: request,
+ user: data.user,
+ redirectTo: "/",
+ });
+ }
+};
+```
+
+```tsx title="pages/sign-in/ui/SignInPage.tsx"
+import { Form, Link, useActionData } from "@remix-run/react";
+
+import type { signIn } from "../api/sign-in";
+
+export function SignInPage() {
+ const signInData = useActionData
+
+
+
+
+
+ Sign up
++ Have an account? +
+ + {registerData?.error && ( +-
+ {registerData.error.errors.body.map((error) => (
+
- {error} + ))} +
+
+ );
+}
+```
+
+```tsx title="pages/sign-in/index.ts"
+export { RegisterPage } from './ui/RegisterPage';
+export { register } from './api/register';
+export { SignInPage } from './ui/SignInPage';
+export { signIn } from './api/sign-in';
+```
+
+```tsx title="app/routes/login.tsx"
+import { SignInPage, signIn } from "pages/sign-in";
+
+export { signIn as action };
+
+export default SignInPage;
+```
+
+Now let’s give the users a way to actually get to these pages.
+
+### Header
+
+As we discussed in part 1, the app header is commonly placed either in Widgets or in Shared. We will put it in Shared because it’s very simple and all the business logic can be kept outside of it. Let’s create a place for it:
+
+```bash
+npx fsd shared ui
+```
+
+Now create `shared/ui/Header.tsx` with the following contents:
+
+```tsx title="shared/ui/Header.tsx"
+import { useContext } from "react";
+import { Link, useLocation } from "@remix-run/react";
+
+import { CurrentUser } from "../api/currentUser";
+
+export function Header() {
+ const currentUser = useContext(CurrentUser);
+ const { pathname } = useLocation();
+
+ return (
+
+ );
+}
+```
+
+Export this component from `shared/ui`:
+
+```tsx title="shared/ui/index.ts"
+export { Header } from "./Header";
+```
+
+In the header, we rely on the context that’s kept in `shared/api`. Create that as well:
+
+```tsx title="shared/api/currentUser.ts"
+import { createContext } from "react";
+
+import type { User } from "./models";
+
+export const CurrentUser = createContext
+
+
+
+
+
+ Sign in
++ Need an account? +
+ + {signInData?.error && ( +-
+ {signInData.error.errors.body.map((error) => (
+
- {error} + ))} +
+
+ );
+}
+```
+
+```tsx title="pages/feed/ui/Pagination.tsx"
+import { Form, useLoaderData, useSearchParams } from "@remix-run/react";
+import { ExistingSearchParams } from "remix-utils/existing-search-params";
+
+import { LIMIT, type loader } from "../api/loader";
+
+export function Pagination() {
+ const [searchParams] = useSearchParams();
+ const { articles } = useLoaderDataPopular Tags
+ + +
+
+ );
+}
+```
+
+We also need to account for the new tab in the loader function:
+
+```tsx title="pages/feed/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET, requireUser } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+This code will send a POST request to `/article/:slug` with `_action=favorite` to mark the article as favorite. It won’t work yet, but as we start working on the article reader, we will implement this too.
+
+And with that we are officially done with the feed! Yay!
+
+### Article reader
+
+First, we need data. Let’s create a loader:
+
+```bash
+npx fsd pages article-read -s api
+```
+
+```tsx title="pages/article-read/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import invariant from "tiny-invariant";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET, getUserFromSession } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+
+
+
+ {article.author.username}
+
+
+ {new Date(article.createdAt).toLocaleDateString(undefined, {
+ dateStyle: "long",
+ })}
+
+
+
+ {article.title}
+{article.description}
+ Read more... +-
+ {article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+
+ );
+}
+```
+
+What’s more interesting is the `ArticleMeta` and `Comments`. They contain write operations such as liking an article, leaving a comment, etc. To get them to work, we first need to implement the backend part. Create `action.ts` in the `api` segment of the page:
+
+```tsx title="pages/article-read/api/action.ts"
+import { redirect, type ActionFunctionArgs } from "@remix-run/node";
+import { namedAction } from "remix-utils/named-action";
+import { redirectBack } from "remix-utils/redirect-back";
+import invariant from "tiny-invariant";
+
+import { DELETE, POST, requireUser } from "shared/api";
+
+export const action = async ({ request, params }: ActionFunctionArgs) => {
+ const currentUser = await requireUser(request);
+
+ const authorization = { Authorization: `Token ${currentUser.token}` };
+
+ const formData = await request.formData();
+
+ return namedAction(formData, {
+ async delete() {
+ invariant(params.slug, "Expected a slug parameter");
+ await DELETE("/articles/{slug}", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirect("/");
+ },
+ async favorite() {
+ invariant(params.slug, "Expected a slug parameter");
+ await POST("/articles/{slug}/favorite", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async unfavorite() {
+ invariant(params.slug, "Expected a slug parameter");
+ await DELETE("/articles/{slug}/favorite", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async createComment() {
+ invariant(params.slug, "Expected a slug parameter");
+ const comment = formData.get("comment");
+ invariant(typeof comment === "string", "Expected a comment parameter");
+ await POST("/articles/{slug}/comments", {
+ params: { path: { slug: params.slug } },
+ headers: { ...authorization, "Content-Type": "application/json" },
+ body: { comment: { body: comment } },
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async deleteComment() {
+ invariant(params.slug, "Expected a slug parameter");
+ const commentId = formData.get("id");
+ invariant(typeof commentId === "string", "Expected an id parameter");
+ const commentIdNumeric = parseInt(commentId, 10);
+ invariant(
+ !Number.isNaN(commentIdNumeric),
+ "Expected a numeric id parameter",
+ );
+ await DELETE("/articles/{slug}/comments/{id}", {
+ params: { path: { slug: params.slug, id: commentIdNumeric } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async followAuthor() {
+ const authorUsername = formData.get("username");
+ invariant(
+ typeof authorUsername === "string",
+ "Expected a username parameter",
+ );
+ await POST("/profiles/{username}/follow", {
+ params: { path: { username: authorUsername } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async unfollowAuthor() {
+ const authorUsername = formData.get("username");
+ invariant(
+ typeof authorUsername === "string",
+ "Expected a username parameter",
+ );
+ await DELETE("/profiles/{username}/follow", {
+ params: { path: { username: authorUsername } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ });
+};
+```
+
+Export that from the slice and then from the route. While we’re at it, let’s also connect the page itself:
+
+```tsx title="pages/article-read/index.ts"
+export { ArticleReadPage } from "./ui/ArticleReadPage";
+export { loader } from "./api/loader";
+export { action } from "./api/action";
+```
+
+```tsx title="app/routes/article.$slug.tsx"
+import { ArticleReadPage } from "pages/article-read";
+
+export { loader, action } from "pages/article-read";
+
+export default ArticleReadPage;
+```
+
+Now, even though we haven’t implemented the like button on the reader page yet, the like button in the feed will start working! That’s because it’s been sending “like” requests to this route. Give that a try.
+
+`ArticleMeta` and `Comments` are, again, a bunch of forms. We’ve done this before, let’s grab their code and move on:
+
+```tsx title="pages/article-read/ui/ArticleMeta.tsx"
+import { Form, Link, useLoaderData } from "@remix-run/react";
+import { useContext } from "react";
+
+import { CurrentUser } from "shared/api";
+import type { loader } from "../api/loader";
+
+export function ArticleMeta() {
+ const currentUser = useContext(CurrentUser);
+ const { article } = useLoaderData
+
+
+
+
+ {article.article.title}
+ +
+
+ +
+
+
+
+
+
+ {article.article.body}
+-
+ {article.article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+ +
+
+
+
+
+
+ {currentUser !== null ? (
+
+ ) : (
+
+ );
+}
+```
+
+And with that our article reader is also complete! The buttons to follow the author, like a post, and leave a comment should now function as expected.
+
+
+
+ )}
+
+ {comments.comments.map((comment) => (
+
+
+ + Sign in + or + Sign up + to add comments on this article. +
+
+
+ ))}
+
+
+
+ {comment.body}
+
+
+ 
+
+
+
+ {comment.author.username}
+
+ {comment.createdAt}
+ {comment.author.username === currentUser?.username && (
+
+
+
+ )}
+
+
+
+ );
+}
+```
+
+This page gets the current article (unless we’re writing from scratch) and fills in the corresponding form fields. We’ve seen this before. The interesting part is `FormErrors`, because it will receive the validation result and display it to the user. Let’s take a look:
+
+```tsx title="pages/article-edit/ui/FormErrors.tsx"
+import { useActionData } from "@remix-run/react";
+import type { action } from "../api/action";
+
+export function FormErrors() {
+ const actionData = useActionData
+
+
+
+
+
+ -
+ {actionData.errors.map((error) => (
+
- {error} + ))} +
+ {tagListState.map((tag) => (
+
+
+ [" ", "Enter"].includes(e.key) && removeTag(tag)
+ }
+ onClick={() => removeTag(tag)}
+ >{" "}
+ {tag}
+
+ ))}
+
+
+ );
+}
+```
+
+Now, for the API part. The loader should look at the URL, and if it contains an article slug, that means we’re editing an existing article, and its data should be loaded. Otherwise, return nothing. Let’s create that loader:
+
+```ts title="pages/article-edit/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+
+import { GET, requireUser } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+```ts title="shared/ui/layout/useThemeSwitcher.ts"
+export function useThemeSwitcher() {
+ const [theme, setTheme] = useState("light");
+
+ function toggleTheme() {
+ setTheme(theme === "light" ? "dark" : "light");
+ }
+
+ useEffect(() => {
+ document.body.classList.remove("light", "dark");
+ document.body.classList.add(theme);
+ }, [theme]);
+
+ return [theme, toggleTheme] as const;
+}
+```
+
+The code of sidebars is left as an exercise for the reader 😉.
+
+## Using widgets in the layout
+
+Sometimes you want to include certain business logic in the layout, especially if you're using deeply nested routes with a router like [React Router][ext-react-router]. Then you can't store the layout in Shared or in Widgets due to [the import rule on layers][import-rule-on-layers]:
+
+> A module in a slice can only import other slices when they are located on layers strictly below.
+
+Before we discuss solutions, we need to discuss if it's even a problem in the first place. Do you _really need_ that layout, and if so, does it _really need_ to be a Widget? If the block of business logic in question is reused on 2-3 pages, and the layout is simply a small wrapper for that widget, consider one of these two options:
+
+1. **Write the layout inline on the App layer, where you configure the routing**
+ This is great for routers that support nesting, because you can group certain routes and apply the layout only to them.
+
+2. **Just copy-paste it**
+ The urge to abstract code is often very overrated. It is especially the case for layouts, which rarely change. At some point, if one of these pages will need to change, you can simply do the change without needlessly affecting other pages. If you're worried that someone might forget to update the other pages, you can always leave a comment that describes the relationship between the pages.
+
+If none of the above are applicable, there are two solutions to include a widget in the layout:
+
+1. **Use render props or slots**
+ Most frameworks allow you to pass a piece of UI externally. In React, it's called [render props][ext-render-props], in Vue it's called [slots][ext-vue-slots].
+2. **Move the layout to the App layer**
+ You can also store your layout on the App layer, for example, in `app/layouts`, and compose any widgets you want.
+
+## Further reading
+
+- There's an example of how to build a layout with authentication with React and Remix (equivalent to React Router) in the [tutorial][tutorial].
+
+[tutorial]: /docs/get-started/tutorial
+[import-rule-on-layers]: /docs/reference/layers#import-rule-on-layers
+[ext-react-router]: https://reactrouter.com/
+[ext-render-props]: https://www.patterns.dev/react/render-props-pattern/
+[ext-vue-slots]: https://vuejs.org/guide/components/slots
diff --git a/src/content/docs/docs/guides/examples/types.mdx b/src/content/docs/docs/guides/examples/types.mdx
new file mode 100644
index 0000000000..b27c6eacba
--- /dev/null
+++ b/src/content/docs/docs/guides/examples/types.mdx
@@ -0,0 +1,436 @@
+---
+title: Types
+sidebar:
+ order: 2
+---
+
+import { FileTree, Aside } from '@astrojs/starlight/components';
+
+This guide concerns data types from typed languages like TypeScript and describes where they fit within FSD.
+
+
+
+## Utility types
+
+Utility types are types that don't have much meaning on their own and are usually used with other types. For example:
+
+```ts
+type ArrayValues
+
+ );
+}
+```
+
+With this structure, `features/userProfile` and `features/activityFeed` do not know about each other. `pages/UserDashboardPage` composes them to build the full screen.
+
+#### Render props example (React):
+
+When one feature needs to render content from another, use render props to invert the dependency:
+
+```tsx title="features/commentList/ui/CommentList.tsx"
+interface CommentListProps {
+ comments: Comment[];
+ renderUserAvatar?: (userId: string) => React.ReactNode;
+}
+
+export function CommentList({ comments, renderUserAvatar }: CommentListProps) {
+ return (
+ -
+ {comments.map(comment => (
+
- + {renderUserAvatar?.(comment.userId)} + {comment.text} + + ))} +
-
+
-
+
+ {{ comment.text }} +
+
{user.name}
;
+}
+```
+
+For example, prevent `features/profile` from importing from paths like `features/auth/model/internal/*`. Restrict usage to only what `features/auth` explicitly exposes as its Public API.
+
+## When should cross-imports be treated as a problem?
+
+After reviewing these strategies, a natural question is:
+
+> When is a cross-import acceptable to keep, and when should it be treated as a code smell and refactored?
+
+Common warning signs:
+- directly depending on another slice's store/model/business logic
+- deep imports into another slice's internal files
+- **bidirectional dependencies** (A imports B, and B imports A)
+- changes in one slice frequently breaking another slice
+- flows that should be composed in `pages` / `app`, but are forced into cross-imports within the same layer
+
+When you see these signals, treat the cross-import as a **code smell** and consider applying at least one of the strategies above.
+
+## How strict you are is a team/project decision
+
+How strictly to enforce these rules depends on the team and project.
+
+For example:
+- In **early-stage products** with heavy experimentation, allowing some cross-imports may be a pragmatic speed trade-off.
+- In **long-lived or regulated systems** (for example, fintech or large-scale services), stricter boundaries often pay off in maintainability and stability.
+
+Cross-imports are not an absolute prohibition here. They are dependencies that are **generally best avoided**, but sometimes used intentionally.
+
+If you do introduce a cross-import:
+- treat it as a deliberate architectural choice
+- document the reasoning
+- revisit it periodically as the system evolves
+
+Teams should align on:
+- what strictness level they want
+- how to reflect it in lint rules, code review, and documentation
+- when and how to reevaluate existing cross-imports over time
+
+## References
+
+- [(Thread) About the supposed inevitability of cross-ports](https://t.me/feature_sliced/4515)
+- [(Thread) About resolving cross-ports in entities](https://t.me/feature_sliced/3678)
+- [(Thread) About cross-imports and responsibility](https://t.me/feature_sliced/3287)
+- [(Thread) About imports between segments](https://t.me/feature_sliced/4021)
+- [(Thread) About cross-imports inside shared](https://t.me/feature_sliced/3618)
diff --git a/src/content/docs/docs/guides/issues/desegmented.mdx b/src/content/docs/docs/guides/issues/desegmented.mdx
new file mode 100644
index 0000000000..c9eed3c6e5
--- /dev/null
+++ b/src/content/docs/docs/guides/issues/desegmented.mdx
@@ -0,0 +1,147 @@
+---
+title: Desegmentation
+sidebar:
+ order: 2
+---
+
+import { Tabs, TabItem, FileTree } from '@astrojs/starlight/components';
+
+Desegmentation (also known as horizontal slicing or packaging by layer) is a code organization pattern where files are grouped by their technical roles rather than by the business domains they serve. This means code with similar technical functions is stored in the same place, regardless of the business logic it handles.
+
+This approach is popular in meta-frameworks like Next and Nuxt due to its simplicity, as it's easy to get started and enables features like auto-imports and file-based routing:
+
+My Custom App component
+Loading...
;
+ }
+
+ if (isError || !post) {
+ return <>{error?.message};
+ }
+
+ return (
+
+
+ );
+};
+```
+
+### Benefits of using a Query Factory
+- **Request structuring:** A factory allows you to organize all API requests in one place, making your code more readable and maintainable.
+- **Convenient access to queries and keys:** The factory provides convenient methods for accessing different types of queries and their keys.
+- **Query Refetching Ability:** The factory allows easy refetching without the need to change query keys in different parts of the application.
+
+## Pagination
+
+In this section, we'll look at an example of the `getPosts` function, which makes an API request to retrieve post entities using pagination.
+
+### 1. Creating a function `getPosts`
+The getPosts function is located in the `get-posts.ts` file, which is located in the `api` segment
+
+```tsx title="@/pages/post-feed/api/get-posts.ts"
+import { apiClient } from "@/shared/api/base";
+
+import { PostWithPaginationDto } from "./dto/post-with-pagination.dto";
+import { PostQuery } from "./query/post.query";
+import { mapPost } from "./mapper/map-post";
+import { PostWithPagination } from "../model/post-with-pagination";
+
+const calculatePostPage = (totalCount: number, limit: number) =>
+ Math.floor(totalCount / limit);
+
+export const getPosts = async (
+ page: number,
+ limit: number,
+): PromisePost id: {post.id}
+
+
+ {post.title}
+
+
+ {post.body}
+Owner: {post.userId}
+ 
+
+
+1. App
+2. Processes (deprecated)
+3. Pages
+4. Widgets
+5. Features
+6. Entities
+7. Shared
+
+You don't have to use every layer in your project — only add them if you think it brings value to your project. Typically, most frontend projects will have at least the Shared, Pages, and App layers.
+
+In practice, layers are folders with lowercase names (for example, `📁 shared`, `📁 pages`, `📁 app`). Adding new layers is _not recommended_ because their semantics are standardized.
+
+## Import rule on layers
+
+Layers are made up of _slices_ — highly cohesive groups of modules. Dependencies between slices are regulated by **the import rule on layers**:
+
+> _A module (file) in a slice can only import other slices when they are located on layers strictly below._
+
+For example, the folder `📁 ~/features/aaa` is a slice with the name "aaa". A file inside of it, `~/features/aaa/api/request.ts`, cannot import code from any file in `📁 ~/features/bbb`, but can import code from `📁 ~/entities` and `📁 ~/shared`, as well as any sibling code from `📁 ~/features/aaa`, for example, `~/features/aaa/lib/cache.ts`.
+
+Layers App and Shared are **exceptions** to this rule — they are both a layer and a slice at the same time. Slices partition code by business domain, and these two layers are exceptions because Shared does not have business domains, and App combines all business domains.
+
+In practice, this means that layers App and Shared are made up of segments, and segments can import each other freely.
+
+## Layer definitions
+
+This section describes the semantic meaning of each layer to create an intuition for what kind of code belongs there.
+
+### Shared
+
+This layer forms a foundation for the rest of the app. It's a place to create connections with the external world, for example, backends, third-party libraries, the environment. It is also a place to define your own highly contained libraries.
+
+This layer, like the App layer, _does not contain slices_. Slices are intended to divide the layer into business domains, but business domains do not exist in Shared. This means that all files in Shared can reference and import from each other.
+
+Here are the segments that you can typically find in this layer:
+
+- `📁 api` — the API client and potentially also functions to make requests to specific backend endpoints.
+- `📁 ui` — the application's UI kit.
+ Components on this layer should not contain business logic, but it's okay for them to be business-themed. For example, you can put the company logo and page layout here. Components with UI logic are also allowed (for example, autocomplete or a search bar).
+- `📁 lib` — a collection of internal libraries.
+ This folder should not be treated as helpers or utilities ([read here why these folders often turn into a dump][ext-sova-utility-dump]). Instead, every library in this folder should have one area of focus, for example, dates, colors, text manipulation, etc. That area of focus should be documented in a README file. The developers in your team should know what can and cannot be added to these libraries.
+- `📁 config` — environment variables, global feature flags and other global configuration for your app.
+- `📁 routes` — route constants or patterns for matching routes.
+- `📁 i18n` — setup code for translations, global translation strings.
+
+You are free to add more segments, but make sure that the name of these segments describes the purpose of the content, not its essence. For example, `components`, `hooks`, and `types` are bad segment names because they aren't that helpful when you're looking for code.
+
+### Entities
+
+Slices on this layer represent concepts from the real world that the project is working with. Commonly, they are the terms that the business uses to describe the product. For example, a social network might work with business entities like User, Post, and Group.
+
+An entity slice might contain the data storage (`📁 model`), data validation schemas (`📁 model`), entity-related API request functions (`📁 api`), as well as the visual representation of this entity in the interface (`📁 ui`). The visual representation doesn't have to produce a complete UI block — it is primarily meant to reuse the same appearance across several pages in the app, and different business logic may be attached to it through props or slots.
+
+#### Entity relationships
+
+Entities in FSD are slices, and by default, slices cannot know about each other. In real life, however, entities often interact with each other, and sometimes one entity owns or contains other entities. Because of that, the business logic of these interactions is preferably kept in higher layers, like Features or Pages.
+
+When one entity's data object contains other data objects, usually it's a good idea to make the connection between the entities explicit and side-step the slice isolation by making a cross-reference API with the `@x` notation. The reason is that connected entities need to be refactored together, so it's best to make the connection impossible to miss.
+
+For example:
+
+```ts title="entities/artist/model/artist.ts"
+import type { Song } from "entities/song/@x/artist";
+
+export interface Artist {
+ name: string;
+ songs: Array
+ 
+ 
+ 
+ | テーマ | +ロゴ (Ctrl/Cmd + Clickでダウンロード) | +使用法 | +
| primary (#29BEDC, #517AED) |
+  |
+ ほとんどの場合に推奨されます | +
| flat (#3193FF) |
+  |
+ 単色コンテキスト用 | +
| monochrome (#FFF) |
+  |
+ 白黒コンテキスト用 | +
| square (#3193FF) |
+  |
+ 正方形サイズ用 | +
+
+
+## ソーシャルプレビュー
+
+作業中...
+
+## プレゼンテーションテンプレート \{#presentation-template}
+
+作業中...
+
+## 参照 \{#see-also}
+
+- [ディスカッション (github)](https://github.com/feature-sliced/documentation/discussions/399)
+- [リブランディングの歴史と参考資料 (figma)](https://www.figma.com/file/RPphccpoeasVB0lMpZwPVR/FSD-Brand?node-id=0%3A1)
diff --git a/src/content/docs/ja/docs/get-started/faq.mdx b/src/content/docs/ja/docs/get-started/faq.mdx
new file mode 100644
index 0000000000..f8c12cb24d
--- /dev/null
+++ b/src/content/docs/ja/docs/get-started/faq.mdx
@@ -0,0 +1,67 @@
+---
+title: FAQ
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+
+
+### ツールキットやリンターはありますか？ \{#is-there-a-toolkit-or-a-linter}
+
+はい！CLI または IDE を通じてプロジェクトのアーキテクチャと [フォルダー ジェネレーター][ext-tools] をチェックするための [Steiger][ext-steiger] というリンターがあります。
+
+### ページのレイアウト/テンプレートはどこに保存すればよいですか？ \{#where-to-store-the-layouttemplate-of-pages}
+
+シンプルなレイアウトテンプレートが必要な場合は、`shared/ui`に保存できます。より上層のレイヤーを使用する必要がある場合、いくつかのオプションがあります。
+
+- レイアウトが本当に必要ですか？レイアウトが数行で構成されている場合、各ページにコードを重複させる方が合理的です。
+- レイアウトが必要な場合は、個別のウィジェットやページとして保存し、App層のルーター設定にそれらを組み合わせることができます。ネストされたルーティングも一つのオプションです。
+
+### フィーチャーとエンティティの違いは何ですか？ \{#what-is-the-difference-between-feature-and-entity}
+
+エンティティはアプリケーションが扱う現実世界の概念です。フィーチャーはユーザーに実際の価値を提供するインタラクションであり、ユーザーがエンティティで行いたいことです。
+
+詳細および例については、参考書セクションの[スライスについてのページ][reference-entities]を参照してください。
+
+### ページ/フィーチャー/エンティティを相互に埋め込むことはできますか？ \{#can-i-embed-pagesfeaturesentities-into-each-other}
+
+はい、しかし、この埋め込みはより上層のレイヤーで行う必要があります。例えば、ウィジェット内で両方のフィーチャーをインポートし、プロップス/子要素として一方のフィーチャーを他方に挿入することができます。
+
+一方のフィーチャーを他方のフィーチャーからインポートすることはできません。これは[**レイヤーのインポートルール**][import-rule-layers]で禁止されています。
+
+### Atomic Designはどうですか？ \{#what-about-atomic-design}
+
+現在、アトミックデザインをFeature-Sliced Designと一緒に使用することを義務付けていませんが、禁止もしていません。
+
+アトミックデザインは、モジュールの`ui`セグメントにうまく適用できます。
+
+### FSDに関する有用なリソース/記事などはありますか？ \{#are-there-any-useful-resourcesarticlesetc-about-fsd}
+
+はい！ https://github.com/feature-sliced/awesome
+
+### なぜFeature-Sliced Designが必要なのですか？ \{#why-do-i-need-feature-sliced-design}
+
+FSDは、プロジェクトの主要な価値を提供するコンポーネントの観点から、あなたとあなたのチームが迅速にプロジェクトを把握するのに役立ちます。標準化されたアーキテクチャは、オンボーディングを迅速化し、コード構造に関する議論を解決するのに役立ちます。FSDが作成された理由については、[モチベーション][motivation]のページを参照してください。
+
+### 初心者の開発者にFSDのアーキテクチャ/設計方法論は必要ですか？ \{#does-a-novice-developer-need-an-architecturemethodology}
+
+おそらく必要です。
+
+*通常、一人でプロジェクトを設計・開発する場合、すべてが順調に進みます。しかし、開発に中断が生じたり、新しい開発者がチームに加わると問題が発生します。*
+
+### 認証コンテキストをどのように扱えばよいですか？ \{#how-do-i-work-with-the-authorization-context}
+
+[こちら](/docs/guides/examples/auth)で回答しています。
+
+[ext-steiger]: https://github.com/feature-sliced/steiger
+[ext-tools]: https://github.com/feature-sliced/awesome?tab=readme-ov-file#tools
+[import-rule-layers]: /docs/reference/layers#import-rule-on-layers
+[reference-entities]: /docs/reference/layers#entities
+[motivation]: /docs/about/motivation
+[telegram]: https://t.me/feature_sliced
+[discord]: https://discord.gg/S8MzWTUsmp
+[github-discussions]: https://github.com/feature-sliced/documentation/discussions
diff --git a/src/content/docs/ja/docs/get-started/overview.mdx b/src/content/docs/ja/docs/get-started/overview.mdx
new file mode 100644
index 0000000000..8032d6eaef
--- /dev/null
+++ b/src/content/docs/ja/docs/get-started/overview.mdx
@@ -0,0 +1,142 @@
+---
+title: 概要
+sidebar:
+ order: 1
+---
+
+import { FileTree } from '@astrojs/starlight/components';
+
+**Feature-Sliced Design** (FSD) とは、フロントエンドアプリケーションの設計方法論です。簡単に言えば、コードを整理するためのルールと規約の集大成です。FSDの主な目的は、ビジネス要件が絶えず変化する中で、プロジェクトをより理解しやすく、構造化されたものにすることです。
+
+ルールのセットに加えて、FSDはツールチェーンでもあります。プロジェクトのアーキテクチャをチェックするための[リンター][ext-steiger]、CLIやIDEを通じた[フォルダージェネレーター][ext-tools]、および豊富な[実装例のコレクション][examples]があります。
+
+## FSDは私のプロジェクトに適しているのか？ \{#is-it-right-for-me}
+
+FSDは、あらゆる規模のプロジェクトやチームに導入できます。以下の場合、あなたのプロジェクトに適しています。
+
+- **フロントエンド**開発での使用（ウェブサイト、モバイル/デスクトップアプリケーションのインターフェース作成など）
+- **アプリケーション**開発での使用（ライブラリ開発ではない）
+
+これだけです！使用するプログラミング言語、フレームワーク、状態管理ライブラリには制限がありません。尚、FSDを段階的に導入したり、モノレポで使用したり、アプリケーションをパッケージに分割し、それぞれにFSDを個別に導入することもできます！
+
+既存のアーキテクチャからFSDに移行することを検討している場合は、現在のアーキテクチャがチームに**支障をきたしている**かどうかを確認してください。例えば、プロジェクトが大きくなりすぎて新機能の開発が効率的に行えない場合や、多くの新しいメンバーがチームに加わることが予想される場合です。現在のアーキテクチャが正常に機能している場合、変更する必要はないかもしれません。しかし、移行を決定した場合は、[移行セクション][migration]の推奨事項を確認してください。
+
+## 基本的な例 \{#basic-example}
+
+以下は、FSDを実装したシンプルなプロジェクトです。
+
+上の図には、左から右に「レイヤー」、「スライス」、「セグメント」とラベル付けされた3つの列があります。
+「レイヤー」列には、上から下に「app」、「processes」、「pages」、「widgets」、「features」、「entities」、「shared」とラベル付けされた7つの区分があります。「processes」区分は取り消し線が引かれています。「entities」区分は2番目の列「スライス」と接続されていて、2番目の列が「entities」の内容であることを示しています。
+「スライス」列には、上から下に「user」、「post」、「comment」とラベル付けされた3つの区分があります。「post」区分は「セグメント」列と同様に接続されていて、「post」の内容であることを示しています。
+「セグメント」列には、上から下に「ui」、「model」、「api」とラベル付けされた3つの区分があります。
+
+
+ );
+}
+```
+
+次に、このコンポーネントをフィードページの公開APIに再エクスポートします。
+
+```tsx title="pages/feed/index.ts"
+export { FeedPage } from "./ui/FeedPage";
+```
+
+次に、ルートに接続します。Remixでは、ルーティングはファイルに基づいていて、ルートファイルは`app/routes`フォルダーにあります。これはFeature-Sliced Designとよく組み合っています。
+
+`app/routes/_index.tsx`で`FeedPage`コンポーネントを使用します。
+
+```tsx title="app/routes/_index.tsx"
+import type { MetaFunction } from "@remix-run/node";
+import { FeedPage } from "pages/feed";
+
+export const meta: MetaFunction = () => {
+ return [{ title: "Conduit" }];
+};
+
+export default FeedPage;
+```
+
+これで、devサーバーを起動し、アプリケーションを開くと、Conduitのバナーが表示されるはずです！
+
+
+
+### APIクライアント
+
+RealWorldのバックエンドと通信するために、Shared層内に便利なAPIクライアントを作成しましょう。クライアント用の`api`セグメントと、バックエンドの基本URLなどの変数用の`config`セグメントを作成します。
+
+```bash
+npx fsd shared --segments api config
+```
+
+次に、`shared/config/backend.ts`を作成します。
+
+```tsx title="shared/config/backend.ts"
+export { mockBackendUrl as backendBaseUrl } from "mocks/handlers";
+```
+
+```tsx title="shared/config/index.ts"
+export { backendBaseUrl } from "./backend";
+```
+
+RealWorldプロジェクトは[OpenAPI仕様](https://github.com/gothinkster/realworld/blob/main/api/openapi.yml)を提供しているため、APIクライアントの型を自動的に生成できます。私たちは[`openapi-fetch`パッケージ](https://openapi-ts.pages.dev/openapi-fetch/)を使用します。このパッケージにはTypeScriptの型を自動生成するツールも含まれています。
+
+次のコマンドを実行して、APIの最新の型を生成しましょう。
+
+```bash
+npm run generate-api-types
+```
+
+その結果、`shared/api/v1.d.ts`ファイルが作成されます。このファイルを使用して、`shared/api/client.ts`で型付きAPIクライアントを作成します。
+
+```tsx title="shared/api/client.ts"
+import createClient from "openapi-fetch";
+
+import { backendBaseUrl } from "shared/config";
+import type { paths } from "./v1";
+
+export const { GET, POST, PUT, DELETE } = createClient
+
+
+
+ conduit
+知識を共有する場
+
+
+ );
+}
+```
+
+「いいね」ボタンはまだ機能していません。それは記事の読み取りページに移動して、「いいね」機能を実装するときに修正します。
+
+これで、記事を取得して、たくさんのプレビューカードを表示できます。Remixでは、データの取得は*ローダー*を使用して行われます。ローダーは、ページに必要なデータを収集するサーバー関数です。ローダーはページの代わりにAPIとやり取りをするため、`api`セグメントに配置します。
+
+```tsx title="pages/feed/api/loader.ts"
+import { json } from "@remix-run/node";
+
+import { GET } from "shared/api";
+
+export const loader = async () => {
+ const { data: articles, error, response } = await GET("/articles");
+
+ if (error !== undefined) {
+ throw json(error, { status: response.status });
+ }
+
+ return json({ articles });
+};
+```
+
+これをページに接続するには、ルートファイルから`loader`としてエクスポートする必要があります。
+
+```tsx title="pages/feed/index.ts"
+export { FeedPage } from "./ui/FeedPage";
+export { loader } from "./api/loader";
+```
+
+```tsx title="app/routes/_index.tsx"
+import type { MetaFunction } from "@remix-run/node";
+import { FeedPage } from "pages/feed";
+
+export { loader } from "pages/feed";
+
+export const meta: MetaFunction = () => {
+ return [{ title: "Conduit" }];
+};
+
+export default FeedPage;
+```
+
+最後のステップは、これらのカードをフィードに表示することです。`FeedPage`を次のコードで更新します。
+
+```tsx title="pages/feed/ui/FeedPage.tsx"
+import { useLoaderData } from "@remix-run/react";
+
+import type { loader } from "../api/loader";
+import { ArticlePreview } from "./ArticlePreview";
+
+export function FeedPage() {
+ const { articles } = useLoaderData
+
+
+
+
+
+
+
+ {article.author.username}
+
+
+ {new Date(article.createdAt).toLocaleDateString(undefined, {
+ dateStyle: "long",
+ })}
+
+
+
+ {article.title}
+{article.description}
+ 続きを読む... +-
+ {article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+
+ );
+}
+```
+
+### タグによるフィルタリング
+
+タグに関しては、バックエンドから取得し、ユーザーが選択したタグを記憶する必要があります。私たちはバックエンドからの取得方法はすでに知っています。これはローダー関数からの別のリクエストです。すでにインストールされている`remix-utils`パッケージの便利な`promiseHash`関数を使用します。
+
+`pages/feed/api/loader.ts`のローダーを次のコードで更新します。
+
+```tsx title="pages/feed/api/loader.ts"
+import { json } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+知識を共有する場
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+ );
+}
+```
+
+次に、タグの検索パラメータをローダーで使用する必要があります。`pages/feed/api/loader.ts`の`loader`関数を次のように変更します。
+
+```tsx title="pages/feed/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+知識を共有する場
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+
+
+
+ 人気のタグ
+ + +
+
+ );
+}
+```
+
+よし、これも実現しました。タグ一覧も同様に実装できますが、認証を実装するまで待ちましょう。ところで、認証についてですが！
+
+### 認証
+
+認証には、ログイン用のページと登録用のページの2つがあります。これらは主に非常に似ているため、必要に応じてコードを再利用できるように、1つの`sign-in`セグメントに保持するのが理にかなっています。
+
+`pages/sign-in`の`ui`セグメントに`RegisterPage.tsx`を作成し、次の内容を配置します。
+
+```tsx title="pages/sign-in/ui/RegisterPage.tsx"
+import { Form, Link, useActionData } from "@remix-run/react";
+
+import type { register } from "../api/register";
+
+export function RegisterPage() {
+ const registerData = useActionData
+
+
+
+
+ conduit
+知識を共有する場
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+
+
+
+ 人気のタグ
+ + +
+
+ );
+}
+```
+
+これからは壊れたインポートを修正する必要があります。インポートが新しいセグメントにアクセスしているため、次のコマンドでそのセグメントを作成しましょう。
+
+```bash
+npx fsd pages sign-in -s api
+```
+
+ただし、登録のバックエンド部分を実装する前に、Remixのセッション処理のためのインフラコードが必要です。これは他のページでも必要になる可能性があるため、Shared層に配置します。
+
+次のコードを`shared/api/auth.server.ts`に配置しましょう。このコードはRemixに特有のものであり、すべてが理解できなくても心配しないでください。単にコピーして貼り付けてください。
+
+```tsx title="shared/api/auth.server.ts"
+import { createCookieSessionStorage, redirect } from "@remix-run/node";
+import invariant from "tiny-invariant";
+
+import type { User } from "./models";
+
+invariant(
+ process.env.SESSION_SECRET,
+ "SESSION_SECRET must be set for authentication to work",
+);
+
+const sessionStorage = createCookieSessionStorage<{
+ user: User;
+}>({
+ cookie: {
+ name: "__session",
+ httpOnly: true,
+ path: "/",
+ sameSite: "lax",
+ secrets: [process.env.SESSION_SECRET],
+ secure: process.env.NODE_ENV === "production",
+ },
+});
+
+export async function createUserSession({
+ request,
+ user,
+ redirectTo,
+}: {
+ request: Request;
+ user: User;
+ redirectTo: string;
+}) {
+ const cookie = request.headers.get("Cookie");
+ const session = await sessionStorage.getSession(cookie);
+
+ session.set("user", user);
+
+ return redirect(redirectTo, {
+ headers: {
+ "Set-Cookie": await sessionStorage.commitSession(session, {
+ maxAge: 60 * 60 * 24 * 7, // 7日間
+ }),
+ },
+ });
+}
+
+export async function getUserFromSession(request: Request) {
+ const cookie = request.headers.get("Cookie");
+ const session = await sessionStorage.getSession(cookie);
+
+ return session.get("user") ?? null;
+}
+
+export async function requireUser(request: Request) {
+ const user = await getUserFromSession(request);
+
+ if (user === null) {
+ throw redirect("/login");
+ }
+
+ return user;
+}
+```
+
+また、`models.ts`ファイルから`User`モデルをエクスポートしてください。
+
+```tsx title="shared/api/models.ts"
+import type { components } from "./v1";
+
+export type Article = components["schemas"]["Article"];
+export type User = components["schemas"]["User"];
+```
+
+このコードが動作する前に、`SESSION_SECRET`環境変数を設定する必要があります。プロジェクトのルートに`.env`ファイルを作成し、`SESSION_SECRET=`を記述してから、適当にランダムな文字列を記入します。次のようになります。
+
+```bash title=".env"
+SESSION_SECRET=これをコピーしないでください
+```
+
+最後に、公開APIにいくつかのエクスポートを追加します。
+
+```tsx title="shared/api/index.ts"
+export { GET, POST, PUT, DELETE } from "./client";
+
+export type { Article } from "./models";
+
+export { createUserSession, getUserFromSession, requireUser } from "./auth.server";
+```
+
+これで、RealWorldのバックエンドと通信するコードを書くことができます。これを`pages/sign-in/api`に保存します。`register.ts`ファイルを作成して、中に次のコードを配置しましょう。
+
+```tsx title="pages/sign-in/api/register.ts"
+import { json, type ActionFunctionArgs } from "@remix-run/node";
+
+import { POST, createUserSession } from "shared/api";
+
+export const register = async ({ request }: ActionFunctionArgs) => {
+ const formData = await request.formData();
+ const username = formData.get("username")?.toString() ?? "";
+ const email = formData.get("email")?.toString() ?? "";
+ const password = formData.get("password")?.toString() ?? "";
+
+ const { data, error } = await POST("/users", {
+ body: { user: { email, password, username } },
+ });
+
+ if (error) {
+ return json({ error }, { status: 400 });
+ } else {
+ return createUserSession({
+ request: request,
+ user: data.user,
+ redirectTo: "/",
+ });
+ }
+};
+```
+
+```tsx title="pages/sign-in/index.ts"
+export { RegisterPage } from './ui/RegisterPage';
+export { register } from './api/register';
+```
+
+ほぼ完成です！残りの部分は、`/register`ルートにアクションとページを接続することだけです。`app/routes`で`register.tsx`を作成します。
+
+```tsx title="app/routes/register.tsx"
+import { RegisterPage, register } from "pages/sign-in";
+
+export { register as action };
+
+export default RegisterPage;
+```
+
+これで、[http://localhost:3000/register](http://localhost:3000/register)にアクセスすると、ユーザーを作成できます！アプリケーションの残りの部分は、まだ反応しませんが、近々対処します。
+
+同様に、ログインページを実装することもできます。自分で実装してみるか、下記のコードをコピペするか、次に進みましょう。
+
+```tsx title="pages/sign-in/api/sign-in.ts"
+import { json, type ActionFunctionArgs } from "@remix-run/node";
+
+import { POST, createUserSession } from "shared/api";
+
+export const signIn = async ({ request }: ActionFunctionArgs) => {
+ const formData = await request.formData();
+ const email = formData.get("email")?.toString() ?? "";
+ const password = formData.get("password")?.toString() ?? "";
+
+ const { data, error } = await POST("/users/login", {
+ body: { user: { email, password } },
+ });
+
+ if (error) {
+ return json({ error }, { status: 400 });
+ } else {
+ return createUserSession({
+ request: request,
+ user: data.user,
+ redirectTo: "/",
+ });
+ }
+};
+```
+
+```tsx title="pages/sign-in/ui/SignInPage.tsx"
+import { Form, Link, useActionData } from "@remix-run/react";
+
+import type { signIn } from "../api/sign-in";
+
+export function SignInPage() {
+ const signInData = useActionData
+
+
+
+
+
+ 登録
++ アカウントをお持ちですか？ +
+ + {registerData?.error && ( +-
+ {registerData.error.errors.body.map((error) => (
+
- {error} + ))} +
+
+ );
+}
+```
+
+```tsx title="pages/sign-in/index.ts"
+export { RegisterPage } from './ui/RegisterPage';
+export { register } from './api/register';
+export { SignInPage } from './ui/SignInPage';
+export { signIn } from './api/sign-in';
+```
+
+```tsx title="app/routes/login.tsx"
+import { SignInPage, signIn } from "pages/sign-in";
+
+export { signIn as action };
+
+export default SignInPage;
+```
+
+これで、ユーザーがこれらのページにアクセスできるようになりました。
+
+### ヘッダー
+
+前章で説明されたように、アプリケーションのヘッダーは通常Widgets層、またはShared層に配置されます。ヘッダーは非常にシンプルで、すべてのビジネスロジックを外部に保持できるので、Shared層に配置しましょう。ヘッダー用のフォルダーを作成します。
+
+```bash
+npx fsd shared ui
+```
+
+次に、`shared/ui/Header.tsx`を作成し、次の内容を配置します。
+
+```tsx title="shared/ui/Header.tsx"
+import { useContext } from "react";
+import { Link, useLocation } from "@remix-run/react";
+
+import { CurrentUser } from "../api/currentUser";
+
+export function Header() {
+ const currentUser = useContext(CurrentUser);
+ const { pathname } = useLocation();
+
+ return (
+
+ );
+}
+```
+
+このコンポーネントを`shared/ui`からエクスポートします。
+
+```tsx title="shared/ui/index.ts"
+export { Header } from "./Header";
+```
+
+ヘッダーで`shared/api`にあるコンテキストを使っているので、それを作成しましょう。
+
+```tsx title="shared/api/currentUser.ts"
+import { createContext } from "react";
+
+import type { User } from "./models";
+
+export const CurrentUser = createContext
+
+
+
+
+
+ サインイン
++ アカウントが必要ですか？ +
+ + {signInData?.error && ( +-
+ {signInData.error.errors.body.map((error) => (
+
- {error} + ))} +
+
+ );
+}
+```
+
+```tsx title="pages/feed/ui/Pagination.tsx"
+import { Form, useLoaderData, useSearchParams } from "@remix-run/react";
+import { ExistingSearchParams } from "remix-utils/existing-search-params";
+
+import { LIMIT, type loader } from "../api/loader";
+
+export function Pagination() {
+ const [searchParams] = useSearchParams();
+ const { articles } = useLoaderData人気のタグ
+ + +
+
+ );
+}
+```
+
+ローダー関数にも新しいタブを考慮する必要があります。
+
+```tsx title="pages/feed/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET, requireUser } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+知識を共有する場
+
+
+
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+このコードは、`/article/:slug`にPOSTリクエストを送信し、`_action=favorite`を使用して記事をお気に入りにします。今は機能していませんが、記事リーダーの作成を始めると、これも実装します。
+
+これで、フィードの作成が完了しました！やったね！
+
+### 記事リーダー
+
+まず、データが必要です。ローダーを作成しましょう。
+
+```bash
+npx fsd pages article-read -s api
+```
+
+```tsx title="pages/article-read/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import invariant from "tiny-invariant";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET, getUserFromSession } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+
+
+
+ {article.author.username}
+
+
+ {new Date(article.createdAt).toLocaleDateString(undefined, {
+ dateStyle: "long",
+ })}
+
+
+
+ {article.title}
+{article.description}
+ もっと読む... +-
+ {article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+
+ );
+}
+```
+
+興味深いのは`ArticleMeta`と`Comments`です。これらは、記事を「いいね」したり、コメントを残したりするための操作を含んでいます。これらが機能するためには、まずバックエンド部分を実装する必要があります。このページの`api`セグメントに`action.ts`ファイルを作成します。
+
+```tsx title="pages/article-read/api/action.ts"
+import { redirect, type ActionFunctionArgs } from "@remix-run/node";
+import { namedAction } from "remix-utils/named-action";
+import { redirectBack } from "remix-utils/redirect-back";
+import invariant from "tiny-invariant";
+
+import { DELETE, POST, requireUser } from "shared/api";
+
+export const action = async ({ request, params }: ActionFunctionArgs) => {
+ const currentUser = await requireUser(request);
+
+ const authorization = { Authorization: `Token ${currentUser.token}` };
+
+ const formData = await request.formData();
+
+ return namedAction(formData, {
+ async delete() {
+ invariant(params.slug, "スラッグパラメータが必要です");
+ await DELETE("/articles/{slug}", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirect("/");
+ },
+ async favorite() {
+ invariant(params.slug, "スラッグパラメータが必要です");
+ await POST("/articles/{slug}/favorite", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async unfavorite() {
+ invariant(params.slug, "スラッグパラメータが必要です");
+ await DELETE("/articles/{slug}/favorite", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async createComment() {
+ invariant(params.slug, "スラッグパラメータが必要です");
+ const comment = formData.get("comment");
+ invariant(typeof comment === "string", "コメントパラメータが必要です");
+ await POST("/articles/{slug}/comments", {
+ params: { path: { slug: params.slug } },
+ headers: { ...authorization, "Content-Type": "application/json" },
+ body: { comment: { body: comment } },
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async deleteComment() {
+ invariant(params.slug, "スラッグパラメータが必要です");
+ const commentId = formData.get("id");
+ invariant(typeof commentId === "string", "idパラメータが必要です");
+ const commentIdNumeric = parseInt(commentId, 10);
+ invariant(
+ !Number.isNaN(commentIdNumeric),
+ "数値のidパラメータが必要です",
+ );
+ await DELETE("/articles/{slug}/comments/{id}", {
+ params: { path: { slug: params.slug, id: commentIdNumeric } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async followAuthor() {
+ const authorUsername = formData.get("username");
+ invariant(
+ typeof authorUsername === "string",
+ "ユーザーネームパラメータが必要です",
+ );
+ await POST("/profiles/{username}/follow", {
+ params: { path: { username: authorUsername } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async unfollowAuthor() {
+ const authorUsername = formData.get("username");
+ invariant(
+ typeof authorUsername === "string",
+ "ユーザーネームパラメータが必要です",
+ );
+ await DELETE("/profiles/{username}/follow", {
+ params: { path: { username: authorUsername } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ });
+};
+```
+
+これをスライスから再エクスポートし、ルートから再エクスポートします。ここにいる間に、ページ自体も接続しましょう。
+
+```tsx title="pages/article-read/index.ts"
+export { ArticleReadPage } from "./ui/ArticleReadPage";
+export { loader } from "./api/loader";
+export { action } from "./api/action";
+```
+
+```tsx title="app/routes/article.$slug.tsx"
+import { ArticleReadPage } from "pages/article-read";
+
+export { loader, action } from "pages/article-read";
+
+export default ArticleReadPage;
+```
+
+これで、記事リーダーの「いいね」ボタンはまだ実装されていないにも関わらず、フィードの「いいね」ボタンは機能し始めます！それは、フィードの「いいね」ボタンもそのルートにリクエストを送っているからです。何かを「いいね」してみてください！
+
+`ArticleMeta`と`Comments`は、単なるフォームです。以前にこれを行ったので、コードをコピペして先に進みましょう。
+
+```tsx title="pages/article-read/ui/ArticleMeta.tsx"
+import { Form, Link, useLoaderData } from "@remix-run/react";
+import { useContext } from "react";
+
+import { CurrentUser } from "shared/api";
+import type { loader } from "../api/loader";
+
+export function ArticleMeta() {
+ const currentUser = useContext(CurrentUser);
+ const { article } = useLoaderData
+
+
+
+
+ {article.article.title}
+ +
+
+ +
+
+
+
+
+
+ {article.article.body}
+-
+ {article.article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+ +
+
+
+
+
+
+ {currentUser !== null ? (
+
+ ) : (
+
+ );
+}
+```
+
+これで、記事リーダーが完成しました！「著者をフォローする」ボタン、「いいね」ボタン、「コメントを残す」ボタンがすべて正常に機能するはずです。
+
+
+
+ )}
+
+ {comments.comments.map((comment) => (
+
+
+ + サインイン + または + 登録 + して記事にコメントを追加しましょう！ +
+
+
+ ))}
+
+
+
+ {comment.body}
+
+
+
+
+
+
+ {comment.author.username}
+
+ {comment.createdAt}
+ {comment.author.username === currentUser?.username && (
+
+
+
+ )}
+
+
+
+ );
+}
+```
+
+このページは、存在する記事を取得し（新しい記事を作成する場合を除く）、対応するフォームフィールドを埋めます。これは以前に見たものです。着目すべき部分は`FormErrors`で、これは検証結果を取得し、ユーザーに表示します。
+
+```tsx title="pages/article-edit/ui/FormErrors.tsx"
+import { useActionData } from "@remix-run/react";
+import type { action } from "../api/action";
+
+export function FormErrors() {
+ const actionData = useActionData
+
+
+
+
+
+ -
+ {actionData.errors.map((error) => (
+
- {error} + ))} +
+ {tagListState.map((tag) => (
+
+
+ [" ", "Enter"].includes(e.key) && removeTag(tag)
+ }
+ onClick={() => removeTag(tag)}
+ >{" "}
+ {tag}
+
+ ))}
+
+
+ );
+}
+```
+
+次に、API部分に移ります。ローダーはURLを確認し、記事へのリンクがある場合、既存の記事を編集していることを意味し、そのデータをロードする必要があります。そうでない場合は、何も返しません。このローダーを作成しましょう。
+
+```tsx title="pages/article-edit/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+
+import { GET, requireUser } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+```ts title="shared/ui/layout/useThemeSwitcher.ts"
+export function useThemeSwitcher() {
+ const [theme, setTheme] = useState("light");
+
+ function toggleTheme() {
+ setTheme(theme === "light" ? "dark" : "light");
+ }
+
+ useEffect(() => {
+ document.body.classList.remove("light", "dark");
+ document.body.classList.add(theme);
+ }, [theme]);
+
+ return [theme, toggleTheme] as const;
+}
+```
+
+
+サイドバーのコードは読者に課題として残されています！
+
+## レイアウトでのウィジェットの使用
+
+時には、特定のビジネスロジックをレイアウトに組み込む必要があります。特に、[React Router][ext-react-router]のような深くネストされたルートを使用している場合、Shared層やWidgets層にレイアウトを保存することはできません。これは[レイヤーのインポートルール][import-rule-on-layers]に違反しています。
+
+> スライス内のモジュールは、下層にあるスライスのみをインポートできる。
+
+解決策を議論する前に、これが実際に問題かどうかを確認する必要があります。このレイアウトは本当に必要なのか？もしそうなら、ウィジェットとして実装することが最適なのかも再考する必要があるでしょう。もしビジネスロジックのブロックが2〜3ページで使用され、レイアウトがそのウィジェットの小さなラッパーに過ぎない場合、次の2つのオプションを検討してください。
+
+1. **レイアウトをApp層のルーターで直接作成する**
+ これは、ネストをサポートするルーターに最適です。特定のルートをグループ化し、必要なレイアウトをそれらにのみ適用できます。
+
+2. **単にコピーする**
+ コードを抽象化する欲求はしばしば過大評価されます。特にレイアウトに関しては、変更がほとんどないためです。ある時点で、これらのページの1つが変更を必要とする場合、他のページに影響を与えずに変更を加えることができます。他のページを更新することを忘れるかもしれないと心配している場合は、ページ間の関係を説明するコメントを残すことができます。
+
+上記のいずれのオプションも適用できない場合、ウィジェットをレイアウトに組み込むための2つの解決策があります。
+
+1. **レンダープロップまたはスロットを使用する**
+ ほとんどのフレームワークは、UIの一部を外部から渡すことを許可しています。Reactではこれを[レンダープロップ][ext-render-props]と呼び、Vueでは[スロット][ext-vue-slots]と呼びます。
+
+2. **レイアウトをApp層に移動する**
+ レイアウトをApp層に保存し、必要なウィジェットを組み合わせることもできます。
+
+## 追加資料
+
+- ReactとRemixを使用した認証付きレイアウトの作成例は[チュートリアル][tutorial]で見つけることができます（React Routerに類似する）。
+
+[tutorial]: /docs/get-started/tutorial
+[import-rule-on-layers]: /docs/reference/layers#import-rule-on-layers
+[ext-react-router]: https://reactrouter.com/
+[ext-render-props]: https://www.patterns.dev/react/render-props-pattern/
+[ext-vue-slots]: https://jp.vuejs.org/guide/components/slots
diff --git a/src/content/docs/ja/docs/guides/examples/types.mdx b/src/content/docs/ja/docs/guides/examples/types.mdx
new file mode 100644
index 0000000000..cc059e99c4
--- /dev/null
+++ b/src/content/docs/ja/docs/guides/examples/types.mdx
@@ -0,0 +1,448 @@
+---
+title: 型
+sidebar:
+ order: 2
+---
+
+import { Aside, FileTree } from '@astrojs/starlight/components';
+
+
+
+このガイドでは、TypeScriptのような型付き言語のデータの型と、それがFSDにどのように適合するかについて説明します。
+
+
+
+## ユーティリティ型
+
+ユーティリティ型は、特に意味を持たず、通常は他の型と一緒に使用される型です。例えば
+
+Loading...
;
+ }
+
+ if (isError || !post) {
+ return <>{error?.message};
+ }
+
+ return (
+
+
+ );
+};
+```
+
+### クエリファクトリーを使用する利点
+- **クエリの構造化:** ファクトリーはすべてのAPIクエリを1か所に整理し、コードをより読みやすく、保守しやすくしている
+- **クエリとキーへの便利なアクセス:** ファクトリーはさまざまなタイプのクエリとそのキーへの便利なメソッドを提供している
+- **クエリの再フェッチ機能:** ファクトリーは、アプリケーションのさまざまな部分でクエリキーを変更することなく、簡単に再フェッチを行うことを可能にしている
+
+## ページネーション
+
+このセクションでは、ページネーションを使用して投稿エンティティを取得するためのAPIクエリを行う`getPosts`関数の例を挙げます。
+
+### 1. `getPosts`関数の作成
+
+`getPosts`関数は、APIセグメント内の`get-posts.ts`ファイルにあります。
+
+```tsx title="@/pages/post-feed/api/get-posts.ts"
+import { apiClient } from "@/shared/api/base";
+
+import { PostWithPaginationDto } from "./dto/post-with-pagination.dto";
+import { PostQuery } from "./query/post.query";
+import { mapPost } from "./mapper/map-post";
+import { PostWithPagination } from "../model/post-with-pagination";
+
+const calculatePostPage = (totalCount: number, limit: number) =>
+ Math.floor(totalCount / limit);
+
+export const getPosts = async (
+ page: number,
+ limit: number,
+): PromisePost id: {post.id}
+
+
+ {post.title}
+
+
+ {post.body}
+Owner: {post.userId}
+ 
+
+
+
+1. App (アップ)
+2. Processes (プロセス、非推奨)
+3. Pages (ページ)
+4. Widgets (ウィジェット)
+5. Features (フィーチャー)
+6. Entities (エンティティ)
+7. Shared (シェアード)
+
+プロジェクトにすべてのレイヤーを使用する必要はありません。プロジェクトに価値をもたらすと思う場合のみ追加してください。通常、ほとんどのフロントエンドプロジェクトには、少なくともShared、Page、Appのレイヤーがあります。
+
+実際には、レイヤーは小文字の名前のフォルダーです（例えば、`📁 shared`、`📁 pages`、`📁 app`）。新しいレイヤーを追加することは推奨されていません。なぜなら、その意味は標準化されているからです。
+
+## レイヤーに関するインポートルール
+
+レイヤーは _スライス_ で構成されており、これは非常に凝集性の高いモジュールのグループです。スライス間の依存関係は、**レイヤーに関するインポートルール**によって規制されています。
+
+> _スライス内のモジュール（ファイル）は、下位のレイヤーにある他のスライスのみをインポートできます。_
+
+例えば、フォルダー `📁 ~/features/aaa` は「aaa」という名前のスライスです。その中のファイル `~/features/aaa/api/request.ts` は、`📁 ~/features/bbb` 内のファイルからコードをインポートすることはできませんが、`📁 ~/entities` や `📁 ~/shared` からコードをインポートすることができ、例えば `~/features/aaa/lib/cache.ts` などの同じスライス内の隣接コードもインポートできます。
+
+AppとSharedのレイヤーは、このルールの**例外**です。これらは同時にレイヤーとスライスの両方です。スライスはビジネスドメインによってコードを分割しますが、これらの2つのレイヤーは例外です。なぜなら、Sharedはビジネスドメインを持たず、Appはすべてのビジネスドメインを統合しているからです。
+
+実際には、AppとSharedのレイヤーはセグメントで構成されており、セグメントは自由に互いにインポートできます。
+
+## レイヤーの定義
+
+このセクションでは、各レイヤーの意味を説明し、どのようなコードがそこに属するかの直感を得るためのものです。
+
+### Shared
+
+このレイヤーは、アプリの残りの部分の基盤を形成します。外部世界との接続を作成する場所であり、例えばバックエンド、サードパーティライブラリ、環境などです。また、特定のタスクに集中した自分自身のライブラリを作成する場所でもあります。
+
+このレイヤーは、Appレイヤーと同様に、_スライスを含みません_。スライスはビジネスドメインによってレイヤーを分割することを目的としていますが、Sharedにはビジネスドメインが存在しないため、Shared内のすべてのファイルは互いに参照し、インポートすることができます。
+
+このレイヤーで通常見られるセグメントは次のとおりです。
+
+- `📁 api` — APIクライアントおよび特定のバックエンドエンドポイントへのリクエストを行う関数
+- `📁 ui` — アプリケーションのUIキット
+ このレイヤーのコンポーネントはビジネスロジックを含むべきではありませんが、ビジネスに関連することは許可されています。例えば、会社のロゴやページレイアウトをここに置くことができます。UIロジックを持つコンポーネントも許可されています（例えば、オートコンプリートや検索バー）
+- `📁 lib` — 内部ライブラリのコレクション
+ このフォルダーはヘルパーやユーティリティとして扱うべきではありません（[なぜこれらのフォルダーがしばしばダンプに変わるか][ext-sova-utility-dump]）。このフォルダー内の各ライブラリは、日付、色、テキスト操作など、1つの焦点を持つべきです。その焦点はREADMEファイルに文書化されるべきです。チームの開発者は、これらのライブラリに何を追加でき、何を追加できないかを知っているべきです
+- `📁 config` — 環境変数、グローバルフィーチャーフラグ、アプリの他のグローバル設定
+- `📁 routes` — ルート定数、またはルートをマッチさせるためのパターン
+- `📁 i18n` — 翻訳のセットアップコード、グローバル翻訳文字列
+
+さらにセグメントを追加することは自由ですが、これらのセグメントの名前は内容の目的を説明するものでなければなりません。例えば、`components`、`hooks`、`types` は、コードを探しているときにあまり役立たないため、悪いセグメント名です。
+
+### Entities
+
+このレイヤーのスライスは、プロジェクトが扱う現実世界の概念を表します。一般的には、ビジネスがプロダクトを説明するために使用する用語です。例えば、SNSは、ユーザー、投稿、グループなどのビジネスエンティティを扱うかもしれません。
+
+エンティティスライスには、データストレージ（`📁 model`）、データ検証スキーマ（`📁 model`）、エンティティ関連のAPIリクエスト関数（`📁 api`）、およびインターフェース内のこのエンティティの視覚的表現（`📁 ui`）が含まれる場合があります。視覚的表現は、完全なUIブロックを生成する必要はなく、アプリ内の複数のページで同じ外観を再利用することを主に目的としています。異なるビジネスロジックは、プロップスやスロットを通じてそれに付加されることがあります。
+
+#### エンティティの関係
+
+FSDにおけるエンティティはスライスであり、デフォルトではスライスは互いに知ることができません。しかし、現実の世界では、エンティティはしばしば互いに相互作用し、一方のエンティティが他のエンティティを所有、または含むことがあります。そのため、これらの相互作用のビジネスロジックは、フィーチャーやページのような上位のレイヤーに保持されるのが望ましいです。
+
+一つのエンティティのデータオブジェクトが他のデータオブジェクトを含む場合、通常はエンティティ間の接続を明示的にし、`@x`表記を使用してスライスの隔離を回避するのが良いアイデアです。理由は、接続されたエンティティは一緒にリファクタリングする必要があるため、その接続を見逃すことができないようにするのが最善です。
+
+例：
+
+```ts title="entities/artist/model/artist.ts"
+import type { Song } from "entities/song/@x/artist";
+
+export interface Artist {
+ name: string;
+ songs: Array
+ 
+ 
+ 
+
+ 위 다이어그램은 FSD의 계층 구조를 시각적으로 보여줍니다.
+ 세 개의 수직 블록 그룹은 각각 Layer, Slice, Segment를 나타냅니다.
+
+ 왼쪽의 Layer 블록에는 app, processespages, widgets,
+ features, entities, shared가 포함됩니다.
+
+ 예를 들어, entities Layer 안에는 여러 개의 Slice가 존재하며,
+ 예시로는 user, post, comment 등이 있습니다.
+
+ Slice는 비즈니스 도메인별(user, post, comment)로 나뉘며, 각 Slice 안의 Segment들은 코드의 역할(예: UI, 데이터, 상태) 에 따라 구성됩니다.
+ 예시로 post Slice에는 ui, model, api Segment가 포함됩니다.
+
+
+ );
+}
+```
+
+그런 다음 피드 페이지의 공개 API인 `pages/feed/index.ts` 파일에서 이 컴포넌트를 다시 내보내세요.
+
+```ts title="pages/feed/index.ts"
+export { FeedPage } from "./ui/FeedPage";
+```
+
+이제 루트 경로에 연결합니다. Remix에서 라우팅은 파일 기반이며, 라우트 파일은 `app/routes` 폴더에 있어 Feature-Sliced Design과 잘 맞습니다.
+
+`app/routes/_index.tsx`에서 `FeedPage` 컴포넌트를 사용하세요.
+
+```tsx title="app/routes/_index.tsx"
+import type { MetaFunction } from "@remix-run/node";
+import { FeedPage } from "pages/feed";
+
+export const meta: MetaFunction = () => {
+ return [{ title: "Conduit" }];
+};
+
+export default FeedPage;
+```
+
+그런 다음 개발 서버를 실행하고 애플리케이션을 열면 Conduit 배너가 보일 것입니다!
+
+
+
+### API 클라이언트
+
+RealWorld 백엔드와 통신하기 위해 Shared에 편리한 API 클라이언트를 만들어 봅시다. 클라이언트를 위한 `api`와 백엔드 기본 URL과 같은 변수를 위한 `config`, 두 개의 세그먼트를 만드세요.
+
+
+```bash
+npx fsd shared --segments api config
+```
+
+그런 다음 `shared/config/backend.ts`를 만드세요.
+
+```tsx title="shared/config/backend.ts"
+export { mockBackendUrl as backendBaseUrl } from "mocks/handlers";
+```
+
+```tsx title="shared/config/index.ts"
+export { backendBaseUrl } from "./backend";
+```
+
+RealWorld 프로젝트는 편리하게 [OpenAPI 사양](https://github.com/gothinkster/realworld/blob/main/api/openapi.yml)을 제공하므로, 클라이언트를 위한 자동 생성 타입을 활용할 수 있습니다. 추가 타입 생성기가 포함된 [`openapi-fetch` 패키지](https://openapi-ts.pages.dev/openapi-fetch/)를 사용할 것입니다.
+
+다음 명령을 실행하여 최신 API 타입을 생성하세요.
+
+```bash
+npm run generate-api-types
+```
+
+이렇게 하면 `shared/api/v1.d.ts` 파일이 생성됩니다. 이 파일을 사용하여 `shared/api/client.ts`에 타입이 지정된 API 클라이언트를 만들 것입니다.
+
+```tsx title="shared/api/client.ts"
+import createClient from "openapi-fetch";
+
+import { backendBaseUrl } from "shared/config";
+import type { paths } from "./v1";
+
+export const { GET, POST, PUT, DELETE } = createClient
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+ );
+}
+```
+
+좋아요 버튼은 지금은 아무 작업도 하지 않습니다. 글 읽기 페이지를 만들고 좋아요 기능을 구현할 때 수정하겠습니다.
+
+이제 글을 가져와서 이러한 카드를 여러 개 렌더링할 수 있습니다. Remix에서 데이터 가져오기는 *로더* — 페이지가 필요로 하는 것을 정확히 가져오는 서버 측 함수 — 를 통해 수행됩니다. 로더는 페이지를 대신하여 API와 상호 작용하므로 페이지의 `api` 세그먼트에 넣을 것입니다:
+
+```tsx title="pages/feed/api/loader.ts"
+import { json } from "@remix-run/node";
+
+import { GET } from "shared/api";
+
+export const loader = async () => {
+ const { data: articles, error, response } = await GET("/articles");
+
+ if (error !== undefined) {
+ throw json(error, { status: response.status });
+ }
+
+ return json({ articles });
+};
+```
+
+페이지에 연결하려면 라우트 파일에서 `loader`라는 이름으로 내보내야 합니다.
+
+```tsx title="pages/feed/index.ts"
+export { FeedPage } from "./ui/FeedPage";
+export { loader } from "./api/loader";
+```
+
+```tsx title="app/routes/_index.tsx"
+import type { MetaFunction } from "@remix-run/node";
+import { FeedPage } from "pages/feed";
+
+export { loader } from "pages/feed";
+
+export const meta: MetaFunction = () => {
+ return [{ title: "Conduit" }];
+};
+
+export default FeedPage;
+```
+
+마지막 단계는 피드에 이러한 카드를 렌더링하는 것입니다. `FeedPage`를 다음 코드로 업데이트하세요.
+
+```tsx title="pages/feed/ui/FeedPage.tsx"
+import { useLoaderData } from "@remix-run/react";
+
+import type { loader } from "../api/loader";
+import { ArticlePreview } from "./ArticlePreview";
+
+export function FeedPage() {
+ const { articles } = useLoaderData
+
+
+
+
+
+
+
+ {article.author.username}
+
+
+ {new Date(article.createdAt).toLocaleDateString(undefined, {
+ dateStyle: "long",
+ })}
+
+
+
+ {article.title}
+{article.description}
+ Read more... +-
+ {article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+
+ );
+}
+```
+
+### 태그로 필터링
+
+태그와 관련해서는 백엔드에서 태그를 가져오고 현재 선택된 태그를 저장해야 합니다. 가져오기 방법은 이미 알고 있습니다 — 로더에서 또 다른 요청을 하면 됩니다. `remix-utils` 패키지에서 `promiseHash`라는 편리한 함수를 사용할 것입니다. 이 패키지는 이미 설치되어 있습니다.
+
+로더 파일인 `pages/feed/api/loader.ts`를 다음 코드로 업데이트하세요.
+
+```tsx title="pages/feed/api/loader.ts"
+import { json } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+ );
+}
+```
+
+그런 다음 로더에서 `tag` 검색 매개변수를 사용해야 합니다. `pages/feed/api/loader.ts`의 `loader` 함수를 다음과 같이 변경하세요.
+
+```tsx title="pages/feed/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+
+
+
+ Popular Tags
+ + +
+
+ );
+}
+```
+
+이것으로 완료되었습니다. 탭 목록도 비슷하게 구현할 수 있지만, 인증을 구현할 때까지 잠시 보류하겠습니다. 그런데 말이 나왔으니!
+
+### 인증
+
+인증에는 두 개의 페이지가 관련됩니다 - 로그인과 회원가입입니다. 이들은 대부분 동일하므로 필요한 경우 코드를 재사용할 수 있도록 `sign-in`이라는 동일한 슬라이스에 유지하는 것이 합리적입니다.
+
+`pages/sign-in`의 `ui` 세그먼트에 다음 내용으로 `RegisterPage.tsx`를 만드세요.
+
+```tsx title="pages/sign-in/ui/RegisterPage.tsx"
+import { Form, Link, useActionData } from "@remix-run/react";
+
+import type { register } from "../api/register";
+
+export function RegisterPage() {
+ const registerData = useActionData
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+
+
+
+ Popular Tags
+ + +
+
+ );
+}
+```
+
+이제 고쳐야 할 깨진 import가 있습니다. 새로운 세그먼트가 필요하므로 다음과 같이 만드세요.
+
+```bash
+npx fsd pages sign-in -s api
+```
+
+그러나 등록의 백엔드 부분을 구현하기 전에 Remix가 세션을 처리할 수 있도록 일부 인프라 코드가 필요합니다. 다른 페이지에서도 필요할 수 있으므로 이는 Shared로 갑니다.
+
+다음 코드를 `shared/api/auth.server.ts`에 넣으세요. 이는 Remix에 매우 특화된 것이므로 너무 걱정하지 마세요. 그냥 복사-붙여넣기 하세요.
+
+```tsx title="shared/api/auth.server.ts"
+import { createCookieSessionStorage, redirect } from "@remix-run/node";
+import invariant from "tiny-invariant";
+
+import type { User } from "./models";
+
+invariant(
+ process.env.SESSION_SECRET,
+ "SESSION_SECRET must be set for authentication to work",
+);
+
+const sessionStorage = createCookieSessionStorage<{
+ user: User;
+}>({
+ cookie: {
+ name: "__session",
+ httpOnly: true,
+ path: "/",
+ sameSite: "lax",
+ secrets: [process.env.SESSION_SECRET],
+ secure: process.env.NODE_ENV === "production",
+ },
+});
+
+export async function createUserSession({
+ request,
+ user,
+ redirectTo,
+}: {
+ request: Request;
+ user: User;
+ redirectTo: string;
+}) {
+ const cookie = request.headers.get("Cookie");
+ const session = await sessionStorage.getSession(cookie);
+
+ session.set("user", user);
+
+ return redirect(redirectTo, {
+ headers: {
+ "Set-Cookie": await sessionStorage.commitSession(session, {
+ maxAge: 60 * 60 * 24 * 7, // 7 days
+ }),
+ },
+ });
+}
+
+export async function getUserFromSession(request: Request) {
+ const cookie = request.headers.get("Cookie");
+ const session = await sessionStorage.getSession(cookie);
+
+ return session.get("user") ?? null;
+}
+
+export async function requireUser(request: Request) {
+ const user = await getUserFromSession(request);
+
+ if (user === null) {
+ throw redirect("/login");
+ }
+
+ return user;
+}
+```
+
+그리고 바로 옆에 있는 `models.ts` 파일에서 `User` 모델도 내보내세요.
+
+```tsx title="shared/api/models.ts"
+import type { components } from "./v1";
+
+export type Article = components["schemas"]["Article"];
+export type User = components["schemas"]["User"];
+```
+
+이 코드가 작동하려면 `SESSION_SECRET` 환경 변수를 설정해야 합니다. 프로젝트 루트에 `.env` 파일을 만들고 `SESSION_SECRET=`을 작성한 다음 키보드에서 무작위로 키를 눌러 긴 무작위 문자열을 만드세요. 다음과 같은 결과가 나와야 합니다.
+
+
+```bash title=".env"
+SESSION_SECRET=dontyoudarecopypastethis
+```
+
+마지막으로 이 코드를 사용하기 위해 공개 API에 일부 내보내기를 추가하세요.
+
+```tsx title="shared/api/index.ts"
+export { GET, POST, PUT, DELETE } from "./client";
+
+export type { Article } from "./models";
+
+export { createUserSession, getUserFromSession, requireUser } from "./auth.server";
+```
+
+이제 RealWorld 백엔드와 실제로 통신하여 등록을 수행하는 코드를 작성할 수 있습니다. 그것을 `pages/sign-in/api`에 유지할 것입니다. `register.ts`라는 파일을 만들고 다음 코드를 넣으세요.
+
+
+```tsx title="pages/sign-in/api/register.ts"
+import { json, type ActionFunctionArgs } from "@remix-run/node";
+
+import { POST, createUserSession } from "shared/api";
+
+export const register = async ({ request }: ActionFunctionArgs) => {
+ const formData = await request.formData();
+ const username = formData.get("username")?.toString() ?? "";
+ const email = formData.get("email")?.toString() ?? "";
+ const password = formData.get("password")?.toString() ?? "";
+
+ const { data, error } = await POST("/users", {
+ body: { user: { email, password, username } },
+ });
+
+ if (error) {
+ return json({ error }, { status: 400 });
+ } else {
+ return createUserSession({
+ request: request,
+ user: data.user,
+ redirectTo: "/",
+ });
+ }
+};
+```
+
+```tsx title="pages/sign-in/index.ts"
+export { RegisterPage } from './ui/RegisterPage';
+export { register } from './api/register';
+```
+
+거의 다 왔습니다! 페이지와 액션을 `/register` 라우트에 연결하기만 하면 됩니다. `app/routes`에 `register.tsx`를 만드세요.
+
+```tsx title="app/routes/register.tsx"
+import { RegisterPage, register } from "pages/sign-in";
+
+export { register as action };
+
+export default RegisterPage;
+```
+
+이제 [http://localhost:3000/register](http://localhost:3000/register)로 가면 사용자를 생성할 수 있어야 합니다! 애플리케이션의 나머지 부분은 아직 이에 반응하지 않을 것입니다. 곧 그 문제를 해결하겠습니다.
+
+매우 유사한 방식으로 로그인 페이지를 구현할 수 있습니다. 직접 시도해 보거나 그냥 코드를 가져와서 계속 진행하세요.
+
+```tsx title="pages/sign-in/api/sign-in.ts"
+import { json, type ActionFunctionArgs } from "@remix-run/node";
+
+import { POST, createUserSession } from "shared/api";
+
+export const signIn = async ({ request }: ActionFunctionArgs) => {
+ const formData = await request.formData();
+ const email = formData.get("email")?.toString() ?? "";
+ const password = formData.get("password")?.toString() ?? "";
+
+ const { data, error } = await POST("/users/login", {
+ body: { user: { email, password } },
+ });
+
+ if (error) {
+ return json({ error }, { status: 400 });
+ } else {
+ return createUserSession({
+ request: request,
+ user: data.user,
+ redirectTo: "/",
+ });
+ }
+};
+```
+
+```tsx title="pages/sign-in/ui/SignInPage.tsx"
+import { Form, Link, useActionData } from "@remix-run/react";
+
+import type { signIn } from "../api/sign-in";
+
+export function SignInPage() {
+ const signInData = useActionData
+
+
+
+
+
+ Sign up
++ Have an account? +
+ + {registerData?.error && ( +-
+ {registerData.error.errors.body.map((error) => (
+
- {error} + ))} +
+
+ );
+}
+```
+
+```tsx title="pages/sign-in/index.ts"
+export { RegisterPage } from './ui/RegisterPage';
+export { register } from './api/register';
+export { SignInPage } from './ui/SignInPage';
+export { signIn } from './api/sign-in';
+```
+
+```tsx title="app/routes/login.tsx"
+import { SignInPage, signIn } from "pages/sign-in";
+
+export { signIn as action };
+
+export default SignInPage;
+```
+
+이제 사용자가 이 페이지에 실제로 접근할 수 있는 방법을 제공해 봅시다.
+
+### 헤더
+
+1부에서 논의했듯이, 앱 헤더는 일반적으로 Widgets나 Shared에 배치됩니다. 매우 간단하고 모든 비즈니스 로직을 외부에 유지할 수 있기 때문에 Shared에 넣을 것입니다. 이를 위한 장소를 만들어 봅시다.
+
+```bash
+npx fsd shared ui
+```
+
+이제 다음 내용으로 `shared/ui/Header.tsx`를 만드세요.
+
+```tsx title="shared/ui/Header.tsx"
+import { useContext } from "react";
+import { Link, useLocation } from "@remix-run/react";
+
+import { CurrentUser } from "../api/currentUser";
+
+export function Header() {
+ const currentUser = useContext(CurrentUser);
+ const { pathname } = useLocation();
+
+ return (
+
+ );
+}
+```
+
+이 컴포넌트를 `shared/ui`에서 내보내세요.
+
+```tsx title="shared/ui/index.ts"
+export { Header } from "./Header";
+```
+
+헤더에서는 `shared/api`에 유지되는 컨텍스트에 의존합니다. 그것도 만드세요.
+
+```tsx title="shared/api/currentUser.ts"
+import { createContext } from "react";
+
+import type { User } from "./models";
+
+export const CurrentUser = createContext
+
+
+
+
+
+ Sign in
++ Need an account? +
+ + {signInData?.error && ( +-
+ {signInData.error.errors.body.map((error) => (
+
- {error} + ))} +
+
+ );
+}
+```
+
+```tsx title="pages/feed/ui/Pagination.tsx"
+import { Form, useLoaderData, useSearchParams } from "@remix-run/react";
+import { ExistingSearchParams } from "remix-utils/existing-search-params";
+
+import { LIMIT, type loader } from "../api/loader";
+
+export function Pagination() {
+ const [searchParams] = useSearchParams();
+ const { articles } = useLoaderDataPopular Tags
+ + +
+
+ );
+}
+```
+
+마지막으로 로더를 업데이트하여 새로운 필터를 처리하세요.
+
+```tsx title="pages/feed/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET, requireUser } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+이 코드는 글에 좋아요를 표시하기 위해 `/article/:slug`로 `_action=favorite`과 함께 POST 요청을 보냅니다. 아직 작동하지 않겠지만, 글 읽기 페이지 작업을 시작하면서 이것도 구현할 것입니다.
+
+이것으로 피드가 공식적으로 완성되었습니다! 야호!
+
+### 글 읽기 페이지
+
+먼저 데이터가 필요합니다. 로더를 만들어 봅시다.
+
+```bash
+npx fsd pages article-read -s api
+```
+
+```tsx title="pages/article-read/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import invariant from "tiny-invariant";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET, getUserFromSession } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+
+
+
+ {article.author.username}
+
+
+ {new Date(article.createdAt).toLocaleDateString(undefined, {
+ dateStyle: "long",
+ })}
+
+
+
+ {article.title}
+{article.description}
+ Read more... +-
+ {article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+
+ );
+}
+```
+
+더 흥미로운 것은 `ArticleMeta`와 `Comments`입니다. 이들은 글 좋아요, 댓글 작성 등과 같은 쓰기 작업을 포함합니다. 이들을 작동시키려면 먼저 백엔드 부분을 구현해야 합니다. 페이지의 `api` 세그먼트에 `action.ts`를 만드세요:
+
+```tsx title="pages/article-read/api/action.ts"
+import { redirect, type ActionFunctionArgs } from "@remix-run/node";
+import { namedAction } from "remix-utils/named-action";
+import { redirectBack } from "remix-utils/redirect-back";
+import invariant from "tiny-invariant";
+
+import { DELETE, POST, requireUser } from "shared/api";
+
+export const action = async ({ request, params }: ActionFunctionArgs) => {
+ const currentUser = await requireUser(request);
+
+ const authorization = { Authorization: `Token ${currentUser.token}` };
+
+ const formData = await request.formData();
+
+ return namedAction(formData, {
+ async delete() {
+ invariant(params.slug, "Expected a slug parameter");
+ await DELETE("/articles/{slug}", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirect("/");
+ },
+ async favorite() {
+ invariant(params.slug, "Expected a slug parameter");
+ await POST("/articles/{slug}/favorite", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async unfavorite() {
+ invariant(params.slug, "Expected a slug parameter");
+ await DELETE("/articles/{slug}/favorite", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async createComment() {
+ invariant(params.slug, "Expected a slug parameter");
+ const comment = formData.get("comment");
+ invariant(typeof comment === "string", "Expected a comment parameter");
+ await POST("/articles/{slug}/comments", {
+ params: { path: { slug: params.slug } },
+ headers: { ...authorization, "Content-Type": "application/json" },
+ body: { comment: { body: comment } },
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async deleteComment() {
+ invariant(params.slug, "Expected a slug parameter");
+ const commentId = formData.get("id");
+ invariant(typeof commentId === "string", "Expected an id parameter");
+ const commentIdNumeric = parseInt(commentId, 10);
+ invariant(
+ !Number.isNaN(commentIdNumeric),
+ "Expected a numeric id parameter",
+ );
+ await DELETE("/articles/{slug}/comments/{id}", {
+ params: { path: { slug: params.slug, id: commentIdNumeric } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async followAuthor() {
+ const authorUsername = formData.get("username");
+ invariant(
+ typeof authorUsername === "string",
+ "Expected a username parameter",
+ );
+ await POST("/profiles/{username}/follow", {
+ params: { path: { username: authorUsername } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async unfollowAuthor() {
+ const authorUsername = formData.get("username");
+ invariant(
+ typeof authorUsername === "string",
+ "Expected a username parameter",
+ );
+ await DELETE("/profiles/{username}/follow", {
+ params: { path: { username: authorUsername } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ });
+};
+```
+
+그 슬라이스에서 이를 내보내고 라우트에서도 내보내세요. 그리고 페이지 자체도 연결하겠습니다.
+
+```tsx title="pages/article-read/index.ts"
+export { ArticleReadPage } from "./ui/ArticleReadPage";
+export { loader } from "./api/loader";
+export { action } from "./api/action";
+```
+
+```tsx title="app/routes/article.$slug.tsx"
+import { ArticleReadPage } from "pages/article-read";
+
+export { loader, action } from "pages/article-read";
+
+export default ArticleReadPage;
+```
+
+이제 독자 페이지에서 좋아요 버튼을 아직 구현하지 않았지만, 피드의 좋아요 버튼이 작동하기 시작할 것입니다! 이 라우트로 "좋아요" 요청을 보내고 있었기 때문입니다. 한번 시도해 보세요.
+
+`ArticleMeta`와 `Comments`는 다시 한번 폼들의 모음입니다. 이전에 이미 해봤으니, 코드를 가져와서 넘어가겠습니다.
+
+```tsx title="pages/article-read/ui/ArticleMeta.tsx"
+import { Form, Link, useLoaderData } from "@remix-run/react";
+import { useContext } from "react";
+
+import { CurrentUser } from "shared/api";
+import type { loader } from "../api/loader";
+
+export function ArticleMeta() {
+ const currentUser = useContext(CurrentUser);
+ const { article } = useLoaderData
+
+
+
+
+ {article.article.title}
+ +
+
+ +
+
+
+
+
+
+ {article.article.body}
+-
+ {article.article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+ +
+
+
+
+
+
+ {currentUser !== null ? (
+
+ ) : (
+
+ );
+}
+```
+
+이것으로 우리의 글 읽기 페이지도 완성되었습니다! 이제 작성자를 팔로우하고, 글에 좋아요를 누르고, 댓글을 남기는 버튼들이 예상대로 작동해야 합니다.
+
+
+
+ )}
+
+ {comments.comments.map((comment) => (
+
+
+ + Sign in + or + Sign up + to add comments on this article. +
+
+
+ ))}
+
+
+
+ {comment.body}
+
+
+
+
+
+
+ {comment.author.username}
+
+ {comment.createdAt}
+ {comment.author.username === currentUser?.username && (
+
+
+
+ )}
+
+
+
+ );
+}
+```
+
+이 페이지는 현재 글(새로 작성하는 경우가 아니라면)을 가져와서 해당하는 폼 필드를 채웁니다. 이전에 본 적이 있습니다. 흥미로운 부분은 `FormErrors`인데, 이는 검증 결과를 받아 사용자에게 표시할 것입니다. 한번 살펴보겠습니다.
+
+```tsx title="pages/article-edit/ui/FormErrors.tsx"
+import { useActionData } from "@remix-run/react";
+import type { action } from "../api/action";
+
+export function FormErrors() {
+ const actionData = useActionData
+
+
+
+
+
+ -
+ {actionData.errors.map((error) => (
+
- {error} + ))} +
+ {tagListState.map((tag) => (
+
+
+ [" ", "Enter"].includes(e.key) && removeTag(tag)
+ }
+ onClick={() => removeTag(tag)}
+ >{" "}
+ {tag}
+
+ ))}
+
+
+ );
+}
+```
+
+이제 API 부분입니다. 로더는 URL을 살펴보고, 글 슬러그가 포함되어 있다면 기존 글을 수정하는 것이므로 해당 데이터를 로드해야 합니다. 그렇지 않으면 아무것도 반환하지 않습니다. 그 로더를 만들어 봅시다.
+
+```ts title="pages/article-edit/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+
+import { GET, requireUser } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+```ts title="shared/ui/layout/useThemeSwitcher.ts"
+export function useThemeSwitcher() {
+ const [theme, setTheme] = useState("light");
+
+ function toggleTheme() {
+ setTheme(theme === "light" ? "dark" : "light");
+ }
+
+ useEffect(() => {
+ document.body.classList.remove("light", "dark");
+ document.body.classList.add(theme);
+ }, [theme]);
+
+ return [theme, toggleTheme] as const;
+}
+```
+
+위 예시에서 사이드바 UI 자체 구현 코드는 길어질 수 있으므로, 설명에서는 생략했습니다.
+중요한 포인트는 layout이 **틀만 제공하고, 구체적인 내용은 props로 받아서 렌더링한다** 는 점입니다.
+
+## layout에 widget 적용하기
+
+layout 컴포넌트에서 인증 처리나 데이터 로딩 같은 **비즈니스 로직**을 수행해야 할 때가 있습니다.
+예를 들어, [React Router][ext-react-router]의 deeply nested routes 구조에서는 `/users`, `/users/:id`, `/users/:id/settings` 처럼
+공통된 URL prefix를 가진 여러 child routes가 존재합니다.
+
+이 경우, 인증 확인이나 공통 데이터 로딩 같은 로직을
+각 페이지마다 작성하기보다는 **layout 레벨에서 한 번에 처리**하는 방식이 훨씬 효율적입니다.
+
+다만 이런 layout을 shared나 widgets 폴더에 두면
+[layer에 대한 import 규칙][import-rule-on-layers]을 위반할 수 있습니다.
+
+> Slice의 module은 자신보다 **하위 layer**에 있는 Slice만 import할 수 있습니다.
+
+즉, layout에서 entity/feature/page를 직접 불러오게 되면
+**위에서 아래를 가져오는** 잘못된 의존성이 생길 수 있습니다.
+
+그래서 먼저 아래와 같은 점을 고려하는 것이 좋습니다.
+
+- _이 layout이 정말 필요한가?_
+- _꼭 widget 형태로 만들 필요가 있는가?_
+
+layout이 적용되는 페이지 수가 2~3곳 정도라면,
+이 layout이 사실상 **특정 페이지만을 위한 wrapper**일 수도 있으며 굳이 widget으로 승격시킬 필요가 없을 수 있습니다.
+
+이런 상황에서는 아래 두 가지 대안을 먼저 고려하세요.
+
+1. **App layer에서 inline으로 작성하기**
+URL 패턴이 공통된 여러 경로를 Router의 nesting 기능으로 묶어 하나의 route group으로 만들 수 있습니다.
+이 route group에 layout을 한 번만 지정하면, 해당 그룹 아래 모든 페이지에 자동으로 동일한 layout이 적용됩니다.
+
+1. **코드 복사 & 붙여넣기**
+layout은 자주 변경되는 코드가 아니므로,
+필요한 페이지만 layout 코드를 복사해 사용해도 큰 문제가 없습니다.
+수정이 필요할 때만 해당 layout들을 개별적으로 업데이트하면 되고,
+페이지 간 관계를 주석으로 남겨 두면 누락을 방지할 수 있습니다.
+
+---
+
+위 방법들이 프로젝트에 맞지 않다면,
+layout 안에서 widget을 사용하는 다음 두 가지 해결책을 고려할 수 있습니다.
+
+### 1. Render Props 또는 Slots 사용하기
+
+React에서는 [render props][ext-render-props] 패턴을, Vue에서는 [slots][ext-vue-slots] 기능을 사용합니다.
+
+이 방식은 부모인 layout 컴포넌트가 **UI 틀을 제공하고**,
+자식 컴포넌트가 전달한 UI를 layout 내부 특정 위치에 **주입(injection)** 하는 구조입니다.
+Layout이 비즈니스 로직을 직접 수행하면서도,
+UI 구성은 외부에서 유연하게 가져올 수 있다는 장점이 있습니다.
+
+### 2. layout을 App layer로 이동하기
+
+layout을 app/layouts 같은 상위 layer로 옮기면,
+App layer는 아래 layer(entities, features, shared)를 자유롭게 import할 수 있기 때문에
+Layer 규칙을 위반하지 않고 layout 안에서 widget을 사용할 수 있습니다.
+
+## 참고 자료
+
+React 및 Remix(React Router와 구조가 유사)의
+인증 layout 구현 예시는 [튜토리얼][tutorial] 문서에서 확인할 수 있습니다.
+
+[tutorial]: /docs/get-started/tutorial
+[import-rule-on-layers]: /docs/reference/layers#import-rule-on-layers
+[ext-react-router]: https://reactrouter.com/
+[ext-render-props]: https://www.patterns.dev/react/render-props-pattern/
+[ext-vue-slots]: https://vuejs.org/guide/components/slots,
diff --git a/src/content/docs/kr/docs/guides/examples/types.mdx b/src/content/docs/kr/docs/guides/examples/types.mdx
new file mode 100644
index 0000000000..340aa12d5d
--- /dev/null
+++ b/src/content/docs/kr/docs/guides/examples/types.mdx
@@ -0,0 +1,573 @@
+---
+title: Types
+sidebar:
+ order: 2
+---
+
+import { Aside, FileTree } from '@astrojs/starlight/components';
+
+이 가이드는 TypeScript 같은 정적 타입 언어에서 **데이터를 어떻게 정의하고 활용할지**,
+그리고 FSD 구조 안에서 **각 타입을 어디에 배치하는 것이 좋은지**를 설명합니다.
+
+
+
+## 유틸리티 타입
+
+유틸리티 타입은 **그 자체로 큰 의미를 가지기보다는, 다른 타입과 함께 자주 사용되는 보조 타입**을 말합니다.
+예를 들어, 배열에서 요소 타입만 추출하는 `ArrayValues` 같은 타입을 아래와 같이 정의할 수 있습니다.
+
++ +## 1단계: 페이지 단위로 코드 분리하기 \{#divide-code-by-pages} + +대부분의 커스텀 아키텍처는 규모와 관계없이 이미 어느 정도 페이지 단위로 코드를 나누고 있습니다. +`📁 pages` 폴더가 있다면 이 단계를 건너뛰어도 됩니다. + +위에 예시 폴더처럼 `📁 routes`만 있다면 다음 순서를 따르세요. + +1. `📁 pages` 폴더를 새로 만듭니다. +2. `📁 routes`에 있던 **페이지용 컴포넌트**를 가능한 한 모두 `📁 pages` 폴더로 옮깁니다. +3. 코드를 옮길 때마다 해당 페이지 전용 폴더를 만들고 그 안에 `index.tsx` 파일을 추가해 **진입점(entry point)** 를 노출합니다. + + + +**📁 Route File** + +```js title="route file:src/routes/products.[id].js" +export { ProductPage as default } from "src/pages/product"; +``` + +**📁 Page Index File** + +```js title="src/pages/product/index.js" +export { ProductPage } from "./ProductPage.jsx"; +``` + +**📁 Page Component File** + +```jsx title="src/pages/product/ProductPage.jsx" +export function ProductPage(props) { + return ; +} +``` + +## 2단계: 페이지 외부 코드를 분리하기 \{#separate-everything-else-from-pages} + +**📁 src/shared 폴더를 만들고,** 📁 pages 또는 📁 routes를 import하지 않는 모든(파일)은 이 폴더로 모읍니다. +**📁 src/app 폴더를 만들고,** 📁 pages 또는 📁 routes를 import하는 모듈과 라우트 정의 파일은 이 폴더에 배치합니다. + +> **Shared layer는 slice 개념이 존재하지 않기 때문에,** 서로 다른 segment 간에도 자유롭게 import할 수 있습니다 + +이제 폴더 구조는 다음과 같아야 합니다: + +
+FSD `src/pages`의 각 페이지 컴포넌트를 `pages` 폴더에서 **re-export** 하면 NextJS 라우팅과 FSD 구조를 모두 유지할 수 있습니다. + + +
Loading...
;
+ }
+
+ if (isError || !post) {
+ return <>{error?.message};
+ }
+
+ return (
+
+
+ );
+};
+```
+
+### Query Factory 사용의 장점
+- **Request 구조화**: 모든 API 호출을 Factory 패턴으로 통합 관리해, 코드 가독성과 유지보수성을 개선합니다.
+- **Query와 Key에 대한 편리한 접근**: 다양한 Query Type과 해당 Key를 메서드로 제공해, 언제든 간편하게 참조할 수 있습니다.
+- **Query Invalidation 용이성**: Query Key를 직접 수정하지 않고도 원하는 Query를 손쉽게 무효화할 수 있습니다.
+
+## Pagination
+
+Pagination을 적용해 `getPosts` 함수로 게시물 목록을 가져오는 과정을 설명합니다.
+
+### `getPosts` 함수 생성하기
+
+`src/pages/post-feed/api/get-posts.ts` 파일에 다음과 같이 정의됩니다.
+
+```tsx title="@/pages/post-feed/api/get-posts.ts"
+import { apiClient } from "@/shared/api/base";
+
+import { PostWithPaginationDto } from "./dto/post-with-pagination.dto";
+import { PostQuery } from "./query/post.query";
+import { mapPost } from "./mapper/map-post";
+import { PostWithPagination } from "../model/post-with-pagination";
+
+const calculatePostPage = (totalCount: number, limit: number) =>
+ Math.floor(totalCount / limit);
+
+export const getPosts = async (
+ page: number,
+ limit: number,
+): PromisePost id: {post.id}
+
+
+ {post.title}
+
+
+ {post.body}
+Owner: {post.userId}
+
+
+
+1. App
+2. Processes (deprecated)
+3. Pages
+4. Widgets
+5. Features
+6. Entities
+7. Shared
+
+> 모든 Layer를 반드시 사용해야 하는 것은 아닙니다.
+> **필요한 경우에만** Layer를 추가하세요.
+> 대부분의 프론트엔드 프로젝트는 보통 최소한 `shared`, `page`, `app` 정도는 사용합니다.
+
+실무에서는 폴더명을 보통 소문자로 작성합니다. (예: `📁 shared`, `📁 page`, `📁 app`)
+또한, **새로운 Layer를 직접 정의해서 사용하는 것은 권장하지 않습니다.**
+(각 Layer의 역할이 이미 표준으로 충분히 정리되어 있기 때문입니다.)
+
+## Import 규칙
+
+각 Layer는 여러 개의 **Slice(서로 밀접하게 연관된 모듈 묶음)** 로 구성됩니다.
+Slice들 사이의 연결은 **Layer Import 규칙**을 통해 제한합니다.
+
+> **규칙:**
+> 하나의 Slice 안에서 작성된 코드는
+> **자신이 속한 Layer보다 아래 Layer**에 있는 *다른 Slice*만 import할 수 있습니다.
+
+예를 들어, `📁 ~/features/aaa/api/request.ts` 파일은 다음과 같습니다.
+
+- 같은 Layer의 `📁 ~/features/bbb` → **import 불가능**
+- 더 아래 Layer(`📁 ~/entities`, `📁 ~/shared`) → **import 가능**
+- 같은 Slice(`📁 ~/features/aaa/lib/cache.ts`) → **import 가능**
+
+`app`과 `shared`는 조금 특이한 Layer입니다.
+두 Layer는 **Layer이면서 동시에 하나의 큰 Slice처럼 동작**하고 내부 구조는 **Segment**로 나뉩니다.
+
+이 경우에는 Layer 내부에서 Segment끼리는 자유롭게 import할 수 있습니다.
+(`shared`는 비즈니스 도메인이 없고, `app`은 모든 도메인을 묶는 상위 조정자 역할을 합니다.)
+
+## Layer별 역할
+
+이제 각 Layer가 어떤 의미를 가지는지,
+그리고 보통 어떤 종류의 코드가 해당 Layer에 들어오는지 정리해 보겠습니다.
+
+### Shared
+
+Shared Layer는 앱의 **기본 구성 요소와 기반 도구들을 모아두는 곳**입니다.
+백엔드, 서드파티 라이브러리, 실행 환경과의 연결,
+그리고 여러 곳에서 사용하는 **응집도 높은 내부 라이브러리**가 여기에 위치합니다.
+
+`app`과 마찬가지로 **Slice 없이 Segment로만 구성**합니다.
+비즈니스 도메인이 없기 때문에, **Shared 내부의 파일들은 서로 자유롭게 import**할 수 있습니다.
+
+Segment 예시:
+
+- `📁 api` — API 클라이언트와 공통 백엔드 요청 함수
+- `📁 ui` — 공통 UI 컴포넌트
+ - **비즈니스 로직은 포함하지 않지만**, **브랜드 테마는 적용 가능**
+ - 로고, 레이아웃, 자동완성/검색창 등 **UI 자체 로직**을 포함하는 컴포넌트는 허용
+- `📁 lib` — 내부 라이브러리
+ - 단순히 `utils/helpers`를 모아두는 폴더가 아닙니다. ([이 글 참고][ext-sova-utility-dump])
+ - 날짜, 색상, 텍스트 등 **하나의 주제에 집중**해야 합니다.
+ - README를 통해 역할과 범위를 문서화하는 것을 권장합니다.
+- `📁 config` — 환경변수, 전역 Feature Flag
+- `📁 routes` — 라우트 상수/패턴
+- `📁 i18n` — 번역 설정, 전역 문자열
+
+> Segment 이름은 **이 폴더가 무엇을 하는지**를 명확하게 드러내야 합니다.
+> `components`, `hooks`, `types`처럼 역할이 모호한 이름은 가급적 피하세요.
+
+### Entities
+
+Entities Layer는 프로젝트에서 다루는 **핵심 비즈니스 개념**을 표현합니다.
+대부분의 경우, 실제 도메인 용어(예: `User`, `Post`, `Product`)와 일치합니다.
+
+각 Entity Slice에는 다음과 같은 것들을 포함할 수 있습니다.
+
+구성:
+
+- `📁 model` — 데이터 상태, 도메인 로직, 검증 스키마
+- `📁 api` — 해당 Entity와 관련된 API 요청
+- `📁 ui` — Entity의 시각적 표현
+ - 완성된 큰 UI 블록이 아니어도 됩니다.
+ - 여러 페이지에서 재사용 가능한 형태로 설계합니다.
+ - 비즈니스 로직은 가능하면 props/slot으로 외부에서 주입하는 방식을 권장합니다.
+
+#### Entity 간 관계
+
+원칙적으로는 Entity Slice끼리는 서로 **서로를 모르는 상태**가 이상적입니다.
+하지만 실제 애플리케이션에서는 한 Entity가 다른 Entity를 **포함하거나**
+여러 Entity가 서로 **상호작용**하는 일이 자주 발생합니다.
+
+이런 경우, 두 Entity 간의 구체적인 상호작용 로직은
+**상위 Layer(Feature 또는 Page)** 로 올려서 처리하는 것이 좋습니다.
+
+만약 한 Entity의 데이터 안에 다른 Entity가 포함되어야 한다면,
+`@x` 표기법을 사용해 **교차 Public API**를 통해 연결되었음을 명시해 주세요.
+
+```ts title="entities/artist/model/artist.ts"
+import type { Song } from "entities/song/@x/artist";
+
+export interface Artist {
+ name: string;
+ songs: Array
+
+
+
+ На картинке выше: три столбика, обозначенные слева направо как "Слои", "Слайсы" и "Сегменты" соответственно.
+Столбик "Слои" содержит семь делений, расположенных сверху вниз и обозначенных "app", "processes", "pages", "widgets", "features", "entities" и "shared". Деление "processes" зачеркнуто. Деление "entities" соединено со вторым столбиком "Слайсы", показывая, что второй столбик является содержимым "entities".
+Столбик "Слайсы" содержит три деления, расположенных сверху вниз и обозначенных "user", "post" и "comment". Деление "post" соединено со столбиком "Сегменты" таким же образом, что и содержимое "post".
+Столбик "Сегменты" содержит три деления, расположенных сверху вниз и обозначенных "ui", "model" и "api".
+
+
+ );
+}
+```
+
+Затем ре-экспортируйте этот компонент в публичном API страницы фида, файл `pages/feed/index.ts`:
+
+```tsx title="pages/feed/index.ts"
+export { FeedPage } from "./ui/FeedPage";
+```
+
+Теперь подключите его к корневому маршруту. В Remix маршрутизация работает на файлах, и файлы маршрутов находятся в папке `app/routes`, что хорошо сочетается с Feature-Sliced Design.
+
+Используйте компонент `FeedPage` в `app/routes/_index.tsx`:
+
+```tsx title="app/routes/_index.tsx"
+import type { MetaFunction } from "@remix-run/node";
+import { FeedPage } from "pages/feed";
+
+export const meta: MetaFunction = () => {
+ return [{ title: "Conduit" }];
+};
+
+export default FeedPage;
+```
+
+Затем, если вы запустите dev-сервер и откроете приложение, вы должны увидеть баннер Conduit!
+
+
+
+### API-клиент
+
+Чтобы общаться с бэкендом RealWorld, давайте создадим удобный API-клиент в Shared. Создайте два сегмента, `api` для клиента и `config` для таких переменных как базовый URL бэкенда:
+
+```bash
+npx fsd shared --segments api config
+```
+
+Затем создайте `shared/config/backend.ts`:
+
+```tsx title="shared/config/backend.ts"
+export { mockBackendUrl as backendBaseUrl } from "mocks/handlers";
+```
+
+```tsx title="shared/config/index.ts"
+export { backendBaseUrl } from "./backend";
+```
+
+Поскольку проект RealWorld предоставляет [спецификацию OpenAPI](https://github.com/gothinkster/realworld/blob/main/api/openapi.yml), мы можем автоматически сгенерировать типы для нашего API-клиента. Мы будем использовать [пакет `openapi-fetch`](https://openapi-ts.pages.dev/openapi-fetch/), в котором дополнительно есть генератор типов.
+
+Выполните следующую команду, чтобы сгенерировать актуальные типы для API:
+
+```bash
+npm run generate-api-types
+```
+
+В результате будет создан файл `shared/api/v1.d.ts`. Мы воспользуемся этим файлом в `shared/api/client.ts` для создания типизированного клиента API:
+
+```tsx title="shared/api/client.ts"
+import createClient from "openapi-fetch";
+
+import { backendBaseUrl } from "shared/config";
+import type { paths } from "./v1";
+
+export const { GET, POST, PUT, DELETE } = createClient
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+ );
+}
+```
+
+Кнопка "Мне нравится" пока ничего не делает, мы исправим это, когда перейдем на страницу чтения статей и реализуем функцию "Мне нравится".
+
+Теперь мы можем получить статьи и отобразить кучу этих карточек предпросмотра. Получение данных в Remix осуществляется с помощью *загрузчиков* — серверных функций, которые собирают те данные, которые нужны странице. Загрузчики взаимодействуют с API от имени страницы, поэтому мы поместим их в сегмент `api` страницы:
+
+```tsx title="pages/feed/api/loader.ts"
+import { json } from "@remix-run/node";
+
+import { GET } from "shared/api";
+
+export const loader = async () => {
+ const { data: articles, error, response } = await GET("/articles");
+
+ if (error !== undefined) {
+ throw json(error, { status: response.status });
+ }
+
+ return json({ articles });
+};
+```
+
+Чтобы подключить его к странице, нам нужно экспортировать его с именем `loader` из файла маршрута:
+
+```tsx title="pages/feed/index.ts"
+export { FeedPage } from "./ui/FeedPage";
+export { loader } from "./api/loader";
+```
+
+```tsx title="app/routes/_index.tsx"
+import type { MetaFunction } from "@remix-run/node";
+import { FeedPage } from "pages/feed";
+
+export { loader } from "pages/feed";
+
+export const meta: MetaFunction = () => {
+ return [{ title: "Conduit" }];
+};
+
+export default FeedPage;
+```
+
+И последний шаг — отображение этих карточек в ленте. Обновите `FeedPage` следующим кодом:
+
+```tsx title="pages/feed/ui/FeedPage.tsx"
+import { useLoaderData } from "@remix-run/react";
+
+import type { loader } from "../api/loader";
+import { ArticlePreview } from "./ArticlePreview";
+
+export function FeedPage() {
+ const { articles } = useLoaderData
+
+
+
+
+
+
+
+ {article.author.username}
+
+
+ {new Date(article.createdAt).toLocaleDateString(undefined, {
+ dateStyle: "long",
+ })}
+
+
+
+ {article.title}
+{article.description}
+ Read more... +-
+ {article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+
+ );
+}
+```
+
+### Фильтрация по тегам
+
+Что касается тегов, то наша задача — получить их из бэкенда и запомнить выбранный пользователем тег. Мы уже знаем, как загружать из бэкенда — это еще один запрос от функции-загрузчика. Мы будем использовать удобную функцию `promiseHash` из пакета `remix-utils`, который уже установлен.
+
+Обновите файл загрузчика, `pages/feed/api/loader.ts`, следующим кодом:
+
+```tsx title="pages/feed/api/loader.ts"
+import { json } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+ );
+}
+```
+
+Затем нам нужно использовать параметр поиска тегов в нашем загрузчике. Измените функцию `loader` в `pages/feed/api/loader.ts` на следующую:
+
+```tsx title="pages/feed/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+
+
+
+ Popular Tags
+ + +
+
+ );
+}
+```
+
+Ну вот, это тоже сделали. Есть еще список вкладок, который можно реализовать аналогичным образом, но давайте повременим с этим, пока не реализуем аутентификацию. Кстати, о ней!
+
+### Аутентификация \{#authentication}
+
+Аутентификация включает в себя две страницы — одну для входа в систему и другую для регистрации. Они, в основном, очень схожие, поэтому имеет смысл держать их в одном слайсе, `sign-in`, чтобы при необходимости можно было переиспользовать код.
+
+Создайте `RegisterPage.tsx` в сегменте `ui` в `pages/sign-in` со следующим содержимым:
+
+```tsx title="pages/sign-in/ui/RegisterPage.tsx"
+import { Form, Link, useActionData } from "@remix-run/react";
+
+import type { register } from "../api/register";
+
+export function RegisterPage() {
+ const registerData = useActionData
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+ {articles.articles.map((article) => (
+
+
+
+
+
+
+ Popular Tags
+ + +
+
+ );
+}
+```
+
+Сейчас нам нужно исправить сломанный импорт. Он обращается к новому сегменту, поэтому создайте его:
+
+```bash
+npx fsd pages sign-in -s api
+```
+
+Однако прежде чем мы сможем реализовать бэкенд-часть регистрации, нам нужен некоторый инфраструктурный код для Remix для обработки сессий. Отправим его в Shared, на случай, если он понадобится какой-либо другой странице.
+
+Поместите следующий код в `shared/api/auth.server.ts`. Этот код очень специфичен для Remix, так что не беспокойтесь, если там не все понятно, просто скопируйте и вставьте:
+
+```tsx title="shared/api/auth.server.ts"
+import { createCookieSessionStorage, redirect } from "@remix-run/node";
+import invariant from "tiny-invariant";
+
+import type { User } from "./models";
+
+invariant(
+ process.env.SESSION_SECRET,
+ "SESSION_SECRET must be set for authentication to work",
+);
+
+const sessionStorage = createCookieSessionStorage<{
+ user: User;
+}>({
+ cookie: {
+ name: "__session",
+ httpOnly: true,
+ path: "/",
+ sameSite: "lax",
+ secrets: [process.env.SESSION_SECRET],
+ secure: process.env.NODE_ENV === "production",
+ },
+});
+
+export async function createUserSession({
+ request,
+ user,
+ redirectTo,
+}: {
+ request: Request;
+ user: User;
+ redirectTo: string;
+}) {
+ const cookie = request.headers.get("Cookie");
+ const session = await sessionStorage.getSession(cookie);
+
+ session.set("user", user);
+
+ return redirect(redirectTo, {
+ headers: {
+ "Set-Cookie": await sessionStorage.commitSession(session, {
+ maxAge: 60 * 60 * 24 * 7, // 7 days
+ }),
+ },
+ });
+}
+
+export async function getUserFromSession(request: Request) {
+ const cookie = request.headers.get("Cookie");
+ const session = await sessionStorage.getSession(cookie);
+
+ return session.get("user") ?? null;
+}
+
+export async function requireUser(request: Request) {
+ const user = await getUserFromSession(request);
+
+ if (user === null) {
+ throw redirect("/login");
+ }
+
+ return user;
+}
+```
+
+А также экспортируйте модель `User` из файла `models.ts`, расположенного рядом с ним:
+
+```tsx title="shared/api/models.ts"
+import type { components } from "./v1";
+
+export type Article = components["schemas"]["Article"];
+export type User = components["schemas"]["User"];
+```
+
+Прежде чем этот код заработает, необходимо установить переменную окружения `SESSION_SECRET`. Создайте файл `.env` в корне проекта, пропишите в нем `SESSION_SECRET=`, а затем пробегитесь по клавиатуре, чтобы создать длинную случайную строку. У вас должно получиться что-то вроде этого:
+
+```bash title=".env"
+SESSION_SECRET=несмейтеэтокопировать
+```
+
+Наконец, добавьте несколько экспортов в публичный API, чтобы использовать этот код:
+
+```tsx title="shared/api/index.ts"
+export { GET, POST, PUT, DELETE } from "./client";
+
+export type { Article } from "./models";
+
+export { createUserSession, getUserFromSession, requireUser } from "./auth.server";
+```
+
+Теперь мы можем написать код, который будет общаться с бэкендом RealWorld для регистрации. Мы сохраним его в `pages/sign-in/api`. Создайте файл `register.ts` и поместите в него следующий код:
+
+```tsx title="pages/sign-in/api/register.ts"
+import { json, type ActionFunctionArgs } from "@remix-run/node";
+
+import { POST, createUserSession } from "shared/api";
+
+export const register = async ({ request }: ActionFunctionArgs) => {
+ const formData = await request.formData();
+ const username = formData.get("username")?.toString() ?? "";
+ const email = formData.get("email")?.toString() ?? "";
+ const password = formData.get("password")?.toString() ?? "";
+
+ const { data, error } = await POST("/users", {
+ body: { user: { email, password, username } },
+ });
+
+ if (error) {
+ return json({ error }, { status: 400 });
+ } else {
+ return createUserSession({
+ request: request,
+ user: data.user,
+ redirectTo: "/",
+ });
+ }
+};
+```
+
+```tsx title="pages/sign-in/index.ts"
+export { RegisterPage } from './ui/RegisterPage';
+export { register } from './api/register';
+```
+
+Почти готово! Осталось подключить страницу и действие регистрации к маршруту `/register`. Создайте `register.tsx` в `app/routes`:
+
+```tsx title="app/routes/register.tsx"
+import { RegisterPage, register } from "pages/sign-in";
+
+export { register as action };
+
+export default RegisterPage;
+```
+
+Теперь, если вы перейдете на [http://localhost:3000/register,](http://localhost:3000/register) вы сможете создать пользователя! Остальная часть приложения пока что на это не отреагирует, мы займемся этим в ближайшее время.
+
+Аналогичным образом мы можем реализовать страницу входа в систему. Попробуйте сами или просто возьмите код и двигайтесь дальше:
+
+```tsx title="pages/sign-in/api/sign-in.ts"
+import { json, type ActionFunctionArgs } from "@remix-run/node";
+
+import { POST, createUserSession } from "shared/api";
+
+export const signIn = async ({ request }: ActionFunctionArgs) => {
+ const formData = await request.formData();
+ const email = formData.get("email")?.toString() ?? "";
+ const password = formData.get("password")?.toString() ?? "";
+
+ const { data, error } = await POST("/users/login", {
+ body: { user: { email, password } },
+ });
+
+ if (error) {
+ return json({ error }, { status: 400 });
+ } else {
+ return createUserSession({
+ request: request,
+ user: data.user,
+ redirectTo: "/",
+ });
+ }
+};
+```
+
+```tsx title="pages/sign-in/ui/SignInPage.tsx"
+import { Form, Link, useActionData } from "@remix-run/react";
+
+import type { signIn } from "../api/sign-in";
+
+export function SignInPage() {
+ const signInData = useActionData
+
+
+
+
+
+ Sign up
++ Have an account? +
+ + {registerData?.error && ( +-
+ {registerData.error.errors.body.map((error) => (
+
- {error} + ))} +
+
+ );
+}
+```
+
+```tsx title="pages/sign-in/index.ts"
+export { RegisterPage } from './ui/RegisterPage';
+export { register } from './api/register';
+export { SignInPage } from './ui/SignInPage';
+export { signIn } from './api/sign-in';
+```
+
+```tsx title="app/routes/login.tsx"
+import { SignInPage, signIn } from "pages/sign-in";
+
+export { signIn as action };
+
+export default SignInPage;
+```
+
+Теперь давайте дадим пользователям возможность попасть на эти страницы.
+
+### Хэдер
+
+Как мы уже говорили в первой части, хэдер приложения обычно размещается либо в Widgets, либо в Shared. Мы поместим его в Shared, потому что он очень прост, и вся бизнес-логика может быть сохранена за его пределами. Давайте создадим для него место:
+
+```bash
+npx fsd shared ui
+```
+
+Теперь создайте `shared/ui/Header.tsx` со следующим содержимым:
+
+```tsx title="shared/ui/Header.tsx"
+import { useContext } from "react";
+import { Link, useLocation } from "@remix-run/react";
+
+import { CurrentUser } from "../api/currentUser";
+
+export function Header() {
+ const currentUser = useContext(CurrentUser);
+ const { pathname } = useLocation();
+
+ return (
+
+ );
+}
+```
+
+Экспортируйте этот компонент из `shared/ui`:
+
+```tsx title="shared/ui/index.ts"
+export { Header } from "./Header";
+```
+
+В хэдере мы полагаемся на контекст, расположенный в `shared/api`. Создайте ещё его:
+
+```tsx title="shared/api/currentUser.ts"
+import { createContext } from "react";
+
+import type { User } from "./models";
+
+export const CurrentUser = createContext
+
+
+
+
+
+ Sign in
++ Need an account? +
+ + {signInData?.error && ( +-
+ {signInData.error.errors.body.map((error) => (
+
- {error} + ))} +
+
+ );
+}
+```
+
+```tsx title="pages/feed/ui/Pagination.tsx"
+import { Form, useLoaderData, useSearchParams } from "@remix-run/react";
+import { ExistingSearchParams } from "remix-utils/existing-search-params";
+
+import { LIMIT, type loader } from "../api/loader";
+
+export function Pagination() {
+ const [searchParams] = useSearchParams();
+ const { articles } = useLoaderDataPopular Tags
+ + +
+
+ );
+}
+```
+
+Нам также нужно учесть новую вкладку в функции-загрузчике:
+
+```tsx title="pages/feed/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET, requireUser } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+ conduit
+A place to share your knowledge.
+
+
+
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+Этот код отправит POST-запрос на `/article/:slug` с `_action=favorite`, чтобы отметить статью как любимую. Пока это не работает, но как только мы начнем работать над читалкой статей, мы реализуем и это.
+
+И на этом мы официально закончили работу над фидом! Ура!
+
+### Читалка статей
+
+Во-первых, нам нужны данные. Давайте создадим загрузчик:
+
+```bash
+npx fsd pages article-read -s api
+```
+
+```tsx title="pages/article-read/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import invariant from "tiny-invariant";
+import type { FetchResponse } from "openapi-fetch";
+import { promiseHash } from "remix-utils/promise";
+
+import { GET, getUserFromSession } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+
+
+
+ {article.author.username}
+
+
+ {new Date(article.createdAt).toLocaleDateString(undefined, {
+ dateStyle: "long",
+ })}
+
+
+
+ {article.title}
+{article.description}
+ Read more... +-
+ {article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+
+ );
+}
+```
+
+Более интересными являются `ArticleMeta` и `Comments`. Они содержат операции записи, такие как лайкнуть статью, оставить комментарий и т. д. Чтобы они заработали, нам сначала нужно реализовать бэкенд-часть. Создайте файл `action.ts` в сегменте `api` этой страницы:
+
+```tsx title="pages/article-read/api/action.ts"
+import { redirect, type ActionFunctionArgs } from "@remix-run/node";
+import { namedAction } from "remix-utils/named-action";
+import { redirectBack } from "remix-utils/redirect-back";
+import invariant from "tiny-invariant";
+
+import { DELETE, POST, requireUser } from "shared/api";
+
+export const action = async ({ request, params }: ActionFunctionArgs) => {
+ const currentUser = await requireUser(request);
+
+ const authorization = { Authorization: `Token ${currentUser.token}` };
+
+ const formData = await request.formData();
+
+ return namedAction(formData, {
+ async delete() {
+ invariant(params.slug, "Expected a slug parameter");
+ await DELETE("/articles/{slug}", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirect("/");
+ },
+ async favorite() {
+ invariant(params.slug, "Expected a slug parameter");
+ await POST("/articles/{slug}/favorite", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async unfavorite() {
+ invariant(params.slug, "Expected a slug parameter");
+ await DELETE("/articles/{slug}/favorite", {
+ params: { path: { slug: params.slug } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async createComment() {
+ invariant(params.slug, "Expected a slug parameter");
+ const comment = formData.get("comment");
+ invariant(typeof comment === "string", "Expected a comment parameter");
+ await POST("/articles/{slug}/comments", {
+ params: { path: { slug: params.slug } },
+ headers: { ...authorization, "Content-Type": "application/json" },
+ body: { comment: { body: comment } },
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async deleteComment() {
+ invariant(params.slug, "Expected a slug parameter");
+ const commentId = formData.get("id");
+ invariant(typeof commentId === "string", "Expected an id parameter");
+ const commentIdNumeric = parseInt(commentId, 10);
+ invariant(
+ !Number.isNaN(commentIdNumeric),
+ "Expected a numeric id parameter",
+ );
+ await DELETE("/articles/{slug}/comments/{id}", {
+ params: { path: { slug: params.slug, id: commentIdNumeric } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async followAuthor() {
+ const authorUsername = formData.get("username");
+ invariant(
+ typeof authorUsername === "string",
+ "Expected a username parameter",
+ );
+ await POST("/profiles/{username}/follow", {
+ params: { path: { username: authorUsername } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ async unfollowAuthor() {
+ const authorUsername = formData.get("username");
+ invariant(
+ typeof authorUsername === "string",
+ "Expected a username parameter",
+ );
+ await DELETE("/profiles/{username}/follow", {
+ params: { path: { username: authorUsername } },
+ headers: authorization,
+ });
+ return redirectBack(request, { fallback: "/" });
+ },
+ });
+};
+```
+
+Реэкспортируйте её из слайса, а затем из маршрута. Пока мы здесь, давайте также подключим саму страницу:
+
+```tsx title="pages/article-read/index.ts"
+export { ArticleReadPage } from "./ui/ArticleReadPage";
+export { loader } from "./api/loader";
+export { action } from "./api/action";
+```
+
+```tsx title="app/routes/article.$slug.tsx"
+import { ArticleReadPage } from "pages/article-read";
+
+export { loader, action } from "pages/article-read";
+
+export default ArticleReadPage;
+```
+
+Теперь, несмотря на то, что мы еще не реализовали кнопку лайка в читалке, кнопка лайка в ленте начнет работать! Это потому, что она тоже отправляет запросы на этот маршрут. Попробуйте лайкнуть что-нибудь.
+
+`ArticleMeta` и `Comments` — это, опять же, просто формы. Мы уже делали это раньше, давайте возьмем их код и пойдем дальше:
+
+```tsx title="pages/article-read/ui/ArticleMeta.tsx"
+import { Form, Link, useLoaderData } from "@remix-run/react";
+import { useContext } from "react";
+
+import { CurrentUser } from "shared/api";
+import type { loader } from "../api/loader";
+
+export function ArticleMeta() {
+ const currentUser = useContext(CurrentUser);
+ const { article } = useLoaderData
+
+
+
+
+ {article.article.title}
+ +
+
+ +
+
+
+
+
+
+ {article.article.body}
+-
+ {article.article.tagList.map((tag) => (
+
- + {tag} + + ))} +
+ +
+
+
+
+
+
+ {currentUser !== null ? (
+
+ ) : (
+
+ );
+}
+```
+
+А вместе с этим и наша читалка статей! Кнопки "Подписаться на автора", "Мне нравится" и "Оставить комментарий" теперь должны работать как положено.
+
+
+
+ )}
+
+ {comments.comments.map((comment) => (
+
+
+ + Sign in + or + Sign up + to add comments on this article. +
+
+
+ ))}
+
+
+
+ {comment.body}
+
+
+
+
+
+
+ {comment.author.username}
+
+ {comment.createdAt}
+ {comment.author.username === currentUser?.username && (
+
+
+
+ )}
+
+
+
+ );
+}
+```
+
+Эта страница получает текущую статью (если мы пишем статью не с нуля) и заполняет соответствующие поля формы. Мы уже видели это. Интересной частью является `FormErrors`, потому что он будет получать результат проверки и отображать его пользователю. Давайте посмотрим:
+
+```tsx title="pages/article-edit/ui/FormErrors.tsx"
+import { useActionData } from "@remix-run/react";
+import type { action } from "../api/action";
+
+export function FormErrors() {
+ const actionData = useActionData
+
+
+
+
+
+ -
+ {actionData.errors.map((error) => (
+
- {error} + ))} +
+ {tagListState.map((tag) => (
+
+
+ [" ", "Enter"].includes(e.key) && removeTag(tag)
+ }
+ onClick={() => removeTag(tag)}
+ >{" "}
+ {tag}
+
+ ))}
+
+
+ );
+}
+```
+
+Теперь перейдем к API-части. Загрузчик должен посмотреть на URL, и если в нем есть ссылка на статью, это означает, что мы редактируем существующую статью, и ее данные должны быть загружены. В противном случае ничего не возвращается. Давайте создадим этот загрузчик:
+
+```tsx title="pages/article-edit/api/loader.ts"
+import { json, type LoaderFunctionArgs } from "@remix-run/node";
+import type { FetchResponse } from "openapi-fetch";
+
+import { GET, requireUser } from "shared/api";
+
+async function throwAnyErrors
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+```ts title="shared/ui/layout/useThemeSwitcher.ts"
+export function useThemeSwitcher() {
+ const [theme, setTheme] = useState("light");
+
+ function toggleTheme() {
+ setTheme(theme === "light" ? "dark" : "light");
+ }
+
+ useEffect(() => {
+ document.body.classList.remove("light", "dark");
+ document.body.classList.add(theme);
+ }, [theme]);
+
+ return [theme, toggleTheme] as const;
+}
+```
+
+Код сайдбаров оставлен читателю в качестве упражнения 😉.
+
+## Использование виджетов в лейауте
+
+Иногда есть необходимость включить в лейаут определенную бизнес-логику, особенно если вы используете глубоко вложенные маршруты с роутером типа [React Router][ext-react-router]. Тогда вы не можете хранить лейаут в Shared или в Widgets из-за [правила импорта для слоёв][import-rule-on-layers]:
+
+> Модуль в слайсе может импортировать другие слайсы только в том случае, если они расположены на слоях строго ниже.
+
+Прежде чем обсуждать решения, нам нужно обсудить, действительно ли это проблема. Вам _действительно нужен_ этот лейаут, и если да, _действительно ли_ он должен быть виджетом? Если блок бизнес-логики, про который идёт речь, используется на 2-3 страницах, и лейаут просто является небольшой обёрткой для этого виджета, рассмотрите один из этих двух вариантов:
+
+1. **Напишите ваш лейаут прямо в коде роутера на уровне App**
+ Это отлично подходит для роутеров, поддерживающих вложенность, потому что вы можете группировать определенные маршруты и применять нужный лейаут только к ним.
+
+2. **Просто скопируйте его**
+ Желание абстрагировать код часто переоценено. Это особенно верно для лейаутов, потому что они редко меняются. В какой-то момент, если одна из этих страниц потребует изменений, вы можете просто внести изменения, не затрагивая другие страницы. Если вы беспокоитесь, что кто-то может забыть обновить другие страницы, всегда можно оставить комментарий, описывающий отношения между страницами.
+
+Если ни один из вышеперечисленных вариантов не подходит, есть два решения для включения виджета в лейаут:
+
+1. **Используйте render props или слоты**
+ Большинство фреймворков позволяют передавать часть UI внешне. В React это называется [render props][ext-render-props], в Vue — [слоты][ext-vue-slots].
+
+2. **Переместите лейаут на уровень App**
+ Вы также можете хранить свой лейаут на уровне App, например, в `app/layouts`, и комбинировать любые виджеты, которые вам нужны.
+
+## Дополнительные материалы
+
+- Пример создания лейаута с аутентификацией с помощью React и Remix (аналогичен React Router) можно найти в [туториале][tutorial].
+
+[tutorial]: /docs/get-started/tutorial
+[import-rule-on-layers]: /docs/reference/layers#import-rule-on-layers
+[ext-react-router]: https://reactrouter.com/
+[ext-render-props]: https://www.patterns.dev/react/render-props-pattern/
+[ext-vue-slots]: https://ru.vuejs.org/guide/components/slots
diff --git a/src/content/docs/ru/docs/guides/examples/types.mdx b/src/content/docs/ru/docs/guides/examples/types.mdx
new file mode 100644
index 0000000000..43e5a88c0c
--- /dev/null
+++ b/src/content/docs/ru/docs/guides/examples/types.mdx
@@ -0,0 +1,441 @@
+---
+title: Типы
+sidebar:
+ order: 2
+---
+
+import { FileTree } from '@astrojs/starlight/components';
+import { Aside } from '@astrojs/starlight/components';
+
+В этом руководстве рассматриваются типы данных из типизированных языков, таких как TypeScript, и где они вписываются в FSD.
+
+
+
+## Типы-утилиты
+
+Типы-утилиты — это типы, которые сами по себе не имеют особого смысла и обычно используются с другими типами. Например:
+
+