Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow set message to return a function #93

Open
KeironLowe opened this issue Apr 20, 2020 · 2 comments
Open

Allow set message to return a function #93

KeironLowe opened this issue Apr 20, 2020 · 2 comments

Comments

@KeironLowe
Copy link

KeironLowe commented Apr 20, 2020

It would be good to allow the message attribute on setMessage to allow a function so we have more freedom with our error messages. I'm trying to make the error messages match up with with the errors returned by the server. For example, Laravel returns the following error for a missing field The :attribute field is required. with :attribute being replaced with the name of the field.

So something like...

hyperform.setMessage(element, 'valueMissing', (el) => `The ${el.name} field is required.`);
@Boldewyn
Copy link
Contributor

Yes, agreed. I’ve also already played with such an idea in the context of externally provided translations. The most important part is to get the signature of the callback function right. I.e., what information might be needed in which priority? The current element is very high up on that list, but also the type of validity error, i.e. valueMissing, since one might provide a catch-all function for several error types.

Some other helpful things might involve the default message, that would’ve been given, or the hyperform wrapper object.

I’m a bit torn between the following signatures:

callback(element, error_type, default_message, wrapper)
// or an object:
callback(parameters={element, error_type, default_message, wrapper})
// or a mixture of both:
callback(element, error_type, parameters={default_message, wrapper})

The first is simple and plain, but hard to correct, if we missed anything or the order should change. The second is extremely flexible, but a wee bit cumbersome to handle in the function body. The third is good, if element and error_type are really what one needs in 99.9% of cases from now to eternity. Otherwise it is annoyingly inconsistent to use.

@KeironLowe
Copy link
Author

I think I would tend to lead more towards option three as well. Like you mention, that would cover the far majority of use cases and it's easier to extend in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants