snapshot of https://github.com/twentyhq/twenty.git (main, 2026-09-17; blobs > 131072B omitted)

packages/twenty-docs/l/ja/developers/contribute/capabilities/frontend-development/best-practices-front.mdx

@@ -0,0 +1,329 @@
+---
+title: ベストプラクティス',
+icon: star
+---
+
+このドキュメントでは、フロントエンド作業におけるベストプラクティスを概要化しています。
+
+## 状態管理
+
+React と Jotai はコードベース内の状態管理を行います。
+
+### Jotai の atom を使用して状態を保存する
+
+状態を保存するために必要なだけ多くのアトムを作成するのがよいです。
+
+<Warning>
+
+プロップドリリングを必要以上に控えるより、追加のアトムを使用する方が良いです。
+
+</Warning>
+
+```tsx
+import { createAtomState } from '@/ui/utilities/state/jotai/utils/createAtomState';
+import { useAtomState } from '@/ui/utilities/state/jotai/hooks/useAtomState';
+
+export const myAtomState = createAtomState<string>({
+  key: 'myAtomState',
+  defaultValue: 'default value',
+});
+
+export const MyComponent = () => {
+  const [myAtom, setMyAtom] = useAtomState(myAtomState);
+
+  return (
+    <div>
+      <input
+        value={myAtom}
+        onChange={(e) => setMyAtom(e.target.value)}
+      />
+    </div>
+  );
+}
+```
+
+### 状態を保存するために `useRef` を使用しないでください
+
+状態の保存に `useRef` を使用するのは避けてください。
+
+状態を保存したい場合は、`useState` または `useAtomState` を用いた Jotai の atom を使用してください。
+
+いくつかの再レンダリングを防ぐために `useRef` が必要だと感じた場合は、[再レンダリングの管理方法](#managing-re-renders)を参照してください。
+
+## 再レンダリングの管理
+
+React で再レンダリングを管理するのは難しいことがあります。
+
+不必要な再レンダリングを避けるためのいくつかのルールをご紹介します。
+
+再レンダリングの原因を理解することで、常に再レンダリングを避けることができることを念頭に置いてください。
+
+### ルートレベルで作業する
+
+新機能での再レンダリングをルートレベルで排除することで、簡単に避けることができるようになりました。
+
+`PageChangeEffect` サイドカーコンポーネントには、ページ変更時に実行するすべてのロジックを保持する `useEffect` が1つだけ含まれています。
+
+その方法で、再レンダリングを引き起こす場所が 1 つだけあることを認識できます。
+
+### コードベースに `useEffect` を追加する前に、常に考えてください。
+
+再レンダリングは、しばしば不要な `useEffect` によって引き起こされます。
+
+`useEffect` が必要か、イベントハンドラ関数でロジックを動かせるか考えるべきです。
+
+「handleClick」関数や「handleChange」関数の中で、ロジックを簡単に動かすことができます。
+
+Apollo などのライブラリで `onCompleted`、`onError` などとしても見つかることがあります。
+
+### 兄弟コンポーネントを使用して、`useEffect` またはデータ取得ロジックを抽出します。
+
+ルートコンポーネントに `useEffect` を追加する必要があると思われる場合は、サイドカーコンポーネント内で展開することを検討する必要があります。
+
+Apollo フックを使用してデータ取得ロジックにも同じことを適用できます。
+
+```tsx
+// ❌ Bad, will cause re-renders even if data is not changing,
+//    because useEffect needs to be re-evaluated
+export const PageComponent = () => {
+  const [data, setData] = useAtomState(dataState);
+  const [someDependency] = useAtomState(someDependencyState);
+
+  useEffect(() => {
+    if(someDependency !== data) {
+      setData(someDependency);
+    }
+  }, [someDependency]);
+
+  return <div>{data}</div>;
+};
+
+export const App = () => (
+  <PageComponent />
+);
+```
+
+```tsx
+// ✅ Good, will not cause re-renders if data is not changing,
+//   because useEffect is re-evaluated in another sibling component
+export const PageComponent = () => {
+  const [data, setData] = useAtomState(dataState);
+
+  return <div>{data}</div>;
+};
+
+export const PageData = () => {
+  const [data, setData] = useAtomState(dataState);
+  const [someDependency] = useAtomState(someDependencyState);
+
+  useEffect(() => {
+    if(someDependency !== data) {
+      setData(someDependency);
+    }
+  }, [someDependency]);
+
+  return <></>;
+};
+
+export const App = () => (
+  <>
+    <PageData />
+    <PageComponent />
+  </>
+);
+```
+
+### atom ファミリー状態とセレクターを使用する
+
+atom ファミリー状態とセレクターは、再レンダリングを回避するための優れた方法です。
+
+アイテムのリストを保存する必要があるときに有用です。
+
+### `React.memo(MyComponent)` を使用してはいけません
+
+`React.memo()` の使用を避けてください。それは再レンダリングの原因を解決するのではなく、再レンダリングの連鎖を破り、予期しない動作を引き起こす可能性があり、コードのリファクタリングが非常に困難になります。
+
+### `useCallback` または `useMemo` の使用を制限する
+
+それらは通常必要ではなく、気付かない程度のパフォーマンス向上のためにコードの可読性と保守性を低下させます。
+
+## コンソールログ
+
+`console.log` は開発中において、変数の値やコードの流れについてリアルタイムの洞察を提供するために有効です。 しかし、これをプロダクションコードに残すと、いくつかの問題を引き起こす可能性があります。 しかし、これをプロダクションコードに残すと、いくつかの問題を引き起こす可能性があります。
+
+1. **パフォーマンス**: 過剰なログはクライアントサイドアプリケーションのランタイムパフォーマンスに影響を与える可能性があります。
+
+2. **セキュリティ**: センシティブなデータをログに記録すると、ブラウザのコンソールを確認するだけで重要な情報が露見する恐れがあります。
+
+3. **清潔性**: コンソールにログが溢れると、開発者やツールが見るべき重要な警告やエラーが不明瞭になる可能性があります。
+
+4. **プロフェッショナリズム**: エンドユーザーやクライアントがコンソールを確認したときに、多くのログが表示されると、そのコードの品質や仕上がりを疑問視されることがあります。
+
+`console.logs` はすべて削除してからコードをプロダクションにプッシュしてください。
+
+## 命名について
+
+### 変数の命名
+
+変数名は、その変数の目的や機能を正確に描写する必要があります。
+
+#### 汎用的な名前の問題
+
+プログラミングにおいて汎用的な名前は理想的ではありません。なぜなら、それらは特異性に欠け、曖昧さをもたらし、コードの可読性を低下させるからです。 そのような名前は変数や関数の目的を伝えず、開発者がコードの意図を深く探らない限り理解を困難にします。 これにより、デバッグ時間が増加し、エラーの発生率が高まり、メンテナンスやコラボレーションが難しくなります。 一方で、説明的な命名はコードを自己説明的にし、ナビゲートしやすくし、コードの品質と開発者の生産性を向上させます。
+
+```tsx
+// ❌ Bad, uses a generic name that doesn't communicate its
+//    purpose or content clearly
+const [value, setValue] = useState('');
+```
+
+```tsx
+// ✅ Good, uses a descriptive name
+const [email, setEmail] = useState('');
+```
+
+#### 変数名で避けるべき言葉のいくつか
+
+* ダミー
+
+### イベントハンドラー
+
+イベントハンドラの名前は `handle` で始めるべきであり、`on` はコンポーネントのプロップ内のイベントを命名するためのプレフィックスとして使用されます。
+
+```tsx
+// ❌ Bad
+const onEmailChange = (val: string) => {
+  // ...
+};
+```
+
+```tsx
+// ✅ Good
+const handleEmailChange = (val: string) => {
+  // ...
+};
+```
+
+## オプショナルプロップ
+
+オプショナルプロップにデフォルト値を渡すことは避けてください。
+
+**例**
+
+以下に定義された `EmailField` コンポーネントを取る:
+
+```tsx
+type EmailFieldProps = {
+  value: string;
+  disabled?: boolean;
+};
+
+const EmailField = ({ value, disabled = false }: EmailFieldProps) => (
+  <TextInput value={value} disabled={disabled} fullWidth />
+);
+```
+
+**使用方法**
+
+```tsx
+// ❌ Bad, passing in the same value as the default value adds no value
+const Form = () => <EmailField value="username@email.com" disabled={false} />;
+```
+
+```tsx
+// ✅ Good, assumes the default value
+const Form = () => <EmailField value="username@email.com" />;
+```
+
+## プロップとしてのコンポーネント
+
+可能な限り、未初期化のコンポーネントをプロップとして渡してください。子コンポーネントが必要なプロップを自分で決定できるようにします。
+
+そのための最も一般的な例はアイコンコンポーネントです。
+
+```tsx
+const SomeParentComponent = () => <MyComponent Icon={MyIcon} />;
+
+// In MyComponent
+const MyComponent = ({ MyIcon }: { MyIcon: IconComponent }) => {
+  const theme = useTheme();
+
+  return (
+    <div>
+      <MyIcon size={theme.icon.size.md}>
+    </div>
+  )
+};
+```
+
+Reactがコンポーネントを認識するためには、PascalCaseを使用し、その後に`<MyIcon>`でインスタンス化する必要があります。
+
+## プロップのドリリングを最小限に抑える
+
+Reactのコンテキストでのプロップドリリングとは、多くのコンポーネントレイヤーを通じて状態変数やそのセットを渡すことを意味します。中間のコンポーネントがそれを使用していない場合であってもです。 時には必要ですが、過度のプロップドリリングは次の結果を導きかねません。 時には必要ですが、過度のプロップドリリングは次の結果を導きかねません。 時には必要ですが、過度のプロップドリリングは次の結果を導きかねません。
+
+1. **可読性の低下**：プロップがどこから始まり、どこで使われているかを追跡するのが、深くネストされたコンポーネント構造では複雑になり得ます。
+
+2. **メンテナンスの難しさ**：あるコンポーネントのプロップ構造に変更があると、他のコンポーネントに変更が必要になる場合があります。それが直接プロップを使用していなくても。
+
+3. **コンポーネントの再利用性の低下**：多くのプロップを単に下位に渡すコンポーネントは、汎用性が低くなり、異なるコンテキストでの再利用が難しくなります。
+
+もし過度のプロップドリリングをしていると感じた場合は、[状態管理のベストプラクティス](#state-management)を参照してください。
+
+## インポート
+
+インポート時は、完全なパスや相対パスを指定するのではなく、指定されたエイリアスを選択してください。
+
+**ハンドルの別名**
+
+```js
+{
+  alias: {
+    "~": path.resolve(__dirname, "src"),
+    "@": path.resolve(__dirname, "src/modules"),
+    "@testing": path.resolve(__dirname, "src/testing"),
+  },
+}
+```
+
+**使用方法**
+
+```tsx
+// ❌ Bad, specifies the entire relative path
+import {
+  CatalogDecorator
+} from '../../../../../testing/decorators/CatalogDecorator';
+import {
+  ComponentDecorator
+} from '../../../../../testing/decorators/ComponentDecorator';
+```
+
+```tsx
+// ✅ Good, utilises the designated aliases
+import { CatalogDecorator } from '~/testing/decorators/CatalogDecorator';
+import { ComponentDecorator } from 'twenty-ui/testing';
+```
+
+## スキーマ検証
+
+[Zod](https://github.com/colinhacks/zod)は型未定義オブジェクトのスキーマバリデーターです。
+
+```js
+const validationSchema = z
+  .object({
+    exist: z.boolean(),
+    email: z
+      .string()
+      .email('Email must be a valid email'),
+    password: z
+      .string()
+      .regex(PASSWORD_REGEX, 'Password must contain at least 8 characters'),
+  })
+  .required();
+
+type Form = z.infer<typeof validationSchema>;
+```
+
+## 重大な変更
+
+変更が他の部分に影響を及ぼしていないことを確実にするために、進む前に徹底的な手動テストを行ってください。テストがまだ広範囲に統合されていないためです。

packages/twenty-docs/l/ja/developers/contribute/capabilities/frontend-development/folder-architecture-front.mdx

@@ -0,0 +1,110 @@
+---
+title: フォルダ構成
+icon: folder-tree
+info: 当社のフォルダ構造の詳細な解説
+---
+
+このガイドでは、プロジェクトのディレクトリ構成の詳細と、それが Twenty の整理と保守性にどのように寄与するかを解説します。
+
+このフォルダ構成の規約に従うことで、特定の機能に関連するファイルを見つけやすくなり、アプリケーションのスケーラビリティと保守性を確保できます。
+
+```
+front
+└───modules
+│   └───module1
+│   │   └───submodule1
+│   └───module2
+│   └───ui
+│   │   └───display
+│   │   └───inputs
+│   │   │   └───buttons
+│   │   └───...
+└───pages
+└───...
+```
+
+## ページ
+
+アプリケーションのルートで定義されたトップレベルのコンポーネントを含みます。 それらは、modules フォルダからより低レベルのコンポーネントをインポートします（詳細は下記を参照）。
+
+## モジュール
+
+各モジュールは、単一の機能または機能のグループを表し、それぞれ固有のコンポーネント、状態、動作ロジックで構成されています。
+以下の構造に従う必要があります。 モジュール内にモジュール（サブモジュール）をネストでき、同じルールが適用されます。
+
+```
+module1
+  └───components
+  │   └───component1
+  │   └───component2
+  └───constants
+  └───contexts
+  └───graphql
+  │   └───fragments
+  │   └───queries
+  │   └───mutations
+  └───hooks
+  │   └───internal
+  └───states
+  │   └───selectors
+  └───types
+  └───utils
+```
+
+### コンテキスト
+
+コンテキストは、各レベルでプロップスを手動で渡すことなく、コンポーネントツリーを通じてデータを渡す方法です。
+
+詳細は[Reactコンテキスト](https://react.dev/reference/react#context-hooks)を参照してください。
+
+### GraphQL
+
+フラグメント、クエリ、ミューテーションを含みます。
+
+詳細は[GraphQL](https://graphql.org/learn/)を参照してください。
+
+* フラグメント
+
+フラグメントはクエリの再利用可能な一部分で、さまざまな箇所で使用できます。 フラグメントを使用することで、コードを重複させることを避けやすくなります。
+
+詳細は[GraphQLフラグメント](https://graphql.org/learn/queries/#fragments)を参照してください。
+
+* クエリ
+
+詳細は[GraphQLクエリ](https://graphql.org/learn/queries/)を参照してください。
+
+* ミューテーション
+
+詳細は[GraphQLミューテーション](https://graphql.org/learn/queries/#mutations)を参照してください。
+
+### フック
+
+詳細は[フック](https://react.dev/learn/reusing-logic-with-custom-hooks)を参照してください。
+
+### ステート
+
+ステート管理のロジックを含みます。 [Jotai](https://jotai.org) がこれを管理します。
+
+* セレクター: 派生アトム（`createAtomSelector` を使用）は、他のアトムから値を計算し、自動的にメモ化されます。
+
+Reactの組み込みステート管理は依然としてコンポーネント内のステートを処理します。
+
+### ユーティリティ
+
+再利用可能な純粋関数のみを含むべきです。 それ以外の場合は、`hooks`フォルダにカスタムフックを作成します。
+
+## UI
+
+アプリケーションで使用される再利用可能なUIコンポーネントをすべて含みます。
+
+このフォルダには、特定の種類のコンポーネント用に `data`、`display`、`feedback`、`input` といったサブフォルダを含めることができます。 各コンポーネントは自己完結型で再利用可能でなければならず、アプリケーションのさまざまな部分で使用できます。
+
+UIコンポーネントを`modules`フォルダ内の他のコンポーネントから分離することで、一貫したデザインを維持し、UIの変更がコードベースの他の部分（ビジネスロジック）に影響を与えないようにするのが容易になります。
+
+## インターフェースと依存関係
+
+`ui` フォルダを除く任意のモジュールから、他のモジュールのコードをインポートできます。 これにより、そのコードは簡単にテストできます。
+
+### 内部
+
+各部分（フック、ステート、...） は、モジュール内でのみ使用される部分を含む `internal` フォルダを持つことができます。

packages/twenty-docs/l/ja/developers/contribute/capabilities/frontend-development/frontend-commands.mdx

@@ -0,0 +1,91 @@
+---
+title: フロントエンドコマンド
+icon: terminal
+---
+
+## 便利なコマンド
+
+### アプリの開始
+
+```bash
+npx nx start twenty-front
+```
+
+### APIのGraphQLスキーマに基づいてGraphQLスキーマを再生成する
+
+```bash
+npx nx run twenty-front:graphql:generate --configuration=metadata
+```
+
+または
+
+```bash
+npx nx run twenty-front:graphql:generate
+```
+
+### リント
+
+```bash
+npx nx run twenty-front:lint # pass --fix to fix lint errors
+```
+
+## 翻訳
+
+```bash
+npx nx run twenty-front:lingui:extract
+npx nx run twenty-front:lingui:compile
+```
+
+### テスト
+
+```bash
+npx nx run twenty-front:test # run jest tests
+npx nx run twenty-front:storybook:serve:dev # run storybook
+npx nx run twenty-front:storybook:test # run tests # (needs yarn storybook:serve:dev to be running)
+npx nx run twenty-front:storybook:coverage # (needs yarn storybook:serve:dev to be running)
+```
+
+## 技術スタック
+
+プロジェクトは、最小限のボイラープレートコードを持つシンプルでクリーンなスタックを持っています。
+
+**アプリ**
+
+* [React](https://react.dev/)
+* [Apollo](https://www.apollographql.com/docs/)
+* [GraphQL Codegen](https://the-guild.dev/graphql/codegen)
+* [Jotai](https://jotai.org/)
+* [TypeScript](https://www.typescriptlang.org/)
+
+**テスト**
+
+* [Jest](https://jestjs.io/)
+* [Storybook](https://storybook.js.org/)
+
+**ツール**
+
+* [Yarn](https://yarnpkg.com/)
+* [Craco](https://craco.js.org/docs/)
+* [Oxlint](https://oxc.rs/docs/guide/usage/linter.html)
+
+## アーキテクチャ
+
+### ルーティング
+
+[React Router](https://reactrouter.com/)はルーティングを処理します。
+
+不要な [re-renders](/l/ja/developers/contribute/capabilities/frontend-development/best-practices-front#managing-re-renders) を避けるために、すべてのルーティングロジックは `PageChangeEffect` の `useEffect` にあります。
+
+### 状態管理
+
+[Jotai](https://jotai.org/)は状態管理を行います。
+
+状態管理に関する詳細な情報は[ベストプラクティス](/l/ja/developers/contribute/capabilities/frontend-development/best-practices-front#state-management)を参照してください。
+
+## テスト
+
+[Jest](https://jestjs.io/)はユニットテストのツールであり、[Storybook](https://storybook.js.org/)はコンポーネントテスト用です。
+
+Jestは主にユーティリティ関数のテスト用で、コンポーネントのテスト自体ではありません。
+
+Storybookは、独立したコンポーネントの挙動をテストし、デザインシステムを表示するためのものです。

packages/twenty-docs/l/ja/developers/contribute/capabilities/frontend-development/hotkeys.mdx

@@ -0,0 +1,178 @@
+---
+title: ホットキー
+---
+
+## イントロダクション
+
+ホットキーをリッスンする必要がある場合、通常は `onKeyDown` イベントリスナーを使用します。
+
+しかし、`twenty-front` では、同時にマウントされている異なるコンポーネントで使用される同じホットキーの間で競合が生じることがあります。
+
+例えば、Enterキーをリッスンするページと、Enterキーをリッスンするモーダル、さらにそのモーダル内のSelectコンポーネントもEnterキーをリッスンしている場合、全てが同時にマウントされると競合が生じる可能性があります。
+
+## `useScopedHotkeys` フック
+
+この問題を解決するために、どのような競合もなくホットキーをリッスンすることを可能にするカスタムフックがあります。
+
+コンポーネント内に配置すると、コンポーネントがマウントされ、指定された**ホットキースコープ**がアクティブなときだけホットキーをリッスンします。
+
+## 実際にホットキーをリッスンする方法は？
+
+ホットキーをリッスンするための設定には2つのステップがあります：
+
+1. ホットキーをリッスンする[ホットキースコープ](#what-is-a-hotkey-scope-)を設定します
+2. ホットキーをリッスンするために `useScopedHotkeys` フックを使用します
+
+他のUI要素（例：左側のメニューやコマンドメニュー）もホットキーをリッスンする可能性があるため、ホットキースコープの設定は単純なページでも必要です。
+
+## ホットキーのユースケース
+
+一般的に、ホットキーが必要となる動作は2つあります：
+
+1. ページにマウントされたコンポーネントで
+2. ユーザーのアクションでフォーカスをとるモーダルタイプのコンポーネントで
+
+2番目のユースケースは再帰的に発生します：例えばモーダル内のドロップダウン。
+
+### ページ内でホットキーをリッスン
+
+例：
+
+```tsx
+const PageListeningEnter = () => {
+  const {
+    setHotkeyScopeAndMemorizePreviousScope,
+    goBackToPreviousHotkeyScope,
+  } = usePreviousHotkeyScope();
+
+  // 1. Set the hotkey scope in a useEffect
+  useEffect(() => {
+    setHotkeyScopeAndMemorizePreviousScope(
+      ExampleHotkeyScopes.ExampleEnterPage,
+    );
+
+    // Revert to the previous hotkey scope when the component is unmounted
+    return () => {
+      goBackToPreviousHotkeyScope();
+    };
+  }, [goBackToPreviousHotkeyScope, setHotkeyScopeAndMemorizePreviousScope]);
+
+  // 2. Use the useScopedHotkeys hook
+  useScopedHotkeys(
+    Key.Enter,
+    () => {
+      // Some logic executed on this page when the user presses Enter
+      // ...
+    },
+    ExampleHotkeyScopes.ExampleEnterPage,
+  );
+
+  return <div>My page that listens for Enter</div>;
+};
+```
+
+### モーダルタイプのコンポーネントでホットキーをリッスン
+
+この例では、親にモーダルを閉じるように指示するためにEscapeキーをリッスンするモーダルコンポーネントを使用します。
+
+ここで、ユーザーの操作がスコープを変更します。
+
+```tsx
+const ExamplePageWithModal = () => {
+  const [showModal, setShowModal] = useState(false);
+
+  const {
+    setHotkeyScopeAndMemorizePreviousScope,
+    goBackToPreviousHotkeyScope,
+  } = usePreviousHotkeyScope();
+
+  const handleOpenModalClick = () => {
+    // 1. Set the hotkey scope when user opens the modal
+    setShowModal(true);
+    setHotkeyScopeAndMemorizePreviousScope(
+      ExampleHotkeyScopes.ExampleModal,
+    );
+  };
+
+  const handleModalClose = () => {
+    // 1. Revert to the previous hotkey scope when the modal is closed
+    setShowModal(false);
+    goBackToPreviousHotkeyScope();
+  };
+
+  return <div>
+    <h1>My page with a modal</h1>
+    <button onClick={handleOpenModalClick}>Open modal</button>
+    {showModal && <MyModalComponent onClose={handleModalClose} />}
+  </div>;
+};
+```
+
+その後、モーダルコンポーネント内で：
+
+```tsx
+const MyDropdownComponent = ({ onClose }: { onClose: () => void }) => {
+  // 2. Use the useScopedHotkeys hook to listen for Escape.
+  // Note that escape is a common hotkey that could be used by many other components
+  // So it's important to use a hotkey scope to avoid conflicts
+  useScopedHotkeys(
+    Key.Escape,
+    () => {
+      onClose()
+    },
+    ExampleHotkeyScopes.ExampleModal,
+  );
+
+  return <div>My modal component</div>;
+};
+```
+
+mount/unmount で useEffect を使うだけで、競合を避けるのに十分なことがわからない場合は、このパターンを使用することが重要です。
+
+これらの競合はデバッグが難しく、useEffectsを使わないよりも頻繁に発生する可能性があります。
+
+## ホットキースコープとは？
+
+ホットキースコープは、ホットキーがアクティブなコンテキストを表す文字列です。 通常、enumとしてエンコードされます。 通常、enumとしてエンコードされます。 通常、enumとしてエンコードされます。
+
+ホットキースコープを変更すると、このスコープをリッスンしているホットキーが有効になり、他のスコープをリッスンしているホットキーが無効になります。
+
+一度に1つのスコープしか設定できません。
+
+例として、各ページのホットキースコープは`PageHotkeyScope` enumで定義されています：
+
+```tsx
+export enum PageHotkeyScope {
+  Settings = 'settings',
+  CreateWorkspace = 'create-workspace',
+  SignInUp = 'sign-in-up',
+  CreateProfile = 'create-profile',
+  PlanRequired = 'plan-required',
+  ShowPage = 'show-page',
+  PersonShowPage = 'person-show-page',
+  CompanyShowPage = 'company-show-page',
+  CompaniesPage = 'companies-page',
+  PeoplePage = 'people-page',
+  OpportunitiesPage = 'opportunities-page',
+  ProfilePage = 'profile-page',
+  WorkspaceMemberPage = 'workspace-member-page',
+  TaskPage = 'task-page',
+}
+```
+
+内部的には、現在選択されているスコープはアプリケーション全体で共有されるJotai atomに格納されています：
+
+```tsx
+export const currentHotkeyScopeState = createState<HotkeyScope>({
+  key: 'currentHotkeyScopeState',
+  defaultValue: INITIAL_HOTKEYS_SCOPE,
+});
+```
+
+しかし、このatomは手動で扱ってはいけません！ 次のセクションでその使用方法を見ていきます。
+
+## 内部的にはどう機能しているのか？
+
+[react-hotkeys-hook](https://react-hotkeys-hook.vercel.app/docs/intro)の上に薄いラッパーを作成し、より効率的にし、不必要な再レンダリングを避けます。
+
+また、ホットキーのスコープの状態を処理し、アプリケーション全体で利用できるようにするためのJotai atomも作成します。

packages/twenty-docs/l/ja/developers/contribute/capabilities/frontend-development/storybook.mdx

@@ -0,0 +1,8 @@
+---
+title: ストーリーブック
+description: TwentyのUIコンポーネントライブラリを閲覧
+---
+
+ストーリーブックで私たちの完全なコンポーネントライブラリおよびドキュメントを参照してください。
+
+[ストーリーブックを開く →](https://storybook.twenty.com)

packages/twenty-docs/l/ja/developers/contribute/capabilities/frontend-development/style-guide.mdx

@@ -0,0 +1,291 @@
+---
+title: スタイルガイド
+icon: paintbrush
+---
+
+このドキュメントには、コードを書く際に従うべきルールが含まれています。
+
+ここでの目標は、一貫性があり、読みやすく、メンテナンスしやすいコードベースにすることです。
+
+そのためには、簡潔すぎるよりも少し冗長な方が良いです。
+
+常に念頭に置いておくべきなのは、コードは書くよりも読む機会の方が多いということです。特に、誰でも貢献できるオープンソースプロジェクトでは、その傾向が強くなります。
+
+ここでは定義されていない、多くの規則がありますが、リンターにより自動的にチェックされます。
+
+## React
+
+### 関数コンポーネントを使用する
+
+常にTSXの関数コンポーネントを使用してください。
+
+`const`を使ったデフォルトの`import`は避けてください。読むことや、コード補完でのインポートが難しくなるからです。
+
+```tsx
+// ❌ Bad, harder to read, harder to import with code completion
+const MyComponent = () => {
+  return <div>Hello World</div>;
+};
+
+export default MyComponent;
+
+// ✅ Good, easy to read, easy to import with code completion
+export function MyComponent() {
+  return <div>Hello World</div>;
+};
+```
+
+### プロパティ
+
+プロップスの型を作成し、エクスポートの必要がない場合にはそれを`(ComponentName)Props`と呼んでください。
+
+プロップスの分割代入を使用する。
+
+```tsx
+// ❌ Bad, no type
+export const MyComponent = (props) => <div>Hello {props.name}</div>;
+
+// ✅ Good, type
+type MyComponentProps = {
+  name: string;
+};
+
+export const MyComponent = ({ name }: MyComponentProps) => <div>Hello {name}</div>;
+```
+
+#### プロップス型の定義に`React.FC`または`React.FunctionComponent`を使用しない
+
+```tsx
+/* ❌ - Bad, defines the component type annotations with `FC`
+ *    - With `React.FC`, the component implicitly accepts a `children` prop
+ *      even if it's not defined in the prop type. This might not always be
+ *      desirable, especially if the component doesn't intend to render
+ *      children.
+ */
+const EmailField: React.FC<{
+  value: string;
+}> = ({ value }) => <TextInput value={value} disabled fullWidth />;
+```
+
+```tsx
+/* ✅ - Good, a separate type (OwnProps) is explicitly defined for the
+ *      component's props
+ *    - This method doesn't automatically include the children prop. If
+ *      you want to include it, you have to specify it in OwnProps.
+ */
+type EmailFieldProps = {
+  value: string;
+};
+
+const EmailField = ({ value }: EmailFieldProps) => (
+  <TextInput value={value} disabled fullWidth />
+);
+```
+
+#### JSX要素内で単一の変数プロップスプレーディングを使用しない
+
+`{...props}`のようにJSX要素内で単一の変数プロップスプレーディングを避けてください。 この方法は、コンポーネントが受け取るプロップスを不明確にするため、コードの可読性が低下し、メンテナンスが困難になります。 この方法は、コンポーネントが受け取るプロップスを不明確にするため、コードの可読性が低下し、メンテナンスが困難になります。 この方法は、コンポーネントが受け取るプロップスを不明確にするため、コードの可読性が低下し、メンテナンスが困難になります。
+
+```tsx
+/* ❌ - Bad, spreads a single variable prop into the underlying component
+ */
+const MyComponent = (props: OwnProps) => {
+  return <OtherComponent {...props} />;
+}
+```
+
+```tsx
+/* ✅ - Good, Explicitly lists all props
+ *    - Enhances readability and maintainability
+ */
+const MyComponent = ({ prop1, prop2, prop3 }: MyComponentProps) => {
+  return <OtherComponent {...{ prop1, prop2, prop3 }} />;
+};
+```
+
+根拠:
+
+* ひと目で、コードがどのプロップスを渡しているかが明確になり、理解とメンテナンスが容易になります。
+* これにより、コンポーネント間のプロップスによる密結合を防ぐのに役立ちます。
+* プロップスを明示的にリストすれば、lintingツールが綴り間違いや未使用のプロップスを特定しやすくなります。
+
+## JavaScript
+
+### `??`（ヌリッシュ合体演算子）を使う
+
+```tsx
+// ❌ Bad, can return 'default' even if value is 0 or ''
+const value = process.env.MY_VALUE || 'default';
+
+// ✅ Good, will return 'default' only if value is null or undefined
+const value = process.env.MY_VALUE ?? 'default';
+```
+
+### `?.`（オプショナルチェイニング）を使う
+
+```tsx
+// ❌ Bad
+onClick && onClick();
+
+// ✅ Good
+onClick?.();
+```
+
+## TypeScript
+
+### `type`を使い、常に`interface`の代わりにする
+
+`type`は多くの場合、`interface`と重複し、`type`の方が柔軟性が高いため、常に`type`を使用してください。
+
+```tsx
+// ❌ Bad
+interface MyInterface {
+  name: string;
+}
+
+// ✅ Good
+type MyType = {
+  name: string;
+};
+```
+
+### 列挙型の代わりに文字列リテラルを使う
+
+[文字列リテラル](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types) は、TypeScriptで列挙型のような値を扱うための推奨方法です。 それらはPickやOmitで拡張するのが簡単で、特にコード補完を伴う開発者の体験を向上させます。 それらはPickやOmitで拡張するのが簡単で、特にコード補完を伴う開発者の体験を向上させます。 Pick や Omit で拡張しやすく、特にコード補完の面で、より良い開発者体験を提供します。
+
+なぜTypeScriptが列挙型を避けることを推奨しているかは[ここ](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#enums)をご覧ください。
+
+```tsx
+// ❌ Bad, utilizes an enum
+enum Color {
+  Red = "red",
+  Green = "green",
+  Blue = "blue",
+}
+
+let color = Color.Red;
+```
+
+```tsx
+// ✅ Good, utilizes a string literal
+
+let color: "red" | "green" | "blue" = "red";
+```
+
+#### GraphQLと内部ライブラリ
+
+GraphQLのcodegenが生成する列挙型を使用する必要があります。
+
+内部ライブラリを使用する際にも列挙型を使用する方が良いので、内部ライブラリが内部APIに関連しない文字列リテラル型を公開する必要がなくなります。
+
+例:
+
+```TSX
+const {
+  setHotkeyScopeAndMemorizePreviousScope,
+  goBackToPreviousHotkeyScope,
+} = usePreviousHotkeyScope();
+
+setHotkeyScopeAndMemorizePreviousScope(
+  RelationPickerHotkeyScope.RelationPicker,
+);
+```
+
+## スタイリング
+
+### StyledComponentsを使用する
+
+コンポーネントを[Linaria styled](https://github.com/callstack/linaria)でスタイル設定する。
+
+```tsx
+// ❌ Bad
+<div className="my-class">Hello World</div>
+```
+
+```tsx
+// ✅ Good
+const StyledTitle = styled.div`
+  color: red;
+`;
+```
+
+スタイル付きコンポーネントを"Styled"で接頭辞にして、"本物の"コンポーネントと区別する。
+
+```tsx
+// ❌ Bad
+const Title = styled.div`
+  color: red;
+`;
+```
+
+```tsx
+// ✅ Good
+const StyledTitle = styled.div`
+  color: red;
+`;
+```
+
+### テーマ
+
+大部分のコンポーネントのスタイルをテーマに基づかせるのが推奨される手法です。
+
+#### 測定の単位
+
+Styledコンポーネント内で`px`または`rem`値を直接使用しない 必要な値は一般的にテーマに既に定義されているため、これらの目的でテーマを利用することが推奨されます。 必要な値は一般的にテーマに既に定義されているため、これらの目的でテーマを利用することが推奨されます。 必要な値は一般的にテーマに既に定義されているため、これらの目的でテーマを利用することが推奨されます。
+
+#### カラー
+
+新しい色を追加するのではなく、テーマから既存のパレットを使用してください。 パレットが適合しない場合には、コメントを残してチームがそれを修正できるようにしてください。 パレットが適合しない場合には、コメントを残してチームがそれを修正できるようにしてください。 パレットが適合しない場合には、コメントを残してチームがそれを修正できるようにしてください。
+
+```tsx
+// ❌ Bad, directly specifies style values without utilizing the theme
+const StyledButton = styled.button`
+  color: #333333;
+  font-size: 1rem;
+  font-weight: 400;
+  margin-left: 4px;
+  border-radius: 50px;
+`;
+```
+
+```tsx
+// ✅ Good, utilizes the theme
+const StyledButton = styled.button`
+  color: ${({ theme }) => theme.font.color.primary};
+  font-size: ${({ theme }) => theme.font.size.md};
+  font-weight: ${({ theme }) => theme.font.weight.regular};
+  margin-left: ${({ theme }) => theme.spacing(1)};
+  border-radius:  ${({ theme }) => theme.border.rounded};
+`;
+```
+
+## タイプ無しのインポートの強制
+
+タイプインポートを避けてください。 この標準を強制するために、Oxlint のルールがあらゆる型インポートをチェックして報告します。 これにより、TypeScriptコードの一貫性と可読性が維持されます。
+
+```tsx
+// ❌ Bad
+import { type Meta, type StoryObj } from '@storybook/react';
+
+// ❌ Bad
+import type { Meta, StoryObj } from '@storybook/react';
+
+// ✅ Good
+import { Meta, StoryObj } from '@storybook/react';
+```
+
+### なぜタイプなしインポートなのか
+
+* **一貫性**: 型インポートを避け、型と値の両方に単一のアプローチを使用することで、モジュールインポートスタイルの一貫性が保たれます。
+
+* **可読性**: 型専用インポートは、値をインポートしているのか型をインポートしているのかを明確にすることで、コードの可読性を高めます。 これにより曖昧さが減り、インポートされたシンボルの目的を理解しやすくなります。
+
+* **維持性**: コードベースの維持性を向上させます。開発者がコードを確認/変更する際に、タイプのみのインポートを特定して見つけることができるからです。
+
+### Oxlintルール
+
+Oxlint のルール `typescript/consistent-type-imports` は、型インポート禁止の標準を強制します。 このルールは、タイプインポート違反のエラーや警告を生成します。
+
+このルールは、意図せず型をインポートしてしまう稀なエッジケースに特化して対処することに留意してください。 TypeScript自体、[TypeScript 3.8 リリースノート](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html)でこのプラクティスを避けています。 ほとんどの状況で、タイプのみのインポートを使用する必要はありません。 ほとんどの状況で、タイプのみのインポートを使用する必要はありません。 ほとんどの状況で、タイプのみのインポートを使用する必要はありません。
+
+コードがこのルールに準拠していることを確実にするため、開発ワークフローの一環として Oxlint を実行してください。

packages/twenty-docs/l/ja/developers/contribute/capabilities/frontend-development/work-with-figma.mdx

@@ -0,0 +1,138 @@
+---
+title: Figma で作業する
+info: Twenty の Figma を使用した共同作業方法を学ぶ
+---
+
+Figma は、デザイナーと開発者の間のコミュニケーションの壁を埋めるのを助ける協働インターフェース設計ツールです。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+このガイドは、Figma を使って共同作業する方法を説明します。
+
+## アクセス
+
+1. **共有リンクにアクセスする:** プロジェクトの Figma ファイルは [ここ](https://www.figma.com/file/xt8O9mFeLl46C5InWwoMrN/Twenty) からアクセスできます。
+2. **サインイン:** まだサインインしていない場合、Figma はサインインを促します。
+   開発者モードや専用のフレーム選択など、キー機能はサインインしたユーザーのみが利用できます。
+
+<Warning>
+
+アカウントがないと効果的に協力することはできません。
+
+</Warning>
+
+## Figma 構造
+
+左側のサイドバーで、Twenty の Figma の異なるページにアクセスできます。 それらは次のように整理されています: それらは次のように整理されています: それらは次のように整理されています: それらは次のように整理されています: それらは次のように整理されています:
+
+* **コンポーネントページ:** これは最初のページです。 デザイナーはこれを使用して、デザインファイル全体で使用される再利用可能なデザイン要素を作成および整理します。 例えば、ボタン、アイコン、シンボル、またはその他の再利用可能なコンポーネントとして使用されます。 これにより、デザイン全体で一貫性を保つことができます。
+* **メインページ:** 2 番目のページはメインページで、プロジェクトの完全なユーザーインターフェースを示しています。 ***再生*** を押すことで、アプリプロトタイプを完全に使用できます。 **メインページ:** 2 番目のページはメインページで、プロジェクトの完全なユーザーインターフェースを示しています。 ***再生*** を押すことで、アプリプロトタイプを完全に使用できます。 ***再生*** を押すことで、アプリプロトタイプを完全に使用できます。
+* **特徴ページ:** その他のページは、通常、進行中の機能に専念しています。 それらはアプリケーションまたはウェブサイトの特定の機能またはモジュールのデザインを含みます。 通常、まだ進行中です。 それらはアプリケーションまたはウェブサイトの特定の機能またはモジュールのデザインを含みます。 通常、まだ進行中です。 それらはアプリケーションまたはウェブサイトの特定の機能またはモジュールのデザインを含みます。 通常、まだ進行中です。 それらはアプリケーションまたはウェブサイトの特定の機能またはモジュールのデザインを含みます。 通常、まだ進行中です。
+
+## 役立つヒント
+
+閲覧専用アクセスでは、デザインの編集はできませんが、デザインをコードに変換する際に役立つすべての機能にアクセスできます。
+
+### 開発者モードを使用する
+
+Figma の Dev モードは、デザインナビゲーションの容易化、効果的なアセット管理、効率的な通信ツール、ツールボックス統合、迅速なコードスニペット、主要レイヤー情報の提供により、開発者の生産性を向上させ、デザインと開発の間のギャップを埋めます。 Dev Mode についての詳細は [こちら](https://www.figma.com/dev-mode/) で確認できます。
+
+ツールバーの右部分で「開発者」モードに切り替えることで、デザインスペックの確認、CSS のコピー、アセットへのアクセスが可能です。
+
+### プロトタイプを使用する
+
+キャンバス上の任意の要素をクリックし、インターフェースの右上隅にある「再生」ボタンを押してプロトタイプビューにアクセスします。 プロトタイプモードでは、あたかも最終製品であるかのようにデザインに触れることができます。 画面間のフローや、ボタン、リンク、メニューなどのインターフェース要素が操作時にどのように動作するかを示します。
+
+1. **トランジションとアニメーションの理解:** プロトタイプモードでは、デザイナーによって画面や UI 要素間に追加されたトランジションやアニメーションを表示でき、開発者に意図された動作やスタイルを視覚的に明確に指示します。
+2. **実装の明確化:** プロトタイプは曖昧さを減らすのにも役立ちます。 開発者はそれを操作することで、特定の要素の機能や外観をより良く理解することができます。
+
+Figma プラットフォームの学習に関するより包括的な詳細とガイダンスについては、公式の [Figma ドキュメント](https://help.figma.com/hc/en-us) を訪れることができます。
+
+### 距離を測定する
+
+要素を選択し、`Option` キー（Mac）または `Alt` キー（Windows）を押したまま、別の要素の上にカーソルを合わせると、それらの間の距離が表示されます。
+
+### VSCode 用 Figma 拡張機能（推奨）
+
+[Figma for VS Code](https://marketplace.visualstudio.com/items?itemName=figma.figma-vscode-extension) を使用すると、デザインファイルのナビゲート、検査、デザイナーとのコラボレーション、変更の追跡、実装の促進ができます - すべてをテキストエディターから離れることなく行えます。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+これは推奨拡張機能の一部です。
+
+## コラボレーション
+
+1. **コメントの使用:** ツールバーの左側にあるバブルアイコンをクリックしてコメント機能を使用できます。
+2. **カーソルチャット:** Figma の魅力的な機能のひとつにカーソルチャットがあります。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。 **カーソルチャット:** Figma の魅力的な機能のひとつにカーソルチャットがあります。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。 **カーソルチャット:** Figma の魅力的な機能のひとつにカーソルチャットがあります。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。 **カーソルチャット:** Figma の魅力的な機能のひとつにカーソルチャットがあります。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。 **カーソルチャット:** Figma の魅力的な機能のひとつにカーソルチャットがあります。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。 **カーソルチャット:** Figma の魅力的な機能のひとつにカーソルチャットがあります。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。 **カーソルチャット:** Figma の魅力的な機能のひとつにカーソルチャットがあります。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。 他の Figma を同時に使用している誰かを見た場合、`/` キー（Windows）または `;` キー（Mac）を押してメッセージを送信します。