-
Notifications
You must be signed in to change notification settings - Fork 54
Translate 'Shallow Renderer' page #24
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
Translate 'Shallow Renderer' page #24
Conversation
Deploy preview for pl-reactjs ready! Built with commit abcba57 |
20e1d3a
to
b14fddb
Compare
b14fddb
to
db23829
Compare
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.
💯
|
||
When writing unit tests for React, shallow rendering can be helpful. Shallow rendering lets you render a component "one level deep" and assert facts about what its render method returns, without worrying about the behavior of child components, which are not instantiated or rendered. This does not require a DOM. | ||
Podczas pisania testów jednostkowych dla kodu reactowego przydatne może okazać się renderowanie płytkie (ang. *shallow rendering*). Pozwala ono na wyrenderowanie komponentu "jeden poziom w głąb" i wykonanie sprawdzeń na zwróconym drzewie, bez obaw o efekty uboczne komponentów potomnych, które wcale nie są tworzone i renderowane. Proces ten nie wymaga obecności drzewa DOM. |
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.
asercji
zamiastsprawdzeń
- Skąd tłumaczenie
behavior
na efekty uboczne?
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.
- Ok, zmienione zgodnie z naszymi ustaleniami.
- Dlatego że nie pasuje mi sformułowanie: "bez obaw o zachowanie komponentów". Chodzi tutaj o to, że kiedy testujemy przy użyciu płytkiego renderowania, wszelkiej maści calle do backendu czy modyfikacje czegokolwiek nie nastąpią, bo komponenty potomne nie zostaną w ogóle wyrenderowane - tylko ich "szkic". Uważasz, że "zachowanie" by tu lepiej pasowało?
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.
To tylko mój konflikt wewnętrzny, kiedy odbiegamy od oryginału ;). Obawiam się, że używamy sformułowania "efekty uboczne", bez dalszego wyjaśnienia, co one oznaczają. Z drugiej strony chyba możemy założyć, że API Reference czytają zaawansowani użytkownicy. Więc nie wiem, co powiedzieć. Przemyśl mój argument, tymczasem z mojej strony 👍 .
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.
Przespałem się z tym i może być też "zachowanie". Nie kłuje mnie to już tak w oczy, jak ostatnio :D Ale żeby już nie przedłużać, zostawię jak jest. Najwyżej przy "wielkim czytaniu" (jak już skończymy tłumaczyć i zaczniemy sprawdzać całość "na prodzie") ktoś to wyhaczy i zmienimy.
No description provided.