kitten.sh
+207
-51
docs/basics/core.md
+207
-51
docs/basics/core.md
···all exports of our `@urql/core` core library. This means that if we want to use `urql`'s `Client`···-When you're using `urql` to send one-off queries or mutations — rather than in full framework code,-This may be useful when we don't plan on cancelling queries or we don't care about future updates to-`client.executeQuery` and unsubscribes immediately. If a result is available in the cache it will be-resolved synchronously prior to the unsubscribe. If not, the query is cancelled and no request will be sent to the GraphQL API.-Wherever `urql` accepts a query document, you may either pass a string or a `DocumentNode`. `gql` isa utility that allows a `DocumentNode` to be created directly, and others to be interpolated intoit, which is useful for fragments for instance. This function will often also mark GraphQL documents···
···all exports of our `@urql/core` core library. This means that if we want to use `urql`'s `Client`+In other words, if we're using framework bindings then writing `import { Client } from "@urql/vue"`+As we said above, if we are using bindings then those will already have installed `@urql/core` as+they depend on it. They also all re-export all exports from `@urql/core`, so we can use those no···+Since all bindings and all exchanges depend on `@urql/core`, we may sometimes run into problems+where the package manager installs _two versions_ of `@urql/core`, which is a duplication problem.+Wherever `urql` accepts a query document, we can either pass a string or a `DocumentNode`. `gql` isa utility that allows a `DocumentNode` to be created directly, and others to be interpolated intoit, which is useful for fragments for instance. This function will often also mark GraphQL documents···+identical and the output is approximately the same. The two packages are also intercompatible.+However, one small change that `@urql/core`'s implementation makes is that your fragment names don't+have to be globally unique, since it's possible to create some one-off fragments every now and then.+It also pre-generates a "hash key" for the `DocumentNode` which is what `urql` does anyway, thus+framework bindings and from the other pages in the "Basics" section we can see that creating a+create the GraphQL client. This central `Client` manages all of our GraphQL requests and results.+At the bare minimum we'll need to pass an API's `url` when we create a `Client` to get started.+Another common option is `fetchOptions`. This option allows us to customize the options that will be+passed to `fetch` when a request is sent to the given API `url`. We may pass in an options object or+In the following example we'll add a token to each `fetch` request that our `Client` sends to our+This option passes a list of exchanges to the `Client`, which tell it how to execute our requests+Later, [in the "Advanced" section](../advanced/README.md) we'll see many more features that `urql`+supports by adding new exchanges to this list. On [the "Architecture" page](../architecture.md)+exchanges in order. First, the `dedupExchange` deduplicates requests if we send the same queries+twice, the `cacheExchange` implements the default "document caching" behaviour (as we'll learn about+When you're using `urql` to send one-off queries or mutations — rather than in full framework code,+In the above example we're executing a query on the client, are passing some variables and are+calling the `toPromise()` method on the return value to execute the request immediately and get the+Similarly there's a way to read data from the cache synchronously, provided that the cache has+In the above example we call `readQuery` and receive a result immediately. This result will be+GraphQL Clients are by their nature "reactive", meaning that when we execute a query, we expect to+get future results for this query. [On the "Document Caching" page](./document-caching.md) we'll+learn how mutations can invalidate results in the cache. This process (and others just like it) can+In essence, if we're subscribing to results rather than using a promise, like we've seen above, then+somewhere else then we'll get notified of the new API result as well, as long as we're subscribed.+This code example is similar to the one before. However, instead of sending a one-off query, we're+subscription means that our callback may be called repeatedly. We may get future results as well as+immediately if our cache already has a result for the given query. The same principle applies here!+Once we're not interested in any results anymore we need to clean up after ourselves by calling+`unsubscribe`. This stops the subscription and makes sure that the `Client` doesn't actively update+the query anymore or refetches it. We can think of this pattern as being very similar to events or+We're using [the Wonka library for our streams](https://wonka.kitten.sh/basics/background) which+we'll learn more about [on the "Architecture" page](./architecture.md). But we can think of this as