Grommet: Filtering of MaskedInput options isn't showing the options Drop for its last valuePart

[ShimiSun]

I'm moving a slack conversation here so we can discuss and track the concern.
https://grommet.slack.com/archives/C04LMHN59/p1568316856194000

The juice of the problem:

hey guys! could please anyone spot what I'm doing wrong here? :sweat_smile: https://codesandbox.io/s/busy-monad-197wk
I’m trying to add a “suggestion” for MaskedInput component,
the filter seems to work on the first part of the value but not on the second part...

After diving to the sandbox, the following are my conclusions.
For terminology, let's define each object inside the array of MaskedInput mask as a valuePart. so the valueParts in this case are:

1. filterKeys
2. ":" (fixed)
3. values

On the sandbox above, the filter works properly for the first part, and for the last part the options Drop opens as you reached the last value part, but does not show the filtered options after the user enters a string he would like to filter by; so although the filter logic is working correctly, the user can't see the filtered options because the Drop won't be displayed.

Currently, for usability reasons, MaskedInput will be closing its Drop after the last valuePart is filled, which make sense if you take for example the scenario of filling a MaskedInput Date MM/DD/YYYY, and the user fills in the last valuePart of 'YYYY`, then the MaskedInput will close the Drop because all valueParts are already filled, closing the Drop cleans up the UI and implies to the user his work is done which is the correct behavior for this use case.

The issue raised above is interesting and different because it embeds filtering functionality within MaskedInput, which works as expected for other valueParts until the user enters a string for the last valuePart, and then the MaskedInput assumes the last valuePart is already filled and no longer needs to shows the Drop.
I could not think of a way that the MaskedInput could know whether the value entered for the last valuePart is for filtering or it's the actual final value because the filtering functionality isn't embedded in the grommet-core behavior. Feel free to enlight me if I missed other potential ideas here for this problem.

Fixing the MaskedInput to display the Drop on the last valuePart is easy (I've fixed it on branch https://github.com/grommet/grommet/tree/fix/maskedinput-showdrop), but I don't think it is the right approach - functionality wise. For example, if we will consider the MaskedInput Date example again, then after filling the 'YYYY` valuePart, the Drop will still hang and clutter the UI although the user is done entering the input.
For the common usage of MaskedInput (which doesn't include filtering), it makes more sense to close the Drop when the last valuePart is filled, same as it behaves today to avoid cluttering the UI.

Since the filtering of the options work correctly, and the only problem isn't showing the drop due to the fact it is the last valuePart, an easy workaround to fix it is to add another valuePart of fixed that isn't active and will be considered as a valuePart, so the current last valuePart will no longer be the last and hence the Drop will be shown, the fixed value could be an empty string so there wouldn't be any visual changes with the added fixed valuePart.
See the implementation of the suggested workaround on line #67 https://codesandbox.io/s/hopeful-forest-bzbij, and this sandbox is showing the filters and suggestions as expected.

I believe this issue can be closed unless we see an ongoing discussion or other ways to solve the issue except for the provided workaround.

[ldalves]

Hey! Thanks for allocating your time in this case and reporting this issue. I think the MaskedInput component works great as it is at the moment and my use case is a bit out of "normal" use. So I believe that using the workaround is enough for the moment. Feel free to close this issue and thanks again!

[ShimiSun]

I'll keep the issue open for few more days to see if there is any further feedback from the community and maybe other users that have experienced other similar things or use MaskedInput in other creative ways.
Thanks

[ericsoderberghp]

One possible solution to this is to specify a length for the value element. That will keep the drop open as the user types until the last element's length reaches that length. This works if the values are all the same length but doesn't work if they have variable lengths. I'm still cogitating on the variable length scenario.

[ShimiSun]

I believe we can close this issue! Thank you for raising this interesting scenario, I enjoyed exploring it :)