Straight -> curly quotes

Author: lorensr

text/6.md

@@ -4319,13 +4319,13 @@ Section contents:
 
 Our `ReviewsQuery` currently has `limit: 20` because loading all the reviews would be unwise 😄. We don’t know how many reviews there will be in the database, and receiving thousands of them over the network would take a long time on mobile. They’d take a lot of memory in the Apollo store, they’d take a long time to render onto the page, and we’d have the problems that come along with a high DOM (and VDOM) node count: interacting with the DOM takes longer, and the amount of memory the browser uses grows—in the worst case, it exceeds the available memory on the device. On mobile, the OS kills the browser process, and on a computer, the OS starts using the hard drive for memory, which is very slow.
 
-😅 So! In any app where the user might want to see a potentially long list of data, we paginate: we request and display a set amount of data, and when the user wants more (either by scrolling down—in the case of infinite scroll—or by clicking a "next page" link or "page 3" link), we request and display more. There are two main methods of pagination: offset-based, which we’ll talk about first, and [cursors](#cursors). 
+😅 So! In any app where the user might want to see a potentially long list of data, we paginate: we request and display a set amount of data, and when the user wants more (either by scrolling down—in the case of infinite scroll—or by clicking a “next page” link or “page 3” link), we request and display more. There are two main methods of pagination: offset-based, which we’ll talk about first, and [cursors](#cursors). 
 
 We can display the data however we want. The two most common methods are pages (with next/previous links and/or numbered page links like Google search results) and infinite scroll. We can use either data-fetching method with either display method.
 
 ### Offset-based
 
-Offset-based pagination is the easier of the two methods to implement—both on the client and on the server. In its simplest form, we request a `page` number, and each page has a set number of items. The Guide server sends 10 items per page, so page 1 has the first 10, page 2 has items 11-20, etc. A more flexible form is using two parameters: `offset` (or `skip`) and `limit`. The client decides how large each page is by setting the `limit` of how many items the server should return. For instance, we can have 20-item pages by first requesting `skip: 0, limit: 20`, then requesting `skip: 20, limit: 20` ("give me 20 items starting with #20", so items 20-39), then `skip: 40, limit: 20`, etc.
+Offset-based pagination is the easier of the two methods to implement—both on the client and on the server. In its simplest form, we request a `page` number, and each page has a set number of items. The Guide server sends 10 items per page, so page 1 has the first 10, page 2 has items 11-20, etc. A more flexible form is using two parameters: `offset` (or `skip`) and `limit`. The client decides how large each page is by setting the `limit` of how many items the server should return. For instance, we can have 20-item pages by first requesting `skip: 0, limit: 20`, then requesting `skip: 20, limit: 20` (“give me 20 items starting with #20”, so items 20-39), then `skip: 40, limit: 20`, etc.
 
 The downside of offset-based pagination is that if the list is modified between requests, we might miss items or see them twice. Take, for example, this scenario: