(docs) - Language/spelling cleanup (#763)

+1 -1

docs/advanced/retry-operations.md

··· 59 59 60 60 Talking about increasing the `delay` randomly, `randomDelay` allows us to disable this. When this option is set to `false` we'll only increase the time between attempts with the `initialDelayMs`. This means if we fail the first time we'll have 1 second wait, next fail we'll have 2 seconds and so on. 61 61 62 - We don't want to infinitley attempt an `operation`, we can declare how many times it should attempt the `operation` with `maxNumberAttempts`. 62 + We don't want to infinitely attempt an `operation`, we can declare how many times it should attempt the `operation` with `maxNumberAttempts`. 63 63 64 64 [For more information on the available options check out the API Docs.](../api/retry-exchange.md) 65 65

+3 -9

docs/advanced/server-side-rendering.md

··· 18 18 To start out with the `ssrExchange` we have to add the exchange to our `Client`: 19 19 20 20 ```js 21 - import { 22 - createClient, 23 - dedupExchange, 24 - cacheExchange, 25 - fetchExchange, 26 - ssrExchange 27 - } from '@urql/core'; 21 + import { createClient, dedupExchange, cacheExchange, fetchExchange, ssrExchange } from '@urql/core'; 28 22 29 23 const isServerSide = typeof window === 'undefined'; 30 24 ··· 40 34 cacheExchange, 41 35 ssr, // Add `ssr` in front of the `fetchExchange` 42 36 fetchExchange, 43 - ] 37 + ], 44 38 }); 45 39 ``` 46 40 ··· 48 42 option tells the exchange whether it's on the server- or client-side. In our example we use `typeof window` to determine this, but in Webpack environments you may also be able to use `process.browser`. 49 43 50 44 The `initialState` option should be set to the serialized data you retrieve on your server-side. 51 - This data may be retrieved using methods on `ssrExchange()`. You can retrive the serialized data 45 + This data may be retrieved using methods on `ssrExchange()`. You can retrieve the serialized data 52 46 after server-side rendering using `ssr.extractData()`: 53 47 54 48 ```js

+4 -4

docs/advanced/testing.md

··· 13 13 14 14 ## Mocking the client 15 15 16 - For the most part, Urql's hooks are just adapters for talking to the Urql client. 16 + For the most part, urql's hooks are just adapters for talking to the urql client. 17 17 18 18 The way in which they do this is by making calls to the client via context. 19 19 ··· 21 21 - `useMutation` calls `executeMutation` 22 22 - `useSubscription` calls `executeSubscription` 23 23 24 - In the section [Stream Patterns](../concepts/stream-patterns.md) we've seen, that all methods on the client operate with and return streams. These streams are created using the `wonka` library and we're able to create streams ourselves to mock the different states of our operations, e.g. fetching, errors, or success with data. 24 + In the section [Stream Patterns](../concepts/stream-patterns.md) we've seen, that all methods on the client operate with and return streams. These streams are created using the [Wonka](../concepts/stream-patterns.md#the-wonka-library) library and we're able to create streams ourselves to mock the different states of our operations, e.g. fetching, errors, or success with data. 25 25 26 26 You'll probably use one of these utility functions to create streams: 27 27 ··· 184 184 185 185 ## Subscriptions 186 186 187 - Testing subscriptions can be done by simulating the arrival of new data over time. To do this we may use the `interval` utility from `wonka`, which emits values on a timer, and for each value we can map over the response that we'd like to mock. 187 + Testing subscriptions can be done by simulating the arrival of new data over time. To do this we may use the `interval` utility from Wonka, which emits values on a timer, and for each value we can map over the response that we'd like to mock. 188 188 189 - If you prefer to have more control on when the new data is arriving you can use the `makeSubject` utility from `wonka`. You can see more details in the next section. 189 + If you prefer to have more control on when the new data is arriving you can use the `makeSubject` utility from Wonka. You can see more details in the next section. 190 190 191 191 Here's an example of testing a list component which uses a subscription. 192 192

+10 -10

docs/api/core.md

··· 114 114 115 115 ## CombinedError 116 116 117 - The `CominedError` is used in `urql` to normalize network errors and `GraphQLError`s if anything 117 + The `CombinedError` is used in `urql` to normalize network errors and `GraphQLError`s if anything 118 118 goes wrong during a GraphQL request. 119 119 120 - | Input | Type | Description | 121 - | ------------- | -------------------------------- | --------------------------------------------------------------------------------- | 122 - | networkError | `?Error` | An unexpected error that might've occured when trying to send the GraphQL request | 123 - | graphQLErrors | `?Array<string \| GraphQLError>` | GraphQL Errors (if any) that were returned by the GraphQL API | 124 - | response | `?any` | The raw response object (if any) from the `fetch` call | 120 + | Input | Type | Description | 121 + | ------------- | -------------------------------- | ---------------------------------------------------------------------------------- | 122 + | networkError | `?Error` | An unexpected error that might've occurred when trying to send the GraphQL request | 123 + | graphQLErrors | `?Array<string \| GraphQLError>` | GraphQL Errors (if any) that were returned by the GraphQL API | 124 + | response | `?any` | The raw response object (if any) from the `fetch` call | 125 125 126 126 [Read more about errors in `urql` on the "Error" page.](../basics/errors.md) 127 127 ··· 139 139 | variables | `?object` | The variables to be used with the GraphQL request. | 140 140 141 141 The `key` property is a hash of both the `query` and the `variables`, to uniquely 142 - identify the request. When `variables` are passed it is ensured that they're stabily stringified so 142 + identify the request. When `variables` are passed it is ensured that they're stably stringified so 143 143 that the same variables in a different order will result in the same `key`, since variables are 144 144 order-independent in GraphQL. 145 145 ··· 197 197 198 198 | Prop | Type | Description | 199 199 | ------------------- | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | 200 - | fetchOptions | `?RequestInit \| (() => RequestInit)` |Additional `fetchOptions` that `fetch` in `fetchExchange` should use to make a request. | 200 + | fetchOptions | `?RequestInit \| (() => RequestInit)` | Additional `fetchOptions` that `fetch` in `fetchExchange` should use to make a request. | 201 201 | fetch | `typeof fetch` | An alternative implementation of `fetch` that will be used by the `fetchExchange` instead of `window.fetch` | 202 202 | requestPolicy | `RequestPolicy` | An optional [request policy](/basics/querying-data#request-policy) that should be used specifying the cache strategy. | 203 203 | url | `string` | The GraphQL endpoint | ··· 231 231 | Input | Type | Description | 232 232 | ------- | ------------ | ----------------------------------------------------------------------------------------------------------------------- | 233 233 | forward | `ExchangeIO` | The unction responsible for receiving an observable operation and returning a result | 234 - | client | `Client` | The URQL application-wide client library. Each execute method starts a GraphQL request and returns a stream of results. | 234 + | client | `Client` | The urql application-wide client library. Each execute method starts a GraphQL request and returns a stream of results. | 235 235 236 236 ### Exchange 237 237 ··· 334 334 ### stringifyVariables 335 335 336 336 This function is a variation of `JSON.stringify` that sorts any object's keys that is being 337 - stringified to ensure that two objects with a different order of keys will be stabily stringified to 337 + stringified to ensure that two objects with a different order of keys will be stably stringified to 338 338 the same string. 339 339 340 340 ```js

+5 -5

docs/api/graphcache.md

··· 415 415 Accepts a single object of optional options and returns a resolver that can be inserted into the 416 416 [`cacheExchange`'s](#cacheexchange) [`resolvers` configuration.](#resolvers-option) 417 417 418 - | Argument | Type | Description | 419 - | -------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 420 - | offsetArgument | `?string` | The field arguments's property, as passed to the resolver, that contains the current offset, i.e. the number of items to be skipped. Defaults to `'skip'`. | 421 - | limitArgument | `?string` | The field arguments's property, as passed to the resolver, that contains the current page size limit, i.e. the number of items on each page. Defaults to `'limit'`. | 418 + | Argument | Type | Description | 419 + | -------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 420 + | offsetArgument | `?string` | The field arguments' property, as passed to the resolver, that contains the current offset, i.e. the number of items to be skipped. Defaults to `'skip'`. | 421 + | limitArgument | `?string` | The field arguments' property, as passed to the resolver, that contains the current page size limit, i.e. the number of items on each page. Defaults to `'limit'`. | 422 422 423 423 Once set up, the resulting resolver is able to automatically concatenate all pages of a given field 424 424 automatically. Queries to this resolvers will from then on only return the infinite, combined list ··· 434 434 435 435 | Argument | Type | Description | 436 436 | --------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 437 - | mergeMode | `'outwards' \| 'inwards'` | With Relay pagination, pages can be queried forwards and backwards using `after` and `before` cursors. This option defines whether pages that have been quiered backwards should be concatenated before (outwards) or after (inwards) all pages that have been queried forwards. | 437 + | mergeMode | `'outwards' \| 'inwards'` | With Relay pagination, pages can be queried forwards and backwards using `after` and `before` cursors. This option defines whether pages that have been queried backwards should be concatenated before (outwards) or after (inwards) all pages that have been queried forwards. | 438 438 439 439 Once set up, the resulting resolver is able to automatically concatenate all pages of a given field 440 440 automatically. Queries to this resolvers will from then on only return the infinite, combined list

+1 -1

docs/basics/errors.md

··· 23 23 24 24 ![Combined errors](../assets/urql-combined-error.png) 25 25 26 - It's worth noting that an `error` can coexit and be returned in a successful request alongside 26 + It's worth noting that an `error` can coexist and be returned in a successful request alongside 27 27 `data`. This is because in GraphQL a query can have partially failed but still contain some data. 28 28 In that case `CombinedError` will be passed to us with `graphQLErrors`, while `data` may still be 29 29 set.

+1 -1

docs/concepts/core-package.md

··· 16 16 ## Background 17 17 18 18 The ["Philosophy"](./philosophy.md) page explains how `urql` solves some of problems encountered when different aspects 19 - of having a GraphQL client handle declarative querying and being a central point of extensibiliy. 19 + of having a GraphQL client handle declarative querying and being a central point of extensibility. 20 20 21 21 By extension there are three parts of `urql` you'll come in contact with when you add it to your 22 22 app:

+3 -3

docs/concepts/exchanges.md

··· 44 44 45 45 The first parameter to an exchange is a `forward` function that refers to the next Exchange in the 46 46 chain. The second second parameter is the `Client` being used. Exchanges always return an `ExchangeIO` 47 - function (this applies to the `forward` funtion as well), which accepts the source of 47 + function (this applies to the `forward` function as well), which accepts the source of 48 48 [_Operations_](../api/core.md#operation) and returns a source of [_Operation 49 49 Results_](../api/core.md#operationresult). 50 50 ··· 54 54 ## Using Exchanges 55 55 56 56 The `Client` accepts an `exchanges` option that defaults to the three default exchanges mentioned above. When we pass a custom list of exchanges the `Client` uses the `composeExchanges` 57 - utiliy, which starts chaining these exchanges. 57 + utility, which starts chaining these exchanges. 58 58 59 59 In essence these exchanges build a pipeline that runs in the order they're passed; _Operations_ flow 60 60 in from the start to the end, and _Results_ are returned through the chain in reverse. ··· 63 63 `fetchExchange` — an incoming operation is treated as follows: 64 64 65 65 **First,** ongoing operations are deduplicated. It wouldn't make sense to send the 66 - same operation / request twice in parralel. 66 + same operation / request twice in parallel. 67 67 68 68 **Second,** operations are checked against the cache. Depending on the `requestPolicy`, 69 69 cached results can be resolved instead and results from network requests are cached.

+2 -2

docs/concepts/philosophy.md

··· 32 32 }); 33 33 ``` 34 34 35 - In `urql`, the client is the first step towards manging the complexity of GraphQL automatically. 35 + In `urql`, the client is the first step towards managing the complexity of GraphQL automatically. 36 36 37 37 ## Using GraphQL Clients 38 38 ··· 93 93 94 94 ## Extensibility and Integration 95 95 96 - With any kind of API there can be concerns outside of caching and state mangagement. For example, 96 + With any kind of API there can be concerns outside of caching and state management. For example, 97 97 the global behavior or business logic of your application. For instance, you may want to add authentication, retry-logic for failed requests, or a global 98 98 error handler. 99 99

+1 -1

exchanges/graphcache/help.md

··· 2 2 3 3 **This document lists out all errors and warnings in `@urql/exchange-graphcache`.** 4 4 5 - Any unexpected behaviour, conditon, or error will be marked by an error or warning 5 + Any unexpected behaviour, condition, or error will be marked by an error or warning 6 6 in development, which will output a helpful little message. Sometimes however, this 7 7 message may not actually tell you everything about what's going on. 8 8

+1 -1

packages/core/src/client.test.ts

··· 1 1 import { print } from 'graphql'; 2 2 import gql from 'graphql-tag'; 3 3 4 - /** NOTE: Testing in this file is designed to test both the client and it's interaction with default Exchanges */ 4 + /** NOTE: Testing in this file is designed to test both the client and its interaction with default Exchanges */ 5 5 6 6 import { map, pipe, subscribe, filter, toArray, tap } from 'wonka'; 7 7 import { Exchange, Operation, OperationResult } from './types';

+1 -1

packages/site/src/screens/home/_content.js

··· 35 35 media: '', 36 36 }, 37 37 getStarted: { 38 - description: `With it's intiuitive set of lightweight API's, getting started with urql is a breeze. Dive into the documentation to get up and running in minutes.`, 38 + description: `With its intuitive set of lightweight API's, getting started with urql is a breeze. Dive into the documentation to get up and running in minutes.`, 39 39 link: '/docs', 40 40 }, 41 41 oss: [

Configure Feed

Configure Feed