Updated Built-In Components page to clarify how to use <Input> component #1546
Conversation
|
I think we probably need to do more testing. It is in fact illegal to change the ID of an ember component after its instantiated (and probably a bit sketchy though valid on HTML elements in general), which is why it doesn’t update using your method (I think you are supposed to get an assertion). I think this isn’t that common in practice and instead we should focus on whether things like event delegation still works if you use the ID attribute. ie does the focusIn(), etc hooks defined on the component still fire correctly. |
|
@chancancode Sounds good, thanks for the quick feedback. I'll look at event delegation more closely and let you know how it goes. |
|
@chancancode Here is my updated example. I hope I understood what you were looking for: TemplateController// app/controllers/application.js
import Controller from '@ember/controller';
import { action } from '@ember/object';
import { tracked } from '@glimmer/tracking';
export default class ApplicationController extends Controller {
@tracked name1 = 'Bob Ross';
@tracked name2 = 'Bob Ross';
@tracked name3 = 'Bob Ross';
// https://api.emberjs.com/ember/release/classes/Component#event-handler-methods
@action mouseDown(event) {
console.log('mousedown');
console.log(event);
}
@action mouseUp(event) {
console.log('mouseup');
console.log(event);
}
@action contextMenu(event) {
console.log('contextmenu');
console.log(event);
}
@action click(event) {
console.log('click');
console.log(event);
}
@action doubleClick(event) {
console.log('dblclick');
console.log(event);
}
@action change(event) {
console.log('change');
console.log(event.target.value);
}
@action focusIn(event) {
console.log('focusin');
console.log(event);
}
@action focusOut(event) {
console.log('focusout');
console.log(event);
}
@action input(event) {
console.log('input');
console.log(event.target.value);
}
}I created 3 sets of
In Perhaps we need to test in |
|
Yeah that seems like a good test to me. The fix should be available in v3.21.1 so I would expect it to work. Are you able to:
Otherwise you can push your app somewhere and I can take a look too |
|
I uploaded my demo app and recorded what I tried in I don't get to walk through the |
|
@ijlee2 you can do it from the chrome devtools.
|
|
(Instead of |
|
I think I see the problem in your test: you tried to do Then, things like |
|
@chancancode Thanks very much for the instructions. I was able to set a breakpoint on Changes I made to the sample app I think you're right that we have to use It's also worth noting that version 3 ( ScreenshotsVersion 1,
|
👍 I think that all went as expected. Version 2 doesn’t trip the breakpoint because the passed argument overwrote and replaced the handler on the component, which is The Problem™️.
Yeah so that’s the problem/quirk of classic components in general. However, the fact that you can get version 1 working as expected either way means that Ember internally no longer uses If this is your own component or something from an addon that you are invoking, you may care about
Yep that is also as expected. The |
|
Awesome. Other than a review of the writing, this PR should be good to go then? |
There was a problem hiding this comment.
Hello! Thanks so much for writing this! It is a big improvement for our users.
I added a few comments and wording changes. The ones that I would say are required are, we should not say that any particular addon is recommended, if linking to a list of them will suffice. The others are around cutting down references to Ember Classic and "legacy." We have some of that language sprinkled through the Guides to help give people a glide path, but Octane has been out for a while now and I think we should walk towards removing the references. These may not be described in a styleguide anywhere - I will try to fix that.
Co-authored-by: Jen Weber <[email protected]>
Co-authored-by: Jen Weber <[email protected]>
Co-authored-by: Jen Weber <[email protected]>
Co-authored-by: Jen Weber <[email protected]>
Description
This PR addresses and can close issue #1543 . In particular, in the Ember Learning Team's
Input component plansdocument, this PR completes 3 action items:{{on "input}}or{{on "change"}}handlingw/o addons in the first pass. Maybe later show keydown(For simplicity in code, I showed how to migrate@enterand@escape-pressusingember-keyboard)I read everything in Built-In Components to figure out how to update each subsection and its examples, so that the updated page will be coherent as a whole.
I also created a new Ember v3.21.1 app. I copy-pasted the existing code samples to figure out what worked and what didn't. The updated code samples should work when a developer copy-pastes them to a new app (assuming v3.21).
How to Review
I recommend reviewing commits one by one. Each commit looks at one subsection in
Built-In Components.Notes
In meeting, @chancancode, @jenweber, @locks, and I weren't sure whether, with
<Input>component, a developer needed to use@id(argument) orid(attribute) to correctly bind to the input element'sidattribute.Based on my
v3.21.1app, I think we have to useid. (This is good for us, as it requires fewer changes.)Consider the following code. It changes the input ID every 1 second.
When we use
<Input id=... />, in Chrome Inspector, we will see that the ID changes for theforandidattributes every second. Clicking on the label will focus on the input as well.However, when we use
<Input @id=... />, we will see that the ID changes only for theforattribute in the label. Clicking on the label will not focus on the input anymore.