Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finish translation of Reacting to Input with State #581

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

undead404
Copy link
Contributor

No description provided.

Copy link

vercel bot commented Dec 29, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Skipped Deployment
Name Status Preview Comments Updated (UTC)
uk-legacy-reactjs-org ⬜️ Ignored (Inspect) Visit Preview Jan 3, 2025 0:14am

Copy link

github-actions bot commented Dec 29, 2024

Size changes

📦 Next.js Bundle Analysis for react-dev

This analysis was generated by the Next.js Bundle Analysis action. 🤖

Five Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page Size (compressed) First Load
/404 106.41 KB (🟡 +5 B) 210.79 KB
/500 106.41 KB (🟡 +5 B) 210.79 KB
/[[...markdownPath]] 108.32 KB (🟡 +5 B) 212.7 KB
/errors 106.62 KB (🟡 +5 B) 211 KB
/errors/[errorCode] 106.6 KB (🟡 +5 B) 210.98 KB
Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by 10% or more, there will be a red status indicator applied, indicating that special attention should be given to this.

Copy link
Collaborator

@alinkedd alinkedd left a comment

Choose a reason for hiding this comment

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

Перша частина перевірки (до step 3)

src/content/learn/reacting-to-input-with-state.md Outdated Show resolved Hide resolved
src/content/learn/reacting-to-input-with-state.md Outdated Show resolved Hide resolved
src/content/learn/reacting-to-input-with-state.md Outdated Show resolved Hide resolved
src/content/learn/reacting-to-input-with-state.md Outdated Show resolved Hide resolved
src/content/learn/reacting-to-input-with-state.md Outdated Show resolved Hide resolved
src/content/learn/reacting-to-input-with-state.md Outdated Show resolved Hide resolved
src/content/learn/reacting-to-input-with-state.md Outdated Show resolved Hide resolved
src/content/learn/reacting-to-input-with-state.md Outdated Show resolved Hide resolved
src/content/learn/reacting-to-input-with-state.md Outdated Show resolved Hide resolved
src/content/learn/reacting-to-input-with-state.md Outdated Show resolved Hide resolved
@undead404
Copy link
Contributor Author

Звертаю увагу, що лишилась незакрита дискусія

Copy link
Collaborator

@alinkedd alinkedd left a comment

Choose a reason for hiding this comment

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

Друга і фінальна частина перевірки

trigger змінено на тригер/збудити


Start with the state that *absolutely must* be there. For example, you'll need to store the `answer` for the input, and the `error` (if it exists) to store the last error:
Почніть зі стану, який *абсолютно точно* повинен бути присутній. Наприклад, необхідно зберігати `answer` — значення поля, а також `error`, аби зберігати останню помилку:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
Почніть зі стану, який *абсолютно точно* повинен бути присутній. Наприклад, необхідно зберігати `answer` — значення поля, а також `error`, аби зберігати останню помилку:
Почніть зі стану, який *безсумнівно повинен* бути присутній. Наприклад, необхідно зберігати `answer` — значення поля, а також за наявності `error` останню помилку:


```js
const [answer, setAnswer] = useState('');
const [error, setError] = useState(null);
```

Then, you'll need a state variable representing which one of the visual states that you want to display. There's usually more than a single way to represent that in memory, so you'll need to experiment with it.
Далі потрібна змінна стану, що представляє те, який з візуальних станів має бути виведений. Зазвичай є більш ніж один спосіб представити це в пам'яті, тому доведеться з цим поекспериментувати.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
Далі потрібна змінна стану, що представляє те, який з візуальних станів має бути виведений. Зазвичай є більш ніж один спосіб представити це в пам'яті, тому доведеться з цим поекспериментувати.
Далі потрібна змінна стану, що представляє те, який із візуальних станів має бути виведений. Зазвичай є більш ніж один спосіб представити це в пам'яті, тому доведеться з цим поекспериментувати.


If you struggle to think of the best way immediately, start by adding enough state that you're *definitely* sure that all the possible visual states are covered:
Якщо вам важко зразу вигадати найкращий спосіб, почніть з додавання такої кількості стану, щоб *точно* були покриті всі можливі візуальні стани:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
Якщо вам важко зразу вигадати найкращий спосіб, почніть з додавання такої кількості стану, щоб *точно* були покриті всі можливі візуальні стани:
Якщо вам важко одразу вигадати найкращий спосіб, почніть із додавання такої кількості стану, щоб *напевно* були покриті всі можливі візуальні стани:

@@ -371,39 +371,39 @@ const [isSuccess, setIsSuccess] = useState(false);
const [isError, setIsError] = useState(false);
```

Your first idea likely won't be the best, but that's ok--refactoring state is a part of the process!
Ваш перший варіант навряд буде найкращим з можливих, але це нормально: рефакторинг стану — частина процесу розробки!
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
Ваш перший варіант навряд буде найкращим з можливих, але це нормально: рефакторинг стану — частина процесу розробки!
Ваш перший варіант навряд буде найкращим із можливих, але це нормально: рефакторинг стану — частина процесу розробки!

* **Is the same information available in another state variable already?** Another paradox: `isEmpty` and `isTyping` can't be `true` at the same time. By making them separate state variables, you risk them going out of sync and causing bugs. Fortunately, you can remove `isEmpty` and instead check `answer.length === 0`.
* **Can you get the same information from the inverse of another state variable?** `isError` is not needed because you can check `error !== null` instead.
* **Чи призводить цей стан до парадоксів?** Наприклад, `isTyping` і `isSubmitting` не можуть водночас бути `true`. Парадокс зазвичай означає, що на стан накладено недостатньо обмежень. Є чотири можливі комбінації двох булевих змінних, але лише три з них відповідають валідним станам. Щоб позбавитися "неможливого" стану, можна поєднати ці змінні в одну змінну `status`, яка повинна мати одне з трьох значень: `'typing'`, `'submitting'` або `'success'`.
* **Чи доступна та сама інформація в іншій змінній стану?** Ще один парадокс: `isEmpty` й `isTyping` не можуть водночас бути `true`. Їхнє розділення приносить ризик того, що вони розсинхронізуються, що породить помилки. На щастя, можна вилучити `isEmpty`, а натомість перевіряти `answer.length === 0`.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* **Чи доступна та сама інформація в іншій змінній стану?** Ще один парадокс: `isEmpty` й `isTyping` не можуть водночас бути `true`. Їхнє розділення приносить ризик того, що вони розсинхронізуються, що породить помилки. На щастя, можна вилучити `isEmpty`, а натомість перевіряти `answer.length === 0`.
* **Чи доступна та сама інформація в іншій змінній стану?** Ще один парадокс: `isEmpty` й `isTyping` не можуть водночас мати значення `true`. Їхнє розділення загрожує можливою розсинхронізацією та породженням помилок. На щастя, можна вилучити `isEmpty`, а натомість перевіряти `answer.length === 0`.


</Solution>

</Challenges>
</Challenges>
Copy link
Collaborator

Choose a reason for hiding this comment

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

що тут змінилося? забрав каретку?

4. **Remove** any non-essential state variables
5. **Connect** the event handlers to set the state
1. **З'ясуйте** різні візуальні стани свого компонента
2. **Визначте**, що запускає ці зміни стану
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
2. **Визначте**, що запускає ці зміни стану
2. **Визначте**, що збуджує ці зміни стану


You can trigger state updates in response to two kinds of inputs:
Запускати зміни стану можна у відповідь на два види введення:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
Запускати зміни стану можна у відповідь на два види введення:
Збудити зміни стану можна у відповідь на два види введення:


</DeepDive>

### Step 2: Determine what triggers those state changes {/*step-2-determine-what-triggers-those-state-changes*/}
### Крок 2. Визначте, що запускає ці зміни стану {/*step-2-determine-what-triggers-those-state-changes*/}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
### Крок 2. Визначте, що запускає ці зміни стану {/*step-2-determine-what-triggers-those-state-changes*/}
### Крок 2. Визначте, що збуджує ці зміни стану {/*step-2-determine-what-triggers-those-state-changes*/}

* Декларативне програмування означає описувати UI для кожного візуального стану, а не займатися мікроменеджментом UI (імперативним стилем).
* Для розробки компонента:
1. З'ясуйте всі його візуальні стани.
2. Визначте людські та комп'ютерні пускачі змін стану.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
2. Визначте людські та комп'ютерні пускачі змін стану.
2. Визначте людські та комп'ютерні тригери змін стану.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants