can you add tailplaceholder as parameter, like MaskedTexfieldDelegate(primaryFormat: [99] / [99], isTailPlaceholderVisible: true) about input-mask-ios HOT 3 CLOSED

Hey @margulan97
Thanks for your question. Let's discuss our options.

I understand it would've been much more convenient to have this feature in the library core so you could simply turn it on like a boolean flag, yet there are a few things that stop me from the implementation.

Imagine having this string as a part of the input. Should there be an option to place a cursor somewhere inside? Should it somehow trigger autocompletion? Will you be able to select parts of the placeholder and copy them? Should you be able to select the entered value with parts of the tail placeholder? Should the library somehow process the "Select All" click, so that only the entered value gets selected?

A dozen of UX questions, and most of them have nothing to do with the library scope. A no-go.
Thus, the tail placeholder should be… a placeholder. Non-selectable. Check ✅

There's a couple of reasonable and almost equivalent ways to implement such a placeholder: draw it on canvas or just drop down a UILabel.

Both of those ways require us to know the width of the entered string in pixels in order to correctly layout the "tail".
This is already an ambiguous topic. See, at the moment, even the designated way to calculate this width requires developers to (omfg) cast your String to an NSString. But okay, I've considered this as a minor evil, so here you go.

Here, the library must already be aware about your app's fonts. In order to calculate the text width in pixels, I've got to know the exact UIFont. This is out of scope, this library is not about theming, but okay.

And then, I've got to know how to draw the tail placeholder. Fonts, colours, the text size. For both light and dark theme.
So I've got to include options for you to apply your app's theme, and you know there're plenty. This is for sure out of scope.

You've got to understand that I'll have to maintain the support for all of these handles and theming. Take a look at the UITextField wrapper and its extension that I've made in order to support SwiftUI. Those are huge, and most of the code is a stupid monkey job.

Instead, you could simply throw in your own UILabel above your own UITextField with your own already-implemented-in-your-own-project themes, tweaks and everything.

I'll calculate the tailPlaceholder and the text width for you; the only thing that's left is just to wire everything together:

label.text = tailPlaceholder
label_something_constraint.constant = value.boxSizeWithFont(myFont).width

I think, this trade-off is obvious (-:

from input-mask-ios.

thanks for the reply. I have a crutch solution through a parameter that I implemented. But I think it goes against the logic of the library. In any case, thank you so much for giving a detailed answer.

from input-mask-ios.

But I think it goes against the logic of the library.

Well, it's a little bit off, and I'd rather go for a full-fledged separate component that includes both the view and its "controller", but… :D

I've made everything open on purpose. You've got to be able to get under the hood and alter the guts to the extent that suits you, and call super when you'd like to fall back. So it's really up to you.

I'd be happy to put more instruments to the core, so you just let me know.

from input-mask-ios.