{"data":[{"id":"28","type":"series","links":{"self":"https://embermap.com/api/v1/series/28"},"attributes":{"title":"Converting to Octane: First Look","subtitle":"Learn how to convert classic Ember code to native JS and Octane APIs","slug":"converting-to-octane-first-look","position":2,"description":"Learn how to convert classic Ember code to native JS and Octane APIs.","poster-s3-key":"public/images/903b1671-738b-43d6-b7b5-40a79b6d23dd/series-poster.png","featured-poster-image-key":null,"square-poster-image-key":null,"gradient-primary":"#2A2D34","gradient-secondary":"#181A1F"},"relationships":{"clips":{"links":{"self":"https://embermap.com/api/v1/series/28/relationships/clips","related":"https://embermap.com/api/v1/series/28/clips"},"data":[{"type":"clips","id":"612"},{"type":"clips","id":"577"},{"type":"clips","id":"578"},{"type":"clips","id":"613"}]}}}],"included":[{"id":"612","type":"clips","links":{"self":"https://embermap.com/api/v1/clips/612"},"attributes":{"title":"Converting an Ember Component to a Glimmer Component, Part 1","poster-s3-key":"public/images/45b13574-9104-4449-b5af-444c81c020af/first-look-3.png","featured-poster-image-key":null,"published-at":"2021-01-07T21:47:44.713Z","position":3,"viewing-requirement":"none","live":true,"coming-soon":false,"duration":717,"description":"Learn the basics needed to convert an Ember native class component to a Glimmer component.","summary":"In this video we convert an Ember component using native class syntax into a Glimmer component. This will involve:\n\n- How to actually use Glimmer to make your component\n- Removing the wrapper tag\n- Replacing the `didInsertElement` lifecycle hook\n- Updating the component argument syntax:\n - using `@` in template\n - using `this.args` in JavaScript files\n - no implicit `this`\n\n### How to use Glimmer to make your component\nTo use Glimmer to render components, import `Component` from `@glimmer/component` rather than `@ember/component`:\n\n```js\nimport Component from '@glimmer/component'\n```\n\n### Removing the wrapper tag\nGlimmer components do not have wrapper elements, so we no longer need to define any `tagNames` in our JavaScript file. Instead, we can put any HTML tag we want directly in our template.\n\nNext we need to update the `didInsertElement` hook. This lifecycle hook is not supported in Glimmer components. To replace logic that happens in `didInsertElement`, we can use the `did-insert` modifier from the [`ember-render-modifiers`](https://github.com/emberjs/ember-render-modifiers) addon.\n\n\n### Updating the component argument syntax\nAn important thing to understand about Glimmer components is that passed-in arguments are referred to differently than internal properties.\n\nProperties that are passed into your component are now immutable. You can't change them and you can't overwrite them. For this reason, the syntax you use to refer to passed-in arguments in your components is different in both your JavaScript and template files.\n\nIn a JavaScript file, you use the `args` object to reference a passed-in argument. In a template file, you use the `@` sign (instead of `this`) to reference a passed-in argument. For more information about this, check out the video or see the official migration [cheat](https://ember-learn.github.io/ember-octane-vs-classic-cheat-sheet/#component-properties__args) [sheet](https://ember-learn.github.io/ember-octane-vs-classic-cheat-sheet/#component-templates__template-named). \n\nIf you do not prefix your external props with this syntax, your component will not read the correct values and it will break.\n\n### No implicit this\nFinally, updating components to use Glimmer changes the relationship the component has with `this`. In a Glimmer world, `this` is reserved for properties defined directly on the component object. This idea is called `no-implicit-this` and can be enforced with a linter rule of the same name with [`ember-template-lint`](https://github.com/ember-template-lint/ember-template-lint/blob/master/docs/rule/no-implicit-this.md).\nWhile not technically required in current versions of Ember, it is considered good practice to follow and `implicit-this` will be deprecated in Ember 4. If you need to convert your whole app away from `implicit-this` there is a [codemod](https://github.com/ember-codemods/ember-no-implicit-this-codemod) that will do most of the work for you.\n\nHere's the diff of all these changes applied to our files:\n\n```diff\n// app/components/comments.js\nimport {tagName} from '@ember-decorators/component';\nimport {action, computed} from '@ember/object';\nimport {inject as service} from '@ember/service';\nimport {gt, readOnly} from '@ember/object/computed';\n+ import Component from '@glimmer/component';\n- import Component from '@ember/component';\nimport {task} from 'ember-concurrency';\nimport {tracked} from '@glimmer/tracking';\n\n- @tagName('section')\nexport default class Comments extends Component {\n @service\n store;\n\n @tracked isShowMoreExpanded = false;\n @tracked comments = [];\n @tracked allowNewComments = false;\n\n @readOnly('comments.length')\n commentCount;\n\n @gt('commentCount', 5)\n isTooManyComments;\n\n @computed('isTooManyComments', 'isShowMoreExpanded')\n get shouldShowExpandCommentOption() {\n if (this.isTooManyComments && !this.isShowMoreExpanded) return true;\n return false;\n }\n\n @computed('isTooManyComments', 'isShowMoreExpanded')\n get slicedComments() {\n if (this.isTooManyComments && !this.isShowMoreExpanded) {\n return this.comments.slice(0, 5);\n } else {\n return this.comments;\n }\n }\n\n @action\n expandComments() {\n this.isShowMoreExpanded = true;\n }\n\n- didInsertElement() {\n- this.fetchComments.perform(this.post);\n- }\n\n @task(function* (post) {\n const comments = yield this.store.query('comment', {\n post_id: post.id,\n include: 'author',\n });\n this.comments = comments;\n })\n fetchComments;\n}\n\n```\n\n```diff\n// app/components/comments.hbs\n- {{#if fetchComments.isRunning}}\n- \n-

\n- \n- {{else}}\n-

\n- {{#if allowNewComments}}\n+

\n+ {{#if this.fetchComments.isRunning}}\n+ \n+

\n+ \n+ {{else}}\n {{#if this.allowNewComments}}\n \n {{/if}}\n- {{#each slicedComments as |comment|}}\n+ {{#each this.slicedComments as |comment|}}\n \n {{/each}}\n- {{#if shouldShowExpandCommentOption}}\n+ {{#if this.shouldShowExpandCommentOption}}\n \n Show more comments\n \n {{/if}}\n-

\n- {{/if}}\n+ {{/if}}\n+ \n\n```","transcript":null,"disqus-identifier":"MW_EEAgnFpJfaM9woYw7TA","slug":"converting-an-ember-component-to-a-glimmer-component-part-1"},"relationships":{"vimeo-video":{"links":{"self":"https://embermap.com/api/v1/clips/612/relationships/vimeo-video","related":"https://embermap.com/api/v1/clips/612/vimeo-video"}},"series":{"links":{"self":"https://embermap.com/api/v1/clips/612/relationships/series","related":"https://embermap.com/api/v1/clips/612/series"}},"encodes":{"links":{"self":"https://embermap.com/api/v1/clips/612/relationships/encodes","related":"https://embermap.com/api/v1/clips/612/encodes"},"data":[{"type":"encodes","id":"1127"},{"type":"encodes","id":"1126"}]},"comments":{"links":{"self":"https://embermap.com/api/v1/clips/612/relationships/comments","related":"https://embermap.com/api/v1/clips/612/comments"}}}},{"id":"577","type":"clips","links":{"self":"https://embermap.com/api/v1/clips/577"},"attributes":{"title":"Converting a Model","poster-s3-key":"public/images/04712e1a-3f13-4aaa-bb3d-f78ebfb4d74a/first-look-1.png","featured-poster-image-key":null,"published-at":"2020-10-23T18:43:28.942Z","position":1,"viewing-requirement":"none","live":true,"coming-soon":false,"duration":534,"description":"Learn how to convert an Ember Model to native class syntax.","summary":"\nConverting an Ember model to native class syntax\n\n## Summary\n\nAs of Ember 3.10 ([with decorator support](https://embermap.com/topics/what-s-new-in-ember/native-decorator-support-3-10)), you can easily start converting your Ember app to use native classes. Not only will this bring your Ember app more in-line with the rest of the Javascript ecosystem, it is a required step in upgrading an app to use Octane.\n\nA complete Octane upgrade is fairly involved, so I would recommend checking out [The Ember Atlas upgrade guide](https://www.notion.so/Ember-Octane-b8ad64b7adf74218942fc69ead7b6892) for a great overview.\n\nTo convert our files, I recommend using the excellent [ember-native-class-codemod](https://github.com/ember-codemods/ember-native-class-codemod).\n\nFollowing the directions in the addon readme, we'll need to install two decorator addons:\n```\nember install ember-classic-decorator\nember install ember-decorators \n```\nand then start our app:\n`ember serve`. \nAs you start your app, take note of what port it's running on.\n\nWe'll start with trying to convert this model file:\n\n```js\nimport DS from 'ember-data';\nimport Commentable from 'ember-playground/mixins/commentable';\n\nexport default DS.Model.extend(Commentable, {\n body: DS.attr(),\n\n author: DS.belongsTo('user'),\n post: DS.belongsTo('post'),\n});\n```\nOnce the app is running, we can run the `npx` command noted in the codemod docs:\n`npx ember-native-class-codemod http://localhost:4200/ app/models/comment.js`.\n\nThis will take a minute to run, but at the end we see\n![codemod output -- 1 unmodified, 0 ok](https://i.imgur.com/am8O5qW.png)\nAdditionally we see there's a new file in our directory -- `codemods.log`. Inspecting this file shows nothing was added. And finally, if we look back at our model file, we can see that nothing has changed.\n\nLooking more closely at the codemod docs, we can see it does not support methods imported from `DS`. We can convert our model file away from using DS import as such:\n```js\n// app/models/comment.js\nimport Model, {attr, belongsTo} from '@ember-data/model';\nimport Commentable from 'ember-playground/mixins/commentable';\n\nexport default Model.extend(Commentable, {\n body: attr(),\n\n author: belongsTo('user'),\n post: belongsTo('post'),\n});\n```\n\nRunning the same codemod command again produces a more agreeable output from the command, a `SUCCESS` line in our `codemods.log` file, and finally, our model file converted to use native class syntax.\n\n```js\nimport classic from 'ember-classic-decorator';\nimport Model, {attr, belongsTo} from '@ember-data/model';\nimport Commentable from 'ember-playground/mixins/commentable';\n\n@classic\nexport default class Comment extends Model.extend(Commentable) {\n @attr()\n body;\n\n @belongsTo('user')\n author;\n\n @belongsTo('post')\n post;\n}\n\n```\n\nWe can see we're now using native JS class syntax to define our model class, and it has an automatic name generated -- `Comment`. The model attributes, `attr` and `belongsTo`, are now preceded by and `@` which indicates a decorator. These attributes act exactly like the old ones, just with slightly different syntax.\n\nWe've also got a `@classic` decorator added above the class definition. This is something that is added to every file converted by the codemod by default, and helps with the Octane transition. It acts as a bridge between old ember classes and the new, vanilla JS classes. If your new class has no deprecated ember quirks, you can go ahead and remove the @classic.\n\nIn this case, we've got a mixin that we still need. We won't be able to remove the `@classic` decorator for this class until we can refactor away from the mixin.","transcript":null,"disqus-identifier":"RafaXQlKQYOAUr969Hf89A","slug":"converting-a-model"},"relationships":{"vimeo-video":{"links":{"self":"https://embermap.com/api/v1/clips/577/relationships/vimeo-video","related":"https://embermap.com/api/v1/clips/577/vimeo-video"}},"series":{"links":{"self":"https://embermap.com/api/v1/clips/577/relationships/series","related":"https://embermap.com/api/v1/clips/577/series"}},"encodes":{"links":{"self":"https://embermap.com/api/v1/clips/577/relationships/encodes","related":"https://embermap.com/api/v1/clips/577/encodes"},"data":[{"type":"encodes","id":"1090"},{"type":"encodes","id":"1089"}]},"comments":{"links":{"self":"https://embermap.com/api/v1/clips/577/relationships/comments","related":"https://embermap.com/api/v1/clips/577/comments"}}}},{"id":"578","type":"clips","links":{"self":"https://embermap.com/api/v1/clips/578"},"attributes":{"title":"Converting an Ember Component to Native Class Syntax","poster-s3-key":"public/images/5020e174-075e-4e8e-83b9-d8494443e064/poster.png","featured-poster-image-key":null,"published-at":"2020-11-18T15:08:46.447Z","position":2,"viewing-requirement":"none","live":true,"coming-soon":false,"duration":671,"description":"Learn how to refactor an Ember component to use Native ES classes – without rewriting it into a Glimmer component.","summary":"In this video, we'll continue looking at converting original ember objects into native classes, this time with a component. We'll be using the [ember-native-class-codemod](https://github.com/ember-codemods/ember-native-class-codemod) as we did in the [previous video](https://embermap.com/topics/converting-to-octane-first-look/converting-a-model), and I would recommend taking a look at that for a walk-through of how to set it up.\n\nI'm going to be leaning heavily on [ember-cli/eslint-plugin-ember](https://github.com/ember-cli/eslint-plugin-ember) and [ember-cli-template-lint](https://github.com/ember-template-lint/ember-template-lint) today, and I highly recommend these as helpful tools in everyday development as well as in this conversion process in particular.\n\nNOTE: This conversion is NOT the same as converting your component to a _glimmer_ component. Converting your legacy ember class components to use native javascript classes is the first (but not final) step in upgrading your app to use Glimmer and Octane.\n\nTo start, we have our component which is fairly simple, it fetches some comments on insert, it's got a `tagName`, and toggles more comments into view if there are more than 5.\n\nOriginal file:\n```js\nimport Component from '@ember/component';\nimport {task} from 'ember-concurrency';\nimport {inject as service} from '@ember/service';\nimport {computed} from '@ember/object';\nimport {readOnly, gt} from '@ember/object/computed';\n\nexport default Component.extend({\n tagName: 'section',\n store: service(),\n\n post: null,\n isShowMoreExpanded: false,\n\n init() {\n this._super(...arguments);\n this.set('comments', []);\n },\n\n commentCount: readOnly('comments.length'),\n\n isTooManyComments: gt('commentCount', 5),\n\n shouldShowExpandCommentOption: computed('isTooManyComments', 'isShowMoreExpanded', function () {\n if (this.isTooManyComments && !this.isShowMoreExpanded) return true;\n return false;\n }),\n\n slicedComments: computed('isTooManyComments', 'isShowMoreExpanded', function () {\n if (this.isTooManyComments && !this.isShowMoreExpanded) {\n return this.comments.slice(0, 5);\n } else {\n return this.comments;\n }\n }),\n\n actions: {\n expandComments() {\n this.set('isShowMoreExpanded', true);\n },\n },\n\n didInsertElement() {\n this.fetchComments.perform(this.get('post'));\n },\n\n fetchComments: task(function* (post) {\n const comments = yield this.get('store').query('comment', {\n post_id: post.id,\n include: 'author',\n });\n this.set('comments', comments);\n }),\n});\n```\n\nWe can run the codemod on our component:\n\n```sh\n> npx ember-native-class-codemod http://localhost:4200 app/components/comments.js\n```\n\nAfter the codemod is finished, we see similar updates as last time and additionally:\n- The `tagName` property has become a class decorator,\n- Service injection has become the service decorator,\n- Our initialization of `post` has changed from colon to equal (also we've lost all our commas),\n- Syntax of super has changed from `this._super` to `super.init` (the name of the method we're calling super from),\n- Computed property macros are decorators,\n- Actions hash is gone, and actions are no longer grouped, just marked with the @action decorator,\n- The ember-concurrency task has become marked with a decorator.\n\nAfter codemod:\n```js\nimport classic from 'ember-classic-decorator';\nimport { tagName } from '@ember-decorators/component';\nimport { action, computed } from '@ember/object';\nimport { inject as service } from '@ember/service';\nimport { gt, readOnly } from '@ember/object/computed';\nimport Component from '@ember/component';\nimport {task} from 'ember-concurrency';\n\n@classic\n@tagName('section')\nexport default class Comments extends Component {\n @service\n store;\n\n post = null;\n isShowMoreExpanded = false;\n\n init() {\n super.init(...arguments);\n this.set('comments', []);\n }\n\n @readOnly('comments.length')\n commentCount;\n\n @gt('commentCount', 5)\n isTooManyComments;\n\n @computed('isTooManyComments', 'isShowMoreExpanded')\n get shouldShowExpandCommentOption() {\n if (this.isTooManyComments && !this.isShowMoreExpanded) return true;\n return false;\n }\n\n @computed('isTooManyComments', 'isShowMoreExpanded')\n get slicedComments() {\n if (this.isTooManyComments && !this.isShowMoreExpanded) {\n return this.comments.slice(0, 5);\n } else {\n return this.comments;\n }\n }\n\n @action\n expandComments() {\n this.set('isShowMoreExpanded', true);\n }\n\n didInsertElement() {\n this.fetchComments.perform(this.get('post'));\n }\n\n @task(function* (post) {\n const comments = yield this.get('store').query('comment', {\n post_id: post.id,\n include: 'author',\n });\n this.set('comments', comments);\n })\n fetchComments;\n}\n```\n\n\nFor this component, let's take it a step further, and remove the classic decorator.\n\nFirst, `init` is a component lifecycle hook that is no longer supported with component native classes. Luckily, native classes have `constructor` which will work with almost all uses of `init`.\nWe can change our `init` method to a constructor, which will, in-turn, require us to update our `super` invocation. `super`, in a constructor, appears alone and must be called before `this` is referenced in the method.\nAnother thing we must update is `this.get` and `this.set`. Since we are using a native class, the scope of `this` is different and no longer has `get` and `set` methods. We'll need to update instances of `this.get` and `this.set` and set the property on `this` itself.\nIf you have already used [es5-getter-ember-codemod](https://github.com/ember-codemods/es5-getter-ember-codemod) on your app, which I highly recommend, you'll not need to go through this.\n\nIf we look at our page in the browser again, we see an error.\n```\nUncaught (in promise) Error: Assertion Failed: You attempted to update .comments to \"\", but it is being tracked by a tracking context, such as a template, computed property, or observer. In order to make sure the context updates properly, you must invalidate the property when updating it. You can mark the property as `@tracked`, or use `@ember/object#set` to do this.\n```\nThis is telling us that the `comments` property needs to be `tracked`. We can import `tracked` from glimmer and tell this component we want properties watching `comments` to be updated when `comments` changes. When we mark a property as `tracked`, any computed property or getter that uses that property will automatically be recalculated when the prop changes. This means that we do not need to mark computed properties dependent on properties within them -- they already know when to change.\n\nWith that update, we can see the page loads as expected and we have a fully native ember component class!\n\n\nFinal version:\n```js\nimport {tagName} from '@ember-decorators/component';\nimport {action, computed} from '@ember/object';\nimport {inject as service} from '@ember/service';\nimport {gt, readOnly} from '@ember/object/computed';\nimport Component from '@ember/component';\nimport {task} from 'ember-concurrency';\nimport {tracked} from '@glimmer/tracking';\n\n@tagName('section')\nexport default class Comments extends Component {\n @service\n store;\n\n @tracked post = null;\n @tracked isShowMoreExpanded = false;\n @tracked comments = [];\n\n @readOnly('comments.length')\n commentCount;\n\n @gt('commentCount', 5)\n isTooManyComments;\n\n @computed('isTooManyComments', 'isShowMoreExpanded')\n get shouldShowExpandCommentOption() {\n if (this.isTooManyComments && !this.isShowMoreExpanded) return true;\n return false;\n }\n\n @computed('isTooManyComments', 'isShowMoreExpanded')\n get slicedComments() {\n if (this.isTooManyComments && !this.isShowMoreExpanded) {\n return this.comments.slice(0, 5);\n } else {\n return this.comments;\n }\n }\n\n @action\n expandComments() {\n this.isShowMoreExpanded = true;\n }\n\n didInsertElement() {\n this.fetchComments.perform(this.post);\n }\n\n @task(function* (post) {\n const comments = yield this.store.query('comment', {\n post_id: post.id,\n include: 'author',\n });\n this.comments = comments;\n })\n fetchComments;\n}\n\n```\n","transcript":null,"disqus-identifier":"OPNjLiwHkEQCJ0yVUBaxDQ","slug":"converting-an-ember-component-to-native-class-syntax"},"relationships":{"vimeo-video":{"links":{"self":"https://embermap.com/api/v1/clips/578/relationships/vimeo-video","related":"https://embermap.com/api/v1/clips/578/vimeo-video"}},"series":{"links":{"self":"https://embermap.com/api/v1/clips/578/relationships/series","related":"https://embermap.com/api/v1/clips/578/series"}},"encodes":{"links":{"self":"https://embermap.com/api/v1/clips/578/relationships/encodes","related":"https://embermap.com/api/v1/clips/578/encodes"},"data":[{"type":"encodes","id":"1092"},{"type":"encodes","id":"1091"}]},"comments":{"links":{"self":"https://embermap.com/api/v1/clips/578/relationships/comments","related":"https://embermap.com/api/v1/clips/578/comments"}}}},{"id":"613","type":"clips","links":{"self":"https://embermap.com/api/v1/clips/613"},"attributes":{"title":"Converting an Ember Component to a Glimmer Component, Part 2","poster-s3-key":"public/images/31fc87df-6610-4e1a-b2a8-559434423c72/first-look-4.png","featured-poster-image-key":null,"published-at":"2021-01-26T19:39:24.581Z","position":4,"viewing-requirement":"none","live":true,"coming-soon":false,"duration":714,"description":"Let's update our new Glimmer component with a few more idioms from Octane.","summary":"In this video we'll complete the Glimmer component update process!\n\nWe're now technically using Glimmer for our components, but there's a few more ways to bring our components into Octane and Glimmer best practices. \n\nThis video covers:\n\n- Template colocation\n- Action syntax and the `on` modifier\n- Computed/macros to `getters`\n- How to set default values\n\n\n## Template colocation\n\nTo make our component match Octane conventions, let's move our component template files into the `components` directory. This is called template colocation, and has been available since Ember 3.13. With this update your component JavaScript files and template files can live in the same directory.\n\nYou can move your files manually, or if you've got lots of files to move, you can use the codemod: [`ember-component-template-colocation-migrator`](https://github.com/ember-codemods/ember-component-template-colocation-migrator).\n\nYour components should not need any changes, and Ember will be moving in this direction going forward. You can read more about the reasoning behind this update in [RFC 0481 - Template colocation](https://emberjs.github.io/rfcs/0481-component-templates-co-location.html)\n\n\n## Actions\nRecall that the `actions` hash has been replaced by the `@action` decorator. This means that your actions no longer need to be name-spaced to an `actions` object, and both your JavaScript file and your template file can call these decorated actions as normal JavaScript functions. This also means we don't need to refer to action names as strings (e.g. `{{action 'functionName'}}`) anymore.\n\nThis means we can replace our `expandComments` action with `{{action this.expandComments}}`. \n\nWe can take it one step further and use the `on` modifier. This is the latest way to add interactions to elements in Ember. We can use `{{on \"click\" this.expandComments}}` to tell the template to run `expandComments` on click. Check out [Sam's previous video](https://embermap.com/topics/what-s-new-in-ember/the-on-modifier-3-11) for a lot more detail about the on modifier.\n\n\n## Computed and computed macros\n\nTo make our app even more modern, we can refactor away from `@computed` and related macros. They still work for now, but you should aim to convert your computed properties and macros to plain `getters` as computed properties will become deprecated in future version of Ember.\n\nHere are two examples:\n\n```js\n// old\n@gt('commentCount', 5)\nisTooManyComments;\n\n// new\nget isTooManyComments () {\n return this.commentCount > 5;\n}\n```\n\n```js\n// old\n@computed('isTooManyComments', 'isShowMoreExpanded')\nshouldShowExpandCommentOption() {\n return this.isTooManyComments && !this.isShowMoreExpanded\n}\n\n// new\nget shouldShowExpandCommentOption() {\n return this.isTooManyComments && !this.isShowMoreExpanded\n}\n```\n\nIf you're unfamiliar with `@tracked`, you may be wondering how Ember will know to recalculate these properties when one of their dependent properties changes, since we've dropped the dependent key string we're used to using inside of `computed()`.\n\nWell, since we've defined the properties that we want to track using the `@tracked` decorator, Ember can automatically determine when it needs to recalculate getters. `@tracked` is the key feature of Glimmer that enables this!\n\nWe no longer have to declare dependencies manually for every computed property. If a `getter` accesses a tracked property, _or_ accesses another `getter` that itself accesses a tracked property, it will automatically update for you. Also, since passed-in arguments are tracked, any getter that accesses an argument will also update automatically when that argument changes.\n\nYou can read more about the differences between computed properties and `getters` [here](https://ember-learn.github.io/ember-octane-vs-classic-cheat-sheet/#component-properties__tracked-vs-cp).\n\n\n## Default values\nFinally, we'll cover how to set default values in a Glimmer component.\n\nYou might have noticed that we introduced a bug onto our page – before the conversion, we had a `textarea` where a user could enter a new comment.\nThis element's visibility is controlled by the `allowNewComments` prop, which is defined by default as `false` in our component. However, the caller is passing in `true` as an argument for the prop, attempting to overwrite the default.\n\nThis setup worked in the classic version of components, because default property values could be overridden by arguments of the same name. In Glimmer components, however, all arguments are preserved in the name-spaced `args` object, and they no longer automatically overwrite properties of the same name on the component instance.\n\nWe can fix this by writing a new getter. Looking at our template, we can see it's currently accessing the `this.allowNewComments` property of our component, and in our JavaScript file, that property is set to `false`.\n\nLet's update this property to be a `getter`:\n\n```js\nget allowNewComments() {\n return this.args.allowNewComments ?? false;\n}\n```\n\nThe getter first checks whether an `allowNewComments` arg was passed in or not from the caller. If it was, it uses it, and otherwise, it falls back to a default value of `false`.\n\nChanging `this.allowNewComments` from a property to a getter doesn't require any changes to our template – `this.allowNewComments` still works just the same. This is an intentional part of the design of Glimmer components. And now our page works just like before!","transcript":null,"disqus-identifier":"iKUCI4wJzKGtPan3Ag_49A","slug":"converting-an-ember-component-to-a-glimmer-component-part-2"},"relationships":{"vimeo-video":{"links":{"self":"https://embermap.com/api/v1/clips/613/relationships/vimeo-video","related":"https://embermap.com/api/v1/clips/613/vimeo-video"}},"series":{"links":{"self":"https://embermap.com/api/v1/clips/613/relationships/series","related":"https://embermap.com/api/v1/clips/613/series"}},"encodes":{"links":{"self":"https://embermap.com/api/v1/clips/613/relationships/encodes","related":"https://embermap.com/api/v1/clips/613/encodes"},"data":[{"type":"encodes","id":"1129"},{"type":"encodes","id":"1128"}]},"comments":{"links":{"self":"https://embermap.com/api/v1/clips/613/relationships/comments","related":"https://embermap.com/api/v1/clips/613/comments"}}}},{"id":"1127","type":"encodes","links":{"self":"https://embermap.com/api/v1/encodes/1127"},"attributes":{"url":"https://d19c50bha6zcb3.cloudfront.net/encodes/1127-b843fdb5-da50-4f12-ae79-05f32872b2de.webm","format":"webm"}},{"id":"1126","type":"encodes","links":{"self":"https://embermap.com/api/v1/encodes/1126"},"attributes":{"url":"https://d19c50bha6zcb3.cloudfront.net/encodes/1126-74a8a82e-3500-4482-a312-a29c3a30d3ec.mp4","format":"mp4"}},{"id":"1090","type":"encodes","links":{"self":"https://embermap.com/api/v1/encodes/1090"},"attributes":{"url":"https://d19c50bha6zcb3.cloudfront.net/encodes/1090-5c8aa6e3-be76-4f59-abe2-f0aa56f3d17b.webm","format":"webm"}},{"id":"1089","type":"encodes","links":{"self":"https://embermap.com/api/v1/encodes/1089"},"attributes":{"url":"https://d19c50bha6zcb3.cloudfront.net/encodes/1089-db4102e1-bc5b-4f97-9a4f-4dfd2efe271b.mp4","format":"mp4"}},{"id":"1092","type":"encodes","links":{"self":"https://embermap.com/api/v1/encodes/1092"},"attributes":{"url":"https://d19c50bha6zcb3.cloudfront.net/encodes/1092-ce966fb8-e033-495c-ab7a-886ae52f5649.webm","format":"webm"}},{"id":"1091","type":"encodes","links":{"self":"https://embermap.com/api/v1/encodes/1091"},"attributes":{"url":"https://d19c50bha6zcb3.cloudfront.net/encodes/1091-83a33348-67a3-4909-a719-b81646a05458.mp4","format":"mp4"}},{"id":"1129","type":"encodes","links":{"self":"https://embermap.com/api/v1/encodes/1129"},"attributes":{"url":"https://d19c50bha6zcb3.cloudfront.net/encodes/1129-2af3a188-cfa6-4e87-8c22-e56ce45d1562.webm","format":"webm"}},{"id":"1128","type":"encodes","links":{"self":"https://embermap.com/api/v1/encodes/1128"},"attributes":{"url":"https://d19c50bha6zcb3.cloudfront.net/encodes/1128-6897efbc-d87d-4f77-8034-f2927462b282.mp4","format":"mp4"}}]}

Converting to Octane: First Look

Description

Videos