Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reflect the introduction of Component Signatures #1530

Merged
merged 3 commits into from Oct 25, 2022

Conversation

roomman
Copy link
Contributor

@roomman roomman commented Oct 24, 2022

This PR follows feedback from @chriskrycho on Ember Discuss, and aims to reflect the introduction of Component Signatures.

The changes focus on defining a Component Signature and the use of Args. I've removed several sections that related to args being an empty object. Now that defining a Signature is a prerequisite, they seemed less pertinent.

After making these changes I spotted an existing PR that goes into detail about Element and Block. I didn't attempt this because it felt like a duplication of the Glint docs. I'm happy for this PR to be sidelined if the existing PR ticks more boxes!

This PR follows [feedback](https://discuss.emberjs.com/t/component-arguments-and-typescript-whats-the-right-approach/19761) from @chriskrycho on Ember Discuss, and aims to reflect the introduction of Component Signatures.

Hopefully this isn't too heavy handed but it seemed to me that previous sections belonged to a time when `args` could be empty object. As defining a Signature is a prerequisite for calling `this.args` it felt right to remove them?
@@ -102,75 +127,6 @@ export default class ArgsDisplay extends Component {
</ul>
```

### Understanding `args`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's go ahead and leave this section (I'll do a follow-up on it to clean it up further). If you can just drop it back in, the rest of it looks like a great first iteration on this update, and will already be a big improvement for users. Thank you!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added that section back in. I also started to update the section but got out of my depth pretty quickly so will leave the rest with you 🤣

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha that's exactly what I suggested this narrower path. Thank you!

@@ -133,44 +156,6 @@ let b = ["hello", "goodbye"]; // Array<string>

In the case of the Component, we have the types the way we do so that you can’t accidentally define `args` as a string, or `undefined` , or whatever: it _has_ to be an object. Thus, `Component<Args extends {}>` . But we also want to make it so that you can just write `extends Component` , so that needs to have a default value. Thus, `Component<Args extends {} = {}>`.

### Giving `args` a type
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, looks like this needs to be added back in as well!

Comment on lines 131 to 141
Looking at that example above, Typescript knows what types `this.args` has, but how? In the `constructor` version, we explicitly _named_ the type of the `args` argument. Here, it seems to just work automatically. This works because the type definition for a Glimmer component looks roughly like this:

```typescript
export default class Component<Args extends {} = {}> {
readonly args: Args;

constructor(owner: unknown, args: Args);
}
```
```typescript
export default class Component {
args: Readonly<Args>;
constructor(owner: unknown, args: Args);
}
```

{% hint style="info" %}
Not sure what’s up with `<Args>` _at all_? We highly recommend the [TypeScript Deep Dive](https://basarat.gitbooks.io/typescript/) book’s [chapter on generics ](https://basarat.gitbooks.io/typescript/docs/types/generics.html) to be quite helpful in understanding this part.
Not sure what’s up with `<Args>` or `<S>` _at all_? We highly recommend the [TypeScript Deep Dive](https://basarat.gitbooks.io/typescript/) book’s [chapter on generics ](https://basarat.gitbooks.io/typescript/docs/types/generics.html) to be quite helpful in understanding this part.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just leave these as they were as well, despite the slight incoherence. I will do a follow-up PR later today after merging yours which updates all of this language (and possibly does some restructuring as well).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All done and both sections are back in their original state. Thanks!

Copy link
Member

@chriskrycho chriskrycho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much!

@chriskrycho chriskrycho merged commit c3481a8 into typed-ember:master Oct 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants