Repository navigation
Teach WarpDrive schemas in PolarisMode in chapter 11 - #296
Draft
NullVoxPopuli-ai-agent wants to merge 5 commits into
Draft
NullVoxPopuli-ai-agent wants to merge 5 commits into
NullVoxPopuli-ai-agent wants to merge 5 commits into
Conversation
Add a `main` channel to the Build matrix. It uses the alpha ember-cli and app blueprint, then installs the latest ember-source build of ember.js main. ember.js CI uploads that build to builds.emberjs.com, and canary.json points to it. A hidden step after `ember new` installs the tarball when EMBER_SOURCE_TARBALL is set. Other channels do not set it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add an `ember-source` input to workflow_dispatch. It takes a full ember.js commit SHA or a tarball URL. A SHA maps to its build on builds.emberjs.com. If the input is empty, the main channel uses the latest build, as before. The step checks that the tarball exists, so a SHA with no build stops the job before the slow steps. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Chapter 11 now defines the rental type with a schema from `@warp-drive/core/reactive`. The `type` getter becomes a derived field with a registered derivation. The store uses `useRecommendedStore`, and the chapter removes `@warp-drive/legacy`. The model test becomes a schema test in `tests/unit/schemas/`. The `model-test` generator comes from the legacy package, so the chapter creates the file directly. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 26, 2026
| ## The Store Service | ||
|
|
||
| ## Testing Models | ||
| EmberData provides a `store` *[service](../../../services/)*, also known as the EmberData store. The store needs to know about our schema and our derivation before it can create rental records. The default blueprint generated an `app/services/store.js` file for us. Let's replace its contents: |
Contributor
There was a problem hiding this comment.
Suggested change
| EmberData provides a `store` *[service](../../../services/)*, also known as the EmberData store. The store needs to know about our schema and our derivation before it can create rental records. The default blueprint generated an `app/services/store.js` file for us. Let's replace its contents: | |
| WarpDrive provides a `store` *[service](../../../services/)*. The store needs to know about our schema and our derivation before it can create rental records. The default blueprint generated an `app/services/store.js` file for us. Let's replace its contents: |
| ``` | ||
|
|
||
| EmberData offers many, many features (like managing the *relationships* between different models) and there's a lot more we can learn about it. For example, if your backend's have some inconsistencies across different endpoints, EmberData allows you to define request specific handlers and builders! We are just scratching the surface here. If you want to learn more about EmberData, check out [its own dedicated section](../../../models/) in the guides! | ||
| EmberData offers many, many features (like managing the *relationships* between different types of records) and there's a lot more we can learn about it. For example, if your backend's have some inconsistencies across different endpoints, EmberData allows you to define request specific handlers and builders! We are just scratching the surface here. If you want to learn more about EmberData, check out [its own dedicated section](../../../models/) in the guides! |
Contributor
There was a problem hiding this comment.
Suggested change
| EmberData offers many, many features (like managing the *relationships* between different types of records) and there's a lot more we can learn about it. For example, if your backend's have some inconsistencies across different endpoints, EmberData allows you to define request specific handlers and builders! We are just scratching the surface here. If you want to learn more about EmberData, check out [its own dedicated section](../../../models/) in the guides! | |
| WarpDrive offers many, many features (like managing the *relationships* between different types of records) and there's a lot more we can learn about it. For example, if your backend's have some inconsistencies across different endpoints, WarpDrive allows you to define request specific handlers and builders! We are just scratching the surface here. If you want to learn more about WarpDrive, check out [its own dedicated section](../../../models/) in the guides! |
| We can access these attributes on a rental record using standard dot notation, such as `rental.title` or `rental.location.lat`. In addition to the fields we declared here, there will always be an *id* field as well, which is used to uniquely identify the record and can be accessed using `rental.id`. | ||
|
|
||
| Model classes in EmberData are no different than any other classes we've worked with so far, in that they allow for a convenient place for adding custom behavior. We took advantage of this feature to move our `type` logic (which is a major source of unnecessary duplication in our route handlers) into a getter on our model class. Once we have everything working here, we will go back to clean that up. | ||
| Since a schema does not contain code, we cannot add a getter to it the way we would with a class. Instead, we declared `type` as a `derived` field. When we read `rental.type`, EmberData calls the `rentalType` *[derivation](https://warp-drive.io/guides/the-manual/schemas/derivations)* function with the record and returns its result. We took advantage of this feature to move our `type` logic (which is a major source of unnecessary duplication in our route handlers) into one place. Once we have everything working here, we will go back to clean that up. |
There was a problem hiding this comment.
Hey @NullVoxPopuli, I am noticing something about how this paragraph is phrased. It sounds like an artifact of the former class-based Model, it says that "if it had been class-based we could have used a getter", which make it sounds a bit like something is missing from the concept of Schema and we need to workaround it.
Woudn't it be better to explain what type is conceptually, and why a Derivation is the best way to implement this property in Schema world?
Contributor
There was a problem hiding this comment.
it would! thank you!
Contributor
Author
There was a problem hiding this comment.
Thank you, @BlueCutOfficial. 736c88b rewrites the paragraph. It now says that the server does not send type, that type comes from category, and that a derived field is how a schema holds a value like that. The comparison with a class getter is gone.
Apply the review suggestions that name WarpDrive for the store service and the closing paragraph. The derived field paragraph now explains what type is and why a derivation fits, instead of comparing schemas to model classes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Rename EmberData to WarpDrive in the chapter text, headings, the part 2 index and the recap. The Zoey note keeps the old name, so that readers can match it to older guides and addons. The chapter URL stays ember-data, so existing links keep working. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Chapter 11 now uses WarpDrive in PolarisMode and nothing from
@warp-drive/legacy.What changes for the reader:
app/models/rental.jsbecomesapp/schemas/rental.js. It has awithDefaultsschema from@warp-drive/core/reactive.typegetter becomes aderivedfield with a registeredrentalTypederivation.app/services/store.jsusesuseRecommendedStorefrom@warp-drive/core, with the schema and the derivation.tests/unit/schemas/rental-test.js. The chapter creates it directly, because themodel-testgenerator comes from@warp-drive/legacy.@warp-drive/legacywhen the blueprint installed it.Why this PR needs the others:
LinkTo. Without [BUGFIX beta] LinkTo: do not read unknown properties from models emberjs/ember.js#21771, PolarisMode records throwNo field named isQueryParams on rental.ember-sourcemain. The blueprint store imports@warp-drive/legacy, which uses deprecated computed macros.Tests: I ran
CI=true pnpm generatelocally againstember-source7.4.0 with the #21771 fix added. The whole tutorial passed, andpnpm lint:md:distpassed. CI stays red until #21771 is in a releasedember-sourceand #338 is in the alpha blueprint.Thanks to @BlueCutOfficial (Marine Dunstetter) for the WarpDrive migration guide in ember-learn/guides-source#2246 and the Mainmatter posts that walk Super Rentals to WarpDrive (part 1, part 2). This chapter continues from that path to PolarisMode.
PolarisMode tutorial PRs
Merge in this order:
ember-sourcemain.<LinkTo @model={{record}}>with PolarisMode records.useRecommendedStorewithout@warp-drive/legacy.Related:
@warp-drive/legacy(merged).🤖 Generated with Claude Code