thaw-ui
Unescapable nested div class in AutoComplete
AutoComplete provies class for its main div but internally it uses Input which adds an extra div inside and class for that input can't be changed through AutoComplete params
There's attr:class which gets applied to input, basically right now we have:
<div> - with `class` available as `class` (`thaw-auto-complet` by default)
<div> - with hard-coded `thaw-input` class
<input> - with class available as `attr:class`
using input_class for 2nd level div would be confusing at least
Not right now. I think the core problem here comes from this implicit nesting of Input inside of AutoComplete: ideally we should have only one div, it looks like on:keydown and class could be moved into Input but I'm not sure about auto_complete_ref what is it used for (BTW the guide doesn't quite tell much about it)?
One more detail: in Input there's a warning of one uses attr:class so I get in console:
Thaw: The 'class' attribute already exists on elements inside the Input component, which may cause conflicts.
basically it means that the third option (overriding input class with attr:class) isn't advised by the library at the moment.
but I'm not sure about auto_complete_ref what is it used for
auto_complete_ref is mainly used to get the DOM position in real time to display the popup position.
Also, can you write an example of your needs?
In my example I was trying to fit it into tailwind css classes written by another engineer. It's just a prototype so maybe we'll just throw away that piece of code soon.
@luoxiaozero could you help me finding PR/commit which fixed this? (cross-links could be helpful for cases like this BTW)
Sorry, I thought you no longer need this feature. I will reopen issue.
cross-links could be helpful for cases like this BTW
What does cross-links mean?
with a cross-link I meant a link between a PR or commit and a ticket, e.g. Github finds those and adds to the ticket.