-
Notifications
You must be signed in to change notification settings - Fork 119
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
base: main
Are you sure you want to change the base?
Finish translation of Reacting to Input with State #581
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
Size changes📦 Next.js Bundle Analysis for react-devThis analysis was generated by the Next.js Bundle Analysis action. 🤖 Five Pages Changed SizeThe following pages changed size from the code in this PR compared to its base branch:
DetailsOnly 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 Any third party scripts you have added directly to your app using the 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Перша частина перевірки (до step 3)
- trigger поки залишаю як запустити/запуск [Suggestion]: Переклад Trigger #584
- represent поки залишаю як представляти
Co-authored-by: Alina Listunova <[email protected]>
Звертаю увагу, що лишилась незакрита дискусія |
There was a problem hiding this 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`, аби зберігати останню помилку: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Почніть зі стану, який *абсолютно точно* повинен бути присутній. Наприклад, необхідно зберігати `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. | ||
Далі потрібна змінна стану, що представляє те, який з візуальних станів має бути виведений. Зазвичай є більш ніж один спосіб представити це в пам'яті, тому доведеться з цим поекспериментувати. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Далі потрібна змінна стану, що представляє те, який з візуальних станів має бути виведений. Зазвичай є більш ніж один спосіб представити це в пам'яті, тому доведеться з цим поекспериментувати. | |
Далі потрібна змінна стану, що представляє те, який із візуальних станів має бути виведений. Зазвичай є більш ніж один спосіб представити це в пам'яті, тому доведеться з цим поекспериментувати. |
|
||
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: | ||
Якщо вам важко зразу вигадати найкращий спосіб, почніть з додавання такої кількості стану, щоб *точно* були покриті всі можливі візуальні стани: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Якщо вам важко зразу вигадати найкращий спосіб, почніть з додавання такої кількості стану, щоб *точно* були покриті всі можливі візуальні стани: | |
Якщо вам важко одразу вигадати найкращий спосіб, почніть із додавання такої кількості стану, щоб *напевно* були покриті всі можливі візуальні стани: |
@@ -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! | |||
Ваш перший варіант навряд буде найкращим з можливих, але це нормально: рефакторинг стану — частина процесу розробки! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ваш перший варіант навряд буде найкращим з можливих, але це нормально: рефакторинг стану — частина процесу розробки! | |
Ваш перший варіант навряд буде найкращим із можливих, але це нормально: рефакторинг стану — частина процесу розробки! |
* **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`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* **Чи доступна та сама інформація в іншій змінній стану?** Ще один парадокс: `isEmpty` й `isTyping` не можуть водночас бути `true`. Їхнє розділення приносить ризик того, що вони розсинхронізуються, що породить помилки. На щастя, можна вилучити `isEmpty`, а натомість перевіряти `answer.length === 0`. | |
* **Чи доступна та сама інформація в іншій змінній стану?** Ще один парадокс: `isEmpty` й `isTyping` не можуть водночас мати значення `true`. Їхнє розділення загрожує можливою розсинхронізацією та породженням помилок. На щастя, можна вилучити `isEmpty`, а натомість перевіряти `answer.length === 0`. |
|
||
</Solution> | ||
|
||
</Challenges> | ||
</Challenges> |
There was a problem hiding this comment.
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. **Визначте**, що запускає ці зміни стану |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2. **Визначте**, що запускає ці зміни стану | |
2. **Визначте**, що збуджує ці зміни стану |
|
||
You can trigger state updates in response to two kinds of inputs: | ||
Запускати зміни стану можна у відповідь на два види введення: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Запускати зміни стану можна у відповідь на два види введення: | |
Збудити зміни стану можна у відповідь на два види введення: |
|
||
</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*/} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
### Крок 2. Визначте, що запускає ці зміни стану {/*step-2-determine-what-triggers-those-state-changes*/} | |
### Крок 2. Визначте, що збуджує ці зміни стану {/*step-2-determine-what-triggers-those-state-changes*/} |
* Декларативне програмування означає описувати UI для кожного візуального стану, а не займатися мікроменеджментом UI (імперативним стилем). | ||
* Для розробки компонента: | ||
1. З'ясуйте всі його візуальні стани. | ||
2. Визначте людські та комп'ютерні пускачі змін стану. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2. Визначте людські та комп'ютерні пускачі змін стану. | |
2. Визначте людські та комп'ютерні тригери змін стану. |
No description provided.