Add "Show/Hide" toggle button to Password input
See original GitHub issueIdea
The Password field could have an extra button to control the isPasswordVisible
prop.
Proposed Solution This button would be displayed similar to the badge, but would stay inline with the Label and control the visibility of the password inside the component, as a toggle.
Example of the intended design:
Alternatives that have been discussed
It has been discussed wether the badge
prop should be used for this, but the UI is slightly different (it’s not inline) and this use case may be sufficiently relevant for the Password field to have this special prop.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:5 (5 by maintainers)
Top Results From Across the Web
How To Toggle Password Visibility - W3Schools
Toggle between password visibility with JavaScript. ... Step 1) Add HTML: ... Password: <input type="password" value="FakePSW" id="myInput">
Read more >How to Toggle Password Visibility Using Plain JavaScript
First, create an <input> element with the type of password and an icon that allows users to click it to toggle the visibility...
Read more >Toggle Password input field using Javascript (Show/hide ...
In this article, I have provided working example to show or hide (toggle) password input field using Javascript, with an example.
Read more >Hide/Show Password using Eye icon in HTML and JavaScript
First, create the HTML login form. Secondly, show/hide password when the user clicks on the eye icon. ... Add JavaScript to Toggle Show/Hide...
Read more >Hide/show toggle inside password input - Stack Overflow
First of all, make sure an id is only used once! (Second svg changed); You can hide and show the desired <svg> onclick;...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I was thinking about translations, but I’m now aware that the UIKit already has a better way to deal with that, so no need for such a prop!
Agreed. Managing this state internally makes sense. We only have to make sure that we will not have a case where we need the state to be controlled. That’s down to design to reason about.
Okay, well that surprises me given that we don’t have them for too long. But well.
Do we really need that? Couldn’t it be an internal message to UIKit? Do we ever want to change the labels on that actually from the outside. One could argue that’s a potential source of inconsistencies even.
Yeah, you’re right about it.