feat: add QuantityInput component #378
Conversation
micgro42
force-pushed
the
QuantityInput
branch
3 times, most recently
from
67d30c7
to
ce89206
Compare
micgro42
force-pushed
the
QuantityInput
branch
5 times, most recently
from
2b3edfe
to
dc786ec
Compare
|
This looks great. I give it 1000 cabbage 🥬 I made some small changes to the style of the entered value/quantity indicators (as always), and replaced the error copies just to see if the ones indicated in the designs are clear enough. While doing that, I noticed the nit-pickiest thing: that the error message of the second QuantityInput (when the unit field is being validated) is not properly aligned like the rest. I wasn't sure what's causing it or how to fix it:
Regarding the transparent end border applied to the first field: this make the component look closer to the designs, but the solution is a bit hacky. In case there's not a better way to achieve creating that shared 1px border, it might be better to make the border visible instead. |
| .wikit-Lookup__label { | ||
| position: absolute; | ||
| width: 1px; | ||
| height: 1px; |
There was a problem hiding this comment.
there are no tokens here ?
There was a problem hiding this comment.
There could be? But I don't get to understand what are they styling 🤔
There was a problem hiding this comment.
Ah, this was hiding the Label from the Lookup component so that it is still readable to screen readers. But we're no longer using the Lookup, but the LookupInput, so this is now unused code and can be removed.
Done.
| const enteredNumberText = '123'; | ||
|
|
||
| wrapper.findComponent( Input ).vm.$emit( 'input', enteredNumberText ); | ||
| await wrapper.vm.$nextTick(); |
There was a problem hiding this comment.
maybe also here ?
see comment here
|
P.S. |
Mh, that looks perfectly fine to me: What browser are you using and does this also happen on other validation messages? |
I have to confess, I'm only aware of different bad solutions.:
|
Chrome on MacOS. This issue is tinny, though. Finding whatever might be causing it is the interesting part, but it shouldn't be a blocker from a UI perspective. Regarding the transparent border, I understand how this was the only approach possible to translate the design..but looking at the result, I'd say that we should use the double border for now (although it's not ideal) to avoid both the inconsistencies between states and the hacky-looking corners:
|
Validation is done inside the application after all.
wip
#377 needs to be merged first because this PR here needs it validation functionality.