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

Show how to make your own input component #1354

Open
jenweber opened this issue Mar 25, 2020 · 15 comments
Open

Show how to make your own input component #1354

jenweber opened this issue Mar 25, 2020 · 15 comments

Comments

@jenweber
Copy link
Contributor

In Ember Octane, we have an emphasis on teaching devs how to use Ember to interact with the DOM. We should show an example of how to create a regular input, as opposed to Input.

Showing how to write a vanilla input component serves 3 purposes:

@jenweber
Copy link
Contributor Author

Note, this issue should get some learning team feedback before we move forward.

@jenweber
Copy link
Contributor Author

@ember-learn/learning-core-team please review and add your comments to this issue before our next meeting, if you can find the time!

@locks
Copy link
Contributor

locks commented Mar 25, 2020

The last time we discussed covering input some issues were raised that are still relevant, like the ergonomics of updating a value on change, hope to discuss this proposal at the weekly meeting in more detail!
If we teach how to build your own "wrapper" component, meaning this wrapper component would have the change callback and expose some API to the user, I think we might end up in uncanny valley. Would it make sense to frame it as a deep dive into interacting with the DOM in general?

@jenweber
Copy link
Contributor Author

The last point you made there is the framing I would like to use.

@pzuraq
Copy link
Contributor

pzuraq commented Mar 26, 2020

So, one of the principles we've been moving toward is exposing the primitives, and I don't think that Input is a primitive. Rather, it's a high level convention, but it should still be based on primitives. I think having a guide that shows users how to build the conventional Input component (and all built-in components) would be a good idea.

There is the issue that the current Input is still using older conventions, and hasn't been updated quite yet. We need to finish work on {{box}} to make progress there, so it'll be a while for that. LinkTo is in a similar spot, we need to implement the Router Helpers RFC to be able to show users how to build it in a solid, conventional way.

Once that's done though, I think it would be a great guide to have. It shouldn't be the primary path for new learners, but it could be something like a tutorial: Making Ember Built-Ins from Scratch. I think this would be a great resource for intermediate learners.

@MelSumner
Copy link
Member

I think it's a bit of change we can make to the guides now that would be immediately useful. If/when we resolve the other issues, we could update the guides accordingly.

@rajasegar
Copy link
Contributor

@pzuraq What is {{box}}?

@pzuraq
Copy link
Contributor

pzuraq commented Mar 29, 2020

@chriskrycho
Copy link
Contributor

@MelSumner @pzuraq I agree that there’s a lot of value here, but I do not think it’s a good idea to show how to implement the current Input and LinkTo. There be dragons in the waters for implementing it in a way that’s backwards-compatible with positional arguments as those are currently. 🐉 🌊 (I’ve spent painful time up close and personal with both Input and LinkTo in the last couple weeks, and it is appropriately gnarly given what it has to do. 😬)

A Glimmer-ready implementation, by contrast, would be very helpful—and would allow us to avoid some of the foot-guns present in implementing the primitives we have today. (There’s probably also value in showing how to do even what we have today, but I’d absolutely put that in the “Advanced” rather than “Intermediate” learning materials bucket.)

@jenweber
Copy link
Contributor Author

jenweber commented Mar 31, 2020

To clarify, I would not intend to show a “faithful” Input, rather an Octane-style input without 2 way binding.

@chriskrycho
Copy link
Contributor

100% to that approach! If I had more time, I'd do it myself as it's right in one of my hobby-horse spaces. 😂

@hergaiety
Copy link
Contributor

Perhaps diving into the differences between <input> and <Input> may be confusing to some. What if, instead, we describe a similar use case that comes up commonly that Ember does not attempt to solve for out of the box such as <select> dropdowns? We could cover a lot of the same content such as labels, a11y, setting the value and listening for change events etc.

@chriskrycho
Copy link
Contributor

I would agree if beginners were the target audience, but precisely because this material is intended for an Intermediate audience I think it’s great to tackle what is unarguably already a slightly confusing point in Ember. That being said, no reason there can’t be dedicated How To/Recipe-style materials for more than one of these!

@jenweber
Copy link
Contributor Author

jenweber commented Apr 2, 2020

As discussed in the learning team meeting today:

  • A place for these docs could be having a new article under "In-depth topics" in the Guides
  • Should call it MyInput or similar in order to drive home that it's not Input
  • Make good use of Zoey Says
  • Show how to build the input we want to have (Jen has a draft blog post to share)

@MatthewPringle
Copy link

Hello

Did the blog post get published? I was looking into generating inputs today with Octane and have struggled to find the correct way to do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants