feat: pagination data utils

.github/workflows/release_publish-beta.yml

@@ -72,7 +72,7 @@ jobs:
         run: echo "value=$(bun --silent release latest beta)" >> $GITHUB_OUTPUT
       - name: Publish New Release
         # For beta-cycle we always increment from the branch state
-        # For mirror we increment from the last beta version, unless it's start of a new cycle.
+        # For mirror we increment from the last beta version, unless it is start of a new cycle.
         if: github.event.inputs.kind == 'beta-cycle' || github.event.inputs.is-cycle-start == 'true'
         run: bun release exec publish beta
         env:

CHANGELOG.md

@@ -3515,7 +3515,7 @@ methods.
 - add documentation for the Store's find method
 - Do not double include the host when it uses a protocol relative url.
 - Deprecate RecordArray.pushRecord()
-- Wrap the errorThrown in an Error object if it's a string.
+- Wrap the errorThrown in an Error object if it is a string.
 - Use forEach instead of private api for accessing Map values
 - Disable unknown keys warning by default
 - remove type check for addCanonicalRecord in belongsto relationship
@@ -3617,7 +3617,7 @@ export default DS.RESTSerializer.extend({
 
 ##### `store.metaForType()` has been deprecated
 
-`store.metaForType()` has been deprecated because of it's ambiguous naming.
+`store.metaForType()` has been deprecated because of it is ambiguous naming.
 Please use `store.metadataFor()` to get metadata and `store.setMetadataFor()`
 to set metadata.
 
@@ -3935,7 +3935,7 @@ correctly will need a shim for Object.create.
 - Update ember version to 1.4.0
 - lock server while compiling assets
 - [DOC] Fix extractArray
-- Don't pass the resolver where it's not needed
+- Don't pass the resolver where it is not needed
 - force jshint on failure
 - explicitly set a handlebars dependency to a version known to work.
 - Remove Dead Code from RESTAdapter's Test

README.md

@@ -68,13 +68,13 @@ Wrangle your application's data management with scalable patterns for developer
 
 ## 🪜 Architecture
 
-*Ember***Data** is both _resource_ centric and _document_ centric in it's approach to caching, requesting and presenting data. Your application's configuration and usage drives which is important and when.
+*Ember***Data** is both _resource_ centric and _document_ centric in its approach to caching, requesting and presenting data. Your application's configuration and usage drives which is important and when.
 
 The `Store` is a **coordinator**. When using a `Store` you configure what cache to use, how cache data should be presented to the UI, and where it should look for requested data when it is not available in the cache.
 
 This coordination is handled opaquely to the nature of the requests issued and the format of the data being handled. This approach gives applications broad flexibility to configure *Ember***Data** to best suit their needs. This makes *Ember***Data** a powerful solution for applications regardless of their size and complexity.
 
-*Ember***Data** is designed to scale, with a religious focus on performance and asset-size to keep its footprint small but speedy while still being able to handle large complex APIs in huge data-driven applications with no additional code and no added application complexity. It's goal is to prevent applications from writing code to manage data that is difficult to maintain or reason about.
+*Ember***Data** is designed to scale, with a religious focus on performance and asset-size to keep its footprint small but speedy while still being able to handle large complex APIs in huge data-driven applications with no additional code and no added application complexity. Its goal is to prevent applications from writing code to manage data that is difficult to maintain or reason about.
 
 *Ember***Data**'s power comes not from specific features, data formats, or adherence to specific API specs such as `JSON:API` `trpc` or `GraphQL`, but from solid conventions around requesting and mutating data developed over decades of experience scaling developer productivity.
 

ROADMAP.md

@@ -88,7 +88,7 @@ Comprehensive DX around data management should extend to testing. We're thinking
 
 Currently, frontend mocking solutions typically rely on either mocking in the browser's ui-thread, or via ServiceWorker. Both of these present major downsides.
 
-The ui-thread approach slows down test suite performance with high alloc, compute and gc costs. It's also much more difficult to debug due to circumventing the browser's built in tooling for inspecting requests, and less accurate because responses don't behave the same way or with the same timing as they would for a real request. The mix of generating similar looking API mocks and client side data in the same test or test module causes many devs to accidentally mix paradigms, and the difficulty in disocvering what you've mocked and what its state is regularly leads to over-mocking. Finally, it allows devs to often accidentally share object state in their test between the ui and the api which leads to difficult to reason about bugs.
+The ui-thread approach slows down test suite performance with high alloc, compute and gc costs. it is also much more difficult to debug due to circumventing the browser's built in tooling for inspecting requests, and less accurate because responses don't behave the same way or with the same timing as they would for a real request. The mix of generating similar looking API mocks and client side data in the same test or test module causes many devs to accidentally mix paradigms, and the difficulty in disocvering what you've mocked and what its state is regularly leads to over-mocking. Finally, it allows devs to often accidentally share object state in their test between the ui and the api which leads to difficult to reason about bugs.
 
 The MSW approach solves many of the problems of the ui-thread approach, but introduces problems of its own. Developers must now carefully uninstall the service worker when changing between apps they are developing that usually run on the same domain, it intercepts even for dev when it ought to be used only for tests, it interferes with using the ServiceWorker for actual application needs, and it lacks privileged access to the file system to cache state for reuse to optimize performance of repeat test runs.
 

guides/cookbook/naming-conventions.md

@@ -44,7 +44,7 @@ What does consistency look like?
 
 ### But what about JSON:API spec?
 
-It's pretty simple, JSON:API spec agnostic about the `type` field convention. Here is the quote from the spec:
+It is pretty simple, JSON:API spec agnostic about the `type` field convention. Here is the quote from the spec:
 
 > Note: This spec is agnostic about inflection rules, so the value of type can be either plural or singular. However, the same value should be used consistently throughout an implementation.
 

guides/relationships/configuration/2-one-to-many.md

@@ -59,7 +59,7 @@ graph LR;
 With distinct relationships, we may edit one side without affecting the state of the inverse. This is particularly useful
 in two situations.
 
-First, it may be the case that the user has thousands or tens of thousands of activities. In this case, you likely don't want whichever individual activities you happen to load to create an incomplete list of the TrailRunner's activities. It's better to load and work with the activities list in isolation, ideally in a paginated manner.
+First, it may be the case that the user has thousands or tens of thousands of activities. In this case, you likely don't want whichever individual activities you happen to load to create an incomplete list of the TrailRunner's activities. It is better to load and work with the activities list in isolation, ideally in a paginated manner.
 
 Second, it may be the case that runner is able to share the activity data with another runner that forgot to record. By not coupling the relationship, the ActivityData can still be owned by the first runner by included in the second runner's list of activities as well.
 

guides/requests/index.md

@@ -24,7 +24,7 @@ const users = userList.content;
 
 ### Making Requests
 
-`RequestManager` has a single asynchronous method as it's API: `request`
+`RequestManager` has a single asynchronous method as its API: `request`
 
 ```ts
 class RequestManager {

packages/-ember-data/README.md

@@ -66,13 +66,13 @@ Wrangle your application's data management with scalable patterns for developer
 
 ## 🪜 Architecture
 
-*Ember***Data** is both _resource_ centric and _document_ centric in it's approach to caching, requesting and presenting data. Your application's configuration and usage drives which is important and when.
+*Ember***Data** is both _resource_ centric and _document_ centric in its approach to caching, requesting and presenting data. Your application's configuration and usage drives which is important and when.
 
 The `Store` is a **coordinator**. When using a `Store` you configure what cache to use, how cache data should be presented to the UI, and where it should look for requested data when it is not available in the cache.
 
 This coordination is handled opaquely to the nature of the requests issued and the format of the data being handled. This approach gives applications broad flexibility to configure *Ember***Data** to best suite their needs. This makes *Ember***Data** a powerful solution for applications regardless of their size and complexity.
 
-*Ember***Data** is designed to scale, with a religious focus on performance and asset-size to keep its footprint small but speedy while still being able to handle large complex APIs in huge data-driven applications with no additional code and no added application complexity. It's goal is to prevent applications from writing code to manage data that is difficult to maintain or reason about.
+*Ember***Data** is designed to scale, with a religious focus on performance and asset-size to keep its footprint small but speedy while still being able to handle large complex APIs in huge data-driven applications with no additional code and no added application complexity. Its goal is to prevent applications from writing code to manage data that is difficult to maintain or reason about.
 
 *Ember***Data**'s power comes not from specific features, data formats, or adherence to specific API specs such as `JSON:API` `trpc` or `GraphQL`, but from solid conventions around requesting and mutating data developed over decades of experience scaling developer productivity.
 

packages/-ember-data/src/index.ts

@@ -44,13 +44,13 @@ Wrangle your application's data management with scalable patterns for developer
 The core of *Ember*‍**Data** is the `Store`, which coordinates interaction between your application, the `Cache`, and sources of data (such as your `API` or a local persistence layer).
 Optionally, the Store can be configured to hydrate the response data into rich presentation classes.
 
-*Ember*‍**Data** is both resource centric and document centric in it's approach to caching, requesting and presenting data. Your application's configuration and usage drives which is important and when.
+*Ember*‍**Data** is both resource centric and document centric in its approach to caching, requesting and presenting data. Your application's configuration and usage drives which is important and when.
 
 The `Store` is a **coordinator**. When using a `Store` you configure what cache to use, how cache data should be presented to the UI, and where it should look for requested data when it is not available in the cache.
 
 This coordination is handled opaquely to the nature of the requests issued and the format of the data being handled. This approach gives applications broad flexibility to configure *Ember*‍**Data** to best suite their needs. This makes *Ember*‍**Data** a powerful solution for applications regardless of their size and complexity.
 
-*Ember*‍**Data** is designed to scale, with a religious focus on performance and asset-size to keep its footprint small but speedy while still being able to handle large complex APIs in huge data-driven applications with no additional code and no added application complexity. It's goal is to prevent applications from writing code to manage data that is difficult to maintain or reason about.
+*Ember*‍**Data** is designed to scale, with a religious focus on performance and asset-size to keep its footprint small but speedy while still being able to handle large complex APIs in huge data-driven applications with no additional code and no added application complexity. Its goal is to prevent applications from writing code to manage data that is difficult to maintain or reason about.
 
 *Ember*‍**Data**'s power comes not from specific features, data formats, or adherence to specific API specs such as `JSON:API` `trpc` or `GraphQL`, but from solid conventions around requesting and mutating data developed over decades of experience scaling developer productivity.
 

packages/adapter/src/rest.ts

@@ -203,7 +203,7 @@ declare const jQuery: JQueryStatic | undefined;
   ```
 
   If the records in the relationship are not known when the response
-  is serialized it's also possible to represent the relationship as a
+  is serialized it is also possible to represent the relationship as a
   URL using the `links` key in the response. Ember Data will fetch
   this URL to resolve the relationship when it is accessed for the
   first time.
@@ -1468,12 +1468,12 @@ export function fetchOptions(
     } else {
       // NOTE: a request's body cannot be an object, so we stringify it if it is.
       // JSON.stringify removes keys with values of `undefined` (mimics jQuery.ajax).
-      // If the data is not a POJO (it's a String, FormData, etc), we just set it.
-      // If the data is a string, we assume it's a stringified object.
+      // If the data is not a POJO (it is a String, FormData, etc), we just set it.
+      // If the data is a string, we assume it is a stringified object.
 
       /* We check for Objects this way because we want the logic inside the consequent to run
        * if `options.data` is a POJO, not if it is a data structure whose `typeof` returns "object"
-       * when it's not (Array, FormData, etc). The reason we don't use `options.data.constructor`
+       * when it is not (Array, FormData, etc). The reason we don't use `options.data.constructor`
        * to check is in case `data` is an object with no prototype (e.g. created with null).
        */
       if (Object.prototype.toString.call(options.data) === '[object Object]') {

packages/build-config/src/deprecation-versions.ts

@@ -30,7 +30,7 @@
  * 3.13 as its minimum version compatibility, any deprecations introduced before
  * or during 3.13 would be stripped away.
  *
- * An app can use a different version than what it specifies as it's compatibility
+ * An app can use a different version than what it specifies as its compatibility
  * version. For instance, an App could be using `3.16` while specifying compatibility
  * with `3.12`. This would remove any deprecations that were present in or before `3.12`
  * but keep support for anything deprecated in or above `3.13`.

packages/codemods/src/legacy-compat-builders/legacy-store-method.ts

@@ -152,7 +152,7 @@ export function transformLegacyStoreMethod(
           ],
         });
       } else if (j.ReturnStatement.check(path.parent.parent.value)) {
-        // It's not assigned to a variable so we don't need to worry about destructuring
+        // It is not assigned to a variable so we don't need to worry about destructuring
         // but we do need to make sure the value stays the same, so:
         // Wrap the whole await expression in a MemberExpression to add `.content`
         const memberExpression = j.memberExpression.from({

packages/core-types/src/record.ts

@@ -129,7 +129,7 @@ type _ExtractUnion<
  * to allow for other strategies.
  *
  * There's a 90% chance this particular implementation belongs being in the JSON:API package instead
- * of core-types, but it's here for now.
+ * of core-types, but it is here for now.
  *
  * @typedoc
  */

packages/diagnostic/server/reporters/default.js

@@ -529,7 +529,7 @@ export default class CustomDotReporter {
 }
 
 // Instead of completely removing, we replace the contents with an empty string so that CI will still cache it.
-// While this shouldn't ever really be necessary it's a bit more correct to make sure that the log gets cleared
+// While this shouldn't ever really be necessary it is a bit more correct to make sure that the log gets cleared
 // in the cache as well.
 function remove(filePath) {
   fs.writeFileSync(filePath, '', { encoding: 'utf-8' });

packages/diagnostic/src/-ember/is-component.ts

@@ -10,7 +10,7 @@ export type ComponentLike = object;
  * (see https://github.com/emberjs/rfcs/pull/785 for more info).
  * @private
  * @param {Object} maybeComponent The thing you think might be a component
- * @returns {boolean} True if it's a component, false if not
+ * @returns {boolean} True if it is a component, false if not
  */
 function isComponent(maybeComponent: object): maybeComponent is ComponentLike {
   return !!(getComponentManager as (c: object, v: boolean) => object)(maybeComponent, true);