Skip to content
Open
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions docs/4-advanced/04-react/declarative-ui.drawio.svg
Comment thread
chvmvd marked this conversation as resolved.
Comment thread
chvmvd marked this conversation as resolved.
Comment thread
chvmvd marked this conversation as resolved.
Comment thread
chvmvd marked this conversation as resolved.
Comment thread
chvmvd marked this conversation as resolved.
Comment thread
chvmvd marked this conversation as resolved.
Comment thread
chvmvd marked this conversation as resolved.
Comment thread
chvmvd marked this conversation as resolved.
Comment thread
chvmvd marked this conversation as resolved.
Comment thread
chvmvd marked this conversation as resolved.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

骨格はいいと思います!ただ、上下左右で位置がずれている箇所や、余分な空白があるところ、余白が狭いところなどがあるので、例えば、#954 みたいな感じにするのはどうでしょう?

Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
8 changes: 5 additions & 3 deletions docs/4-advanced/04-react/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -47,9 +47,9 @@ addTodoButton.onclick = () => {

ところが、アプリケーションの本質的な状態というのは、一般的にそこまで多いものではありません。例えば、ToDoリストアプリケーションであれば、各ToDoを表す`string`の配列`string[]`がひとつだけあれば、アプリケーションの状態は全て表現できていることになるはずです。

**宣言的UI**は、こういった性質に着目します。より具体的に説明するのであれば、アプリケーションの状態$S$に対し、関数$f(S)$によりUIの状態を表現できるのであれば、開発者の関心を$S$の変化と$f$の定義のみに絞ることができるというわけです。
**宣言的UI**は、こういった性質に着目します。より一般的に説明するのであれば、アプリケーションの状態$S$に対し、関数$f(S)$によりUIの状態を表現できるのであれば、開発者の関心を$S$の変化と$f$の定義のみに絞ることができるというわけです。
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ここはもとのままで合っているような気がします。

「宣言的UIは、こういった性質に着目します。」という説明を、「より具体的に」説明すると、「アプリケーションの状態$S$に対し、...」という説明になるという論理展開になっているかと思います。
ここで2つの文の関係を考えます。「宣言的UIは、こういった性質に着目します。」という説明はぼんやりとした曖昧な説明となっており、後続の「アプリケーションの状態$S$に対し、...」という説明によって「こういった性質」の中身を一段詳しく説明しているという関係になっているかと思います。
そのため、たしかに、1文目の説明を2文目の説明がより具体的に説明しているので、ここでは「より一般的に」ではなく、「より具体的に」と書くのが正しいような気がします。


具体的なコードで確認してみましょう。先ほどのToDoアプリケーションを、宣言的UIのアプローチを用いて書き換えてみましょう。状態を追いやすいよう、TypeScriptを用いて記述します。
具体的なコードで確認してみましょう。先ほどのToDoアプリケーションのコードを、宣言的UIのアプローチを用いて書き換えてみましょう。状態を追いやすいよう、TypeScriptを用いて記述します。

まずはアプリケーションの状態と、その状態を格納する変数を宣言します。

Expand Down Expand Up @@ -88,7 +88,9 @@ function removeTodo(index: number) {

<ViewSource url={import.meta.url} path="_samples/todo-declarative" />

これにより、アプリケーション全体の状態が変数`state`に集約され、開発者が意識すべき状態のパターンを大幅に減らすことに成功しました。
これにより、アプリケーション全体の状態が変数`state`に集約され、開発者が意識すべき状態のパターンを大幅に減らすことに成功しました。このコードでは、状態$S$は変数`state`に、関数$f(S)$は`render`関数に対応しています。例えば、`remove("寝る")`によって`state`が変化すると、`render`関数が再び呼ばれ、新しい状態に応じたUIが描画されます。
Copy link
Copy Markdown
Contributor

@chvmvd chvmvd Apr 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ここでは、この文より上にある説明で用いられているコード(addTodo関数やremoveTodo関数が宣言されているコード)と、図の中で用いられているコード(remove関数が用いられているコード)の2種類が存在しているかと思います。
そのため、ここでの「コード」という表現が、この文より上にある説明で用いられているコードと、図の中で用いられているコードのどちらを指しているか、かなり曖昧になっています。実際に、「これにより、アプリケーション全体の状態が変数stateに集約され、...」という文が指しているコードは前者のことを指しており、「このコードでは、状態$S$は変数stateに、...」という文が指しているコードは後者のことを指しているというように、1文目と2文目でまったく異なるものを指してしまっています。
また、画像ではadd("寝る")となっていて、説明ではremove("寝る")となっており、ずれているかと思います。


![宣言的UIの概念図](./declarative-ui.drawio.svg)

## React

Expand Down