Improved values

[noahsalvi]

This discussion is based on the following comment by @manterfield

Would it be possible to introduce another action to solve this, allowing custom coercion?

e.g. use:coerce={asString}

This would have benefits over using the builtin valueAsDate/valueAsNumber fields as users could extend to any custom types.

We need this, so I'd be happy to pick it up if agreement can be reached on an approach (and that approach fits our current need).

I'll be solving this in our app either way, so others may as well get the benefit.

I believe that adding a new action as proposed is a good idea. However, I'm unsure on how we would go about adding typings. e.g. if one would coerce to a date, they would most likely expect that $form.someControl.value would also be of the same type. Furthermore since actions are only evaluated at runtime we couldn't really work with type inference here. As a consequence it would need to be defined inside the params of the useForm call. This would then again have the side effect that the default type for value would need to be any which would conflict with PR #63 by @Marnes.

What are your thoughts on this?

[manterfield]

Those are good points. In an ideal world we'd have a way to access the converted values with full type safety, but we might have to settle for any/unknown.

If it could be done via the existing value field then that would be quite neat, but for me it's not a complete necessity. I can still see a logic in the value mapping to the raw value as would be seen on the form element itself (like today), with a different field for typedValue or similar. I don't have a massively strong preference one way or the other. Thoughts?

The most important feature for my use case (and I suspect others) would be the ability to get an object containing all the type converted key/value pairs so we can throw them at a backend API easily. Again though, I'd be quite happy for that to be a typedValues property if necessary.

Another requirement that may be less common is that fields would be able to set their converter/define what converter to use themselves. This would mean I could dynamically construct forms without duplicating per-field info at the top level and in the markup.

The hacky version I've bashed out for now just passes a writable store to each field component, which then binds the field value and runs a function that casts the type. It works just fine, but it's a lot of boilerplate (when compared to how lovely and compact this lib is for handling the rest) and nowhere near as slick as what I think could be created as part of this package.

---

I need to have a think about different approaches and maybe try to spike a couple. In the meantime very happy to hear anyone's thoughts, or what you would and wouldn't be happy to w/regards to the API exposed to users.

[noahsalvi]

I can definitely get behind your logic on why separating it into a separate field would make sense. Perhaps a different word than "typed" should be used like "transformed", "coerced", "converted", "mapped" or "piped".

Another requirement that may be less common is that fields would be able to set their converter/define what converter to use themselves. This would mean I could dynamically construct forms without duplicating per-field info at the top level and in the markup.

Do you mean by that the use of an action that could be used on an input element to bind the converter to it?

[manterfield]

Do you mean by that the use of an action that could be used on an input element to bind the converter to it?

Yes, exactly that. I'm not sure how that could work in practice, but I wouldn't want half the field level config to be on the main form and the rest to be on the fields (as validators are currently on the fields).

I also think part of what makes this library feel so lovely is that validation is just sticking an action on the input. It makes it feel trivial where lots of packages make it feel very complex. I wouldn't want to lose that.

I'm totally easy on the name for the field, really have no strong opinion there.