diff --git a/.local.dic b/.local.dic index 0c19f5a993..1e1a743530 100644 --- a/.local.dic +++ b/.local.dic @@ -252,3 +252,4 @@ websocket working-with-html-css-and-javascript yay ZEIT +userQuestion diff --git a/guides/release/components/block-content.md b/guides/release/components/block-content.md index a98d7a245c..4ef844eafa 100644 --- a/guides/release/components/block-content.md +++ b/guides/release/components/block-content.md @@ -2,24 +2,32 @@ Component templates can leave one or more placeholders that users can fill with These are called blocks. Here's an example that provides a component with the implicit default block. -```handlebars - - This is the default block content that will - replace `{{yield}}` (or `{{yield to="default"}}`) - in the `ExampleComponent` template. - -``` - -This is equivalent to explicitly naming the default block using the named block syntax. +```gjs +import ExampleComponent from 'my-app/components/example-component'; -```handlebars - - <:default> + +``` + +This is equivalent to explicitly naming the default block using the named block syntax. + +```gjs +import ExampleComponent from 'my-app/components/example-component'; + + ``` Through Block Content, users of the component can add additional styling and @@ -28,57 +36,61 @@ behavior by using HTML, modifiers, and other components within the block. To make that more concrete, let's take a look at two similar components representing different user's messages. -```handlebars {data-filename="app/components/received-message.hbs"} - -
-

- Tomster - their local time is 4:56pm -

- -

- Hey Zoey, have you had a chance to look at the EmberConf - brainstorming doc I sent you? -

-
+```gjs {data-filename="app/components/received-message.gjs"} + ``` -```handlebars {data-filename="app/components/sent-message.hbs"} - -
-

Zoey

- -

Hey!

- -

- I love the ideas! I'm really excited about where this year's - EmberConf is going, I'm sure it's going to be the best one yet. - Some quick notes: -

- - - -

Let me know when you've nailed down the dates!

-
+```gjs {data-filename="app/components/sent-message.gjs"} + ``` Instead of having two different components, one for sent messages and one for @@ -90,21 +102,26 @@ Their structure is pretty straightforward and similar, so we can use arguments and conditionals to handle the differences in content between them (see the previous chapters for details on how to do this). -```handlebars {data-filename="app/components/message.hbs"} - -
- +```gjs {data-filename="app/components/message.gjs"} +import MessageAvatar from 'my-app/components/message/avatar'; +import MessageUsername from 'my-app/components/message/username'; - ... -
+ ``` This works pretty well, but the message content is very different. It's also @@ -114,21 +131,26 @@ supplied by the `` tag. The way to do this in Ember is by using the `{{yield}}` syntax. -```handlebars {data-filename="app/components/message.hbs"} - -
- + +
+ - {{yield}} -
+ {{yield}} +
+ ```
@@ -151,57 +173,65 @@ The way to do this in Ember is by using the `{{yield}}` syntax. You can think of using `{{yield}}` as leaving a placeholder for the content of the `` tag. -```handlebars {data-filename="app/components/received-message.hbs"} - -

- Hey Zoey, have you had a chance to look at the EmberConf - brainstorming doc I sent you? -

- +```gjs {data-filename="app/components/received-message.gjs"} +import Message from 'my-app/components/message'; + + ``` -```handlebars {data-filename="app/components/sent-message.hbs"} - -

Hey!

- -

- I love the ideas! I'm really excited about where this year's - EmberConf is going, I'm sure it's going to be the best one yet. - Some quick notes: -

- -
    -
  • - Definitely agree that we should double the coffee budget this - year (it really is impressive how much we go through!) -
    • -
  • - A blimp would definitely make the venue very easy to find, but - I think it might be a bit out of our budget. Maybe we could - rent some spotlights instead? -
    • -
  • - We absolutely will need more hamster wheels, last year's line - was way too long. Will get on that now before rental - season hits its peak. -
    • -
- -

Let me know when you've nailed down the dates!

- +```gjs {data-filename="app/components/sent-message.gjs"} +import Message from 'my-app/components/message'; + + ``` As shown here, we can pass different content into the tag. The content @@ -230,21 +260,27 @@ hasn't provided a block. For instance, consider an error message dialog that has a default message in cases where we don't know what error occurred. We could show the default message using the `(has-block)` syntax in an `ErrorDialog` component. -```handlebars {data-filename=app/components/error-dialog.hbs} - - {{#if (has-block)}} - {{yield}} - {{else}} - An unknown error occurred! - {{/if}} - +```gjs {data-filename="app/components/error-dialog.gjs"} + ``` Now, if we use our `ErrorDialog` component without a block, we'll get the default message. -```handlebars - +```gjs +import ErrorDialog from 'my-app/components/error-dialog'; + + ``` ```html @@ -256,11 +292,16 @@ default message. If we had a more detailed message, though, we could use the block to pass it to the dialog. -```handlebars - - -

You are not connected to the internet!

- +```gjs +import ErrorDialog from 'my-app/components/error-dialog'; +import Icon from 'my-app/components/icon'; + + ``` ## Block Parameters @@ -268,16 +309,22 @@ the dialog. Blocks can also pass values back into the template, similar to a callback function in JavaScript. Consider for instance a simple `BlogPost` component. -```handlebars {data-filename=app/components/blog-post.hbs} -

{{@post.title}}

-

{{@post.author}}

+```gjs {data-filename="app/components/blog-post.gjs"} + ``` -```handlebars - - +```gjs +import BlogPost from 'my-app/components/blog-post'; + + ``` We may want to give the user the ability to put extra content before or after @@ -285,79 +332,101 @@ the post, such as an image or a profile. Since we don't know what the user wants to do with the body of the post, we can instead pass the body back to them. -```handlebars {data-filename=app/components/blog-post.hbs} -

{{@post.title}}

-

{{@post.author}}

+```gjs {data-filename="app/components/blog-post.gjs"} + ``` -```handlebars - - - +```gjs +import BlogPost from 'my-app/components/blog-post'; +import AuthorBio from 'my-app/components/author-bio'; - {{postBody}} + ``` We can yield back multiple values as well, separated by spaces. -```handlebars {data-filename=app/components/blog-post.hbs} -{{yield @post.title @post.author @post.body }} +```gjs {data-filename="app/components/blog-post.gjs"} + ``` -```handlebars - - - +```gjs +import BlogPost from 'my-app/components/blog-post'; +import AuthorBio from 'my-app/components/author-bio'; + + ``` ## Named Blocks If you want to yield content to different spots in the same component, you can use named blocks. You just need to specify a name for the yielded block, like this: -```handlebars -{{yield to="somePlace"}} +```gjs + ``` You could also want to pass some values. This is the same process as the default `yield`, but you just have to pass `to` as the last argument. An example would be the popover: -```handlebars {data-filename=app/components/popover.hbs} -
-
- {{yield this.isOpen to="trigger"}} -
- {{#if this.isOpen}} -
- {{yield to="content"}} +```gjs {data-filename="app/components/popover.gjs"} + ``` Without named blocks, we would certainly have to pass components as `args` to the popover. But this is much more practical! Here’s how we would call our named blocks as a consumer: -```handlebars - - <:trigger as |open|> - - - <:content> - This is what is shown when I'm opened! - - +```gjs +import Popover from 'my-app/components/popover'; + + ``` We know the state of the popover because we passed it as an argument to the `yield`. To access its value, use the block parameters at the named block scope. It will not be accessible at the `Popover` level, so if you want the value to be available for all the blocks, you will have to pass it for each of them. @@ -378,38 +447,48 @@ Rendering the previous code example would give this as result: Don't worry, you can also still use `yield` by itself, and mix it with named blocks. Let’s take a card example: -```handlebars {data-filename=app/components/card.hbs} -
- {{#if (has-block "title")}} -
- {{yield to="title"}} +```gjs {data-filename="app/components/card.gjs"} + ``` A yielded block without a name is called `default`. So to access it, it’s like any other named blocks. -```handlebars - - <:title> -

It's nice to have me. Sometimes

- - <:default> - The card content will appear here! - - +```gjs +import Card from 'my-app/components/card'; + + ``` The title being optional when you create a card, you can use the `(has-block)` helper with the named block by adding its name as a first parameter. That means you could also create this card: -```handlebars - - I don't want any title, and I only have a default content! - +```gjs +import Card from 'my-app/components/card'; + + ``` As you are not using named blocks, you can simply yield the content you would like to add, which becomes the default yield block. diff --git a/guides/release/components/built-in-components.md b/guides/release/components/built-in-components.md index 9b0b1ebf91..1bcd2fb4a2 100644 --- a/guides/release/components/built-in-components.md +++ b/guides/release/components/built-in-components.md @@ -10,18 +10,22 @@ These components are similar in HTML markup to the native `` or `Ask a question about Ember: - +Consider the following example in a component. + +```gjs +import { Input } from '@ember/component'; + + ``` -When Ember renders this template, you will see the following HTML code: +When Ember renders this component, you will see the following HTML code: ```html @@ -35,40 +39,71 @@ Every input should be associated with a label. In HTML, there are a few ways to 1. You can nest the input inside the label. - ```handlebars - - ``` +```gjs +import Component from "@glimmer/component"; +import { Input } from '@ember/component'; +import { tracked } from '@glimmer/tracking'; + +export default class Example extends Component { + @tracked userQuestion = ''; + + +} +``` 2. You can create an ID (globally unique within the webpage), then associate the label to the input with `for` attribute and `id` attribute. - ```handlebars - - - - ``` +```gjs +import Component from "@glimmer/component"; +import { Input } from '@ember/component'; +import { tracked } from '@glimmer/tracking'; + +export default class Example extends Component { + @tracked userQuestion = ''; + myUniqueId = "this-is-a-unique-id"; + + +} +``` 3. You can use the `aria-label` attribute to label the input with a string that is visually hidden but still available to assistive technology. - ```handlebars - - ``` +```gjs +import Component from "@glimmer/component"; +import { Input } from '@ember/component'; +import { tracked } from '@glimmer/tracking'; + +export default class Example extends Component { + @tracked userQuestion = ''; + + +} +``` While it is more appropriate to use the `