You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/markdown/tutorial/part-2/12-provider-components.md
+49-26Lines changed: 49 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ In this chapter, we'll work on adding a new search feature, and refactor our `in
12
12
13
13
During this refactor, you will learn about:
14
14
15
-
* Using Ember's built-in `<Input>` component
15
+
* Using forms
16
16
* The provider component pattern
17
17
* Using block parameters when invoking components
18
18
* Yielding data to caller components
@@ -21,15 +21,17 @@ During this refactor, you will learn about:
21
21
22
22
As our app grows and as we add more features to it, one thing that would be really nice to have is some search functionality. It would be great if our users could just type a word into a search box and our app could just respond with matching and relevant rentals. So how could we go about implementing this feature?
23
23
24
-
Well, we can start simple. Before we worry about implementing the "search" part of this feature, let's just get something on the page. The first step is to add an `<input>` tag to our `index` page, and make it look pretty with a class.
24
+
Well, we can start simple. Before we worry about implementing the "search" part of this feature, let's just get something on the page. The first step is to add a form with an `<input>` tag to our `index` page, and make it look pretty with a class.
@@ -76,13 +80,15 @@ Let's start simple again and begin our refactor by creating a new template for o
76
80
There is one minor change to note here: while extracting our markup into a component, we also renamed the `@model` argument to be `@rentals` instead, just in order to be a little more specific about what we're iterating over in our `{{#each}}` loop. Otherwise, all we're doing here is copy-pasting what was on our `index.hbs` page into our new component template. Now we just need to actually use our new component in the index template where we started this whole refactor! Let's render our `<Rentals>` component in our `index.hbs` template.
Now that we have our component all set up, we can finally wire up our search box and store our search query! First things first: let's create a component class to store our query state.
224
+
Now that we have our component all set up, we can finally wire up our search box and store our search query! First things first: let's create a component class to store our query state and handle events from the `form` element:
+ <p>The results below will update as you type.</p>
261
+
</form>
237
262
```
238
263
239
-
Interesting! There are a few things happening in this one-line template change. First, we're moving from using a plain HTML `<input>` tag to using an `<Input>` tag instead! As it turns out, Ember provides us with a helpful little *[`<Input>` component](../../../components/built-in-components/#toc_input)* for this exact use case. The `<Input>` component is actually just a wrapper around the `<input>` element.
240
-
241
-
Ember's `<Input>` component is pretty neat; it will wire up things behind the scenes such that, whenever the user types something into the input box, `this.query` changes accordingly. In other words, `this.query` is kept in sync with the value of what is being searched; we finally have the perfect way of storing the state of our search query!
264
+
[`FormData`](https://developer.mozilla.org/en-US/docs/Web/API/FormData) is a built-in JavaScript object for handling forms. It requires the `name` attribute on the `input`. We handle both `submit` and `input` events for the form so that the query updates both when the user types into the input and when they submit the form.
0 commit comments