<@U0KMMQA20>… Apologies for pinging you directly, ...

# compose

[Bradleycorn]

@Zach Klippenstein (he/him) [MOD]… Apologies for pinging you directly, but I have a question about the (private) ValidatingOffsetMapping class that was added to text fields. I understand what it does, and why it’s there, but I have a question about how we (developers) should implement our own OffsetMapping instances to return proper offsets and avoid errors thrown by the new(ish) validator. I’ll post more in the 🧵

[Bradleycorn]

I’ll use a concrete example to facilitate my question and discussion.
Suppose we have a date entry field, and we want dates in a format of “mm/dd/yyyy”, and we use a visual transform to do masking such that A.) the user only has to type in digits, and B.) we show the mask for any un-entered digits.
So, when the user initially focuses the field, it shows “mm/dd/yyyy” with the cursor at the beginning. If the user types in say “072”, then the field updates and shows “07/2d/yyyy”, and so on.

We had this working with a fairly simply visual transform, which made use of a fairly simple OffsetMapping instance. We updated our compose version recently and started getting errors/crashes due to the new (to us) ValidatingOffsetMapping wrapper class that has been introduced.

The reason for that is because our transformedToOriginal implementation could sometimes return an offset value that is outside the bounds of the original/current text length. Using the above example, if the field currently has a value of “072” and is displaying “07/2d/yyyy”, and then the user clicks to place their cursor somewhere near the end of the mask (say, after the 2nd “y”), our transform would account for the 2 slashes that we insert, but then return an offset that is higher than 3 (the length of the actual text value). Whoops.

To fix this, we create an implementation of OffsetMapping that takes in an “originalTextLength” property, and we can use that when calculating the offset and make sure we produce a proper value. The hassle is, it seems like we’ll have to do this for EVERY OffsetMapping implementation that we create.

Here is where my question comes in … I see that the ValidatingOffsetMapping class is setup in a similar way (it gets passed the original text length and the transformed text length) … I’m not sure where/how instances of that class get created and passed those values … But would it be possible to update the methods in the OffsetMapping interface so that they get passed those values (along with the offset that is already passed)? That way ANY implementation of OffsetMapping would have those length values available so we can ensure we are producing a valid offset. I haven’t traced far enough to see where those methods are called from and if that information is available at that point, but … 🤞

[Zach Klippenstein (he/him) [MOD]]

The general consensus is that VisualTransformation is kind of a terrible API, and we’re working on an improved alternative design. We are putting most of our effort into that instead of trying to keep plugging holes in the current one.

[Bradleycorn]

Thanks @Zach Klippenstein (he/him) [MOD]

[Colton Idle]

is kind of a terrible API

so nice to hear that. i thought i was just an idiot