humanize v13 docs

Author: mdjastrzebski

website/docs/13.x/cookbook/advanced/network-requests.md

@@ -2,13 +2,12 @@
 
 ## Introduction
 
-Mocking network requests is an essential part of testing React Native applications. By mocking
-network
-requests, you can control the data that is returned from the server and test how your application
-behaves in different scenarios, such as when the request is successful or when it fails.
+Mocking network requests is essential for testing React Native applications. By mocking
+network requests, you can control the data returned from the server and test how your application
+behaves in different scenarios, such as when the request succeeds or fails.
 
-In this guide, we will show you how to mock network requests and guard your test suits from unwanted
-and unmocked/unhandled network requests
+This guide shows how to mock network requests and guard your test suites against unwanted
+and unmocked/unhandled network requests.
 
 :::info
 To simulate a real-world scenario, we will use the [Random User Generator API](https://randomuser.me/) that provides random user data.
@@ -363,14 +362,14 @@ Which will result in a warning in the console if you forget to mock an API reque
 
 ## Conclusion
 
-Testing a component that makes network requests in combination with MSW takes some initial preparation to configure and describe the overridden networks.
-We can achieve that by using MSW's request handlers and intercepting APIs.
+Testing components that make network requests with MSW requires initial setup to configure and describe the overridden networks.
+Use MSW's request handlers and intercepting APIs to achieve this.
 
-Once up and running we gain full grip over the network requests, their responses, statuses.
-Doing so is crucial to be able to test how our application behaves in different
-scenarios, such as when the request is successful or when it fails.
+Once configured, you have full control over network requests, their responses, and statuses.
+This lets you test how your application behaves in different
+scenarios, such as when requests succeed or fail.
 
-When global configuration is in place, MSW's will also warn us when an unhandled network requests has occurred throughout a test suite.
+With global configuration in place, MSW will also warn you when an unhandled network request occurs during a test suite.
 
 ## Further Reading and Alternatives
 

website/docs/13.x/docs/advanced/testing-env.mdx

@@ -6,7 +6,7 @@ This document is intended for a more advanced audience who want to understand th
 
 :::
 
-React Native Testing Library allows you to write integration and component tests for your React Native app or library. While the JSX code used in tests closely resembles your React Native app, things are not as simple as they might appear. This document will describe the key elements of our testing environment and highlight things to be aware of when writing more advanced tests or diagnosing issues.
+React Native Testing Library allows you to write integration and component tests for your React Native app or library. While the JSX code used in tests closely resembles your React Native app, things aren't as simple as they might appear. This document describes the key elements of our testing environment and highlights things to be aware of when writing more advanced tests or diagnosing issues.
 
 ## React renderers
 
@@ -37,7 +37,7 @@ Disadvantages:
 - Assertions do not operate on native view hierarchy
 - Runtime behaviors are simulated, sometimes imperfectly
 
-It's worth noting that the React Testing Library (web one) works a bit differently. While RTL also runs in Jest, it has access to a simulated browser DOM environment from the `jsdom` package, which allows it to use a regular React DOM renderer. Unfortunately, there is no similar React Native runtime environment package. This is probably because while the browser environment is well-defined and highly standardized, the React Native environment constantly evolves in sync with the evolution of underlying OS-es. Maintaining such an environment would require duplicating countless React Native behaviors and keeping them in sync as React Native develops.
+The React Testing Library (web one) works differently. While RTL also runs in Jest, it has access to a simulated browser DOM environment from the `jsdom` package, which allows it to use a regular React DOM renderer. Unfortunately, there's no similar React Native runtime environment package. This is probably because while the browser environment is well-defined and highly standardized, the React Native environment constantly evolves in sync with the evolution of underlying OS-es. Maintaining such an environment would require duplicating countless React Native behaviors and keeping them in sync as React Native develops.
 
 ## Element tree
 
@@ -111,7 +111,7 @@ function isHostElement(element: ReactTestInstance) {
 
 ## Tree nodes
 
-We encourage you to only assert values on host views in your tests because they represent the user interface view and controls which the user can see and interact with. Users cannot see or interact with composite views as they exist purely in the JavaScript domain and do not generate any visible UI.
+We encourage you to only assert values on host views in your tests because they represent the user interface view and controls that users can see and interact with. Users can't see or interact with composite views as they exist purely in the JavaScript domain and don't generate any visible UI.
 
 ### Asserting props
 

website/docs/13.x/docs/advanced/third-party-integration.mdx

@@ -1,6 +1,6 @@
 # Third-Party Library Integration
 
-The React Native Testing Library is designed to simulate the core behaviors of React Native. However, it does not replicate the internal logic of third-party libraries. This guide explains how to integrate your library with RNTL.
+The React Native Testing Library is designed to simulate the core behaviors of React Native. However, it doesn't replicate the internal logic of third-party libraries. This guide explains how to integrate your library with RNTL.
 
 ## Handling Events in Third-Party Libraries
 

website/docs/13.x/docs/advanced/understanding-act.mdx

@@ -1,6 +1,6 @@
 # Understanding `act` function
 
-When writing RNTL tests one of the things that confuses developers the most are cryptic [`act()`](https://reactjs.org/docs/testing-recipes.html#act) function errors logged into console. In this article I will try to build an understanding of the purpose and behaviour of `act()` so you can build your tests with more confidence.
+When writing RNTL tests, one of the things that confuses developers the most are cryptic [`act()`](https://reactjs.org/docs/testing-recipes.html#act) function errors logged to the console. This article explains the purpose and behavior of `act()` so you can write tests with more confidence.
 
 ## `act` warnings
 
@@ -33,7 +33,7 @@ This function is intended only for using in automated tests and works only in de
 
 The responsibility for `act` function is to make React renders and updates work in tests in a similar way they work in real application by grouping and executing related units of interaction (e.g. renders, effects, etc) together.
 
-To showcase that behaviour let make a small experiment. First we define a function component that uses `useEffect` hook in a trivial way.
+To show that behavior, let's make a small experiment. First we define a function component that uses `useEffect` hook in a trivial way.
 
 ```jsx
 function TestComponent() {
@@ -58,7 +58,7 @@ test('render without act', () => {
 });
 ```
 
-When testing without `act` call wrapping rendering call, we see that the assertion runs just after the rendering but before `useEffect`hooks effects are applied. Which is not what we expected in our tests.
+When testing without wrapping the rendering call in `act`, the assertion runs just after rendering but before `useEffect` hooks effects are applied. This is not what we expected in our tests.
 
 ```jsx
 test('render with act', () => {
@@ -73,21 +73,21 @@ test('render with act', () => {
 });
 ```
 
-When wrapping rendering call with `act` we see that the changes caused by `useEffect` hook have been applied as we would expect.
+When wrapping the rendering call with `act`, the changes caused by the `useEffect` hook are applied as expected.
 
 ### When to use act
 
 The name `act` comes from [Arrange-Act-Assert](http://wiki.c2.com/?ArrangeActAssert) unit testing pattern. Which means it’s related to part of the test when we execute some actions on the component tree.
 
-So far we learned that `act` function allows tests to wait for all pending React interactions to be applied before we make our assertions. When using `act` we get guarantee that any state updates will be executed as well as any enqueued effects will be executed.
+The `act` function allows tests to wait for all pending React interactions to be applied before making assertions. When using `act`, we get a guarantee that any state updates will be executed and any enqueued effects will be executed.
 
 Therefore, we should use `act` whenever there is some action that causes element tree to render, particularly:
 
 - initial render call - `ReactTestRenderer.create` call
 - re-rendering of component -`renderer.update` call
 - triggering any event handlers that cause component tree render
 
-Thankfully, for these basic cases RNTL has got you covered as our `render`, `update` and `fireEvent` methods already wrap their calls in sync `act` so that you do not have to do it explicitly.
+For these basic cases, RNTL handles it for you. Our `render`, `update`, and `fireEvent` methods already wrap their calls in sync `act` so you don't have to do it explicitly.
 
 Note that `act` calls can be safely nested and internally form a stack of calls. However, overlapping `act` calls, which can be achieved using async version of `act`, [are not supported](https://github.com/facebook/react/blob/main/packages/react/src/ReactAct.js#L161).
 
@@ -103,9 +103,9 @@ So far we have seen synchronous version of `act` which runs its callback immedia
 
 ### Asynchronous code
 
-Asynchronous version of `act` also is executed immediately, but the callback is not yet completed because of some asynchronous operations inside.
+The asynchronous version of `act` is also executed immediately, but the callback doesn't complete right away because of asynchronous operations inside.
 
-Lets look at a simple example with component using `setTimeout` call to simulate asynchronous behaviour:
+Let's look at a simple example with a component using `setTimeout` to simulate asynchronous behavior:
 
 ```jsx
 function TestAsyncComponent() {
@@ -129,7 +129,7 @@ test('render async natively', () => {
 });
 ```
 
-If we test our component in a native way without handling its asynchronous behaviour we will end up with sync act warning:
+If we test our component without handling its asynchronous behavior, we'll get a sync act warning:
 
 ```
 Warning: An update to TestAsyncComponent inside a test was not wrapped in act(...).
@@ -142,7 +142,7 @@ act(() => {
 /* assert on the output */
 ```
 
-Note that this is not yet the infamous async act warning. It only asks us to wrap our event code with `act` calls. However, this time our immediate state change does not originate from externally triggered events but rather forms an internal part of the component. So how can we apply `act` in such scenario?
+This is not yet the async act warning. It only asks us to wrap our event code with `act` calls. However, this time the state change doesn't come from externally triggered events but from an internal part of the component. So how can we apply `act` in this scenario?
 
 ### Solution with fake timers
 
@@ -160,7 +160,7 @@ test('render with fake timers', () => {
 });
 ```
 
-That way we can wrap `jest.runAllTimers()` call which triggers the `setTimeout` updates inside an `act` call, hence resolving the act warning. Note that this whole code is synchronous thanks to usage of Jest fake timers.
+This way we can wrap the `jest.runAllTimers()` call, which triggers the `setTimeout` updates, inside an `act` call, resolving the act warning. Note that this whole code is synchronous thanks to Jest fake timers.
 
 ### Solution with real timers
 
@@ -177,7 +177,7 @@ test('render with real timers - sleep', async () => {
 });
 ```
 
-This works correctly as we use an explicit async `act()` call that resolves the console error. However, it relies on our knowledge of exact implementation details which is a bad practice.
+This works correctly because we use an explicit async `act()` call that resolves the console error. However, it relies on knowing exact implementation details, which is a bad practice.
 
 Let’s try more elegant solution using `waitFor` that will wait for our desired state:
 
@@ -190,7 +190,7 @@ test('render with real timers - waitFor', async () => {
 });
 ```
 
-This also works correctly, because `waitFor` call executes async `act()` call internally.
+This also works correctly because `waitFor` executes async `act()` internally.
 
 The above code can be simplified using `findBy` query:
 
@@ -202,13 +202,13 @@ test('render with real timers - findBy', async () => {
 });
 ```
 
-This also works since `findByText` internally calls `waitFor` which uses async `act()`.
+This also works because `findByText` internally calls `waitFor`, which uses async `act()`.
 
 Note that all of the above examples are async tests using & awaiting async `act()` function call.
 
 ### Async act warning
 
-If we modify any of the above async tests and remove `await` keyword, then we will trigger the notorious async `act()`warning:
+If we modify any of the above async tests and remove the `await` keyword, we'll trigger the async `act()` warning:
 
 ```jsx
 Warning: You called act(async () => ...) without await. This could lead to unexpected
@@ -218,7 +218,7 @@ testing behaviour, interleaving multiple act calls and mixing their scopes. You
 
 React decides to show this error whenever it detects that async `act()`call [has not been awaited](https://github.com/facebook/react/blob/ce13860281f833de8a3296b7a3dad9caced102e9/packages/react/src/ReactAct.js#L93).
 
-The exact reasons why you might see async `act()` warnings vary, but finally it means that `act()` has been called with callback that returns `Promise`-like object, but it has not been waited on.
+The exact reasons why you might see async `act()` warnings vary, but it means that `act()` has been called with a callback that returns a `Promise`-like object, but it hasn't been awaited.
 
 ## References