Hi, thanks for the suggestion.

The first thing I'd say is FluentValidation is specifically not intended to be a tool for generating client-side validation rules and this is something I'd consider to be very much out of scope. The type of constraints needed between server-side and client-side are generally different enough that it's better to maintain clientside rules separately from serverside as trying to use a single source for both will result in compromise and limitations on what you can use on both ends, so my strong recommendation would not be to go down this route (although I can't stop you from doing so if you really want to). Although clientside validation and serverside validation are similar, they do actually have separate goals & constraints and I think it's a mistake to try and generate the two from a single source unless it's for the simplest of use cases.

With that out of the way I'll try and address the specific suggestions:

Replacing the type for conditions from Func to Expression<Func and exposing the condition in IRuleComponent

Changing the condition to an expression is something we absolutely don't want to do. Expression compilation is expensive and should be avoided unless absolutely necessary, and even with caching it's not ideal. I've done a lot of work on FluentValidation's performance over the years and handling of expressions are 100% the biggest issue - this would become significantly worse if conditions were changed to be expressions too, so I'm afraid this isn't a change that I'm willing to make.

Alternatively exposing a public version of OnItemAdded (OnRuleAdded perhaps ?) on AbstractValidator

I'm much more open to this, although I'm very wary of opening up internal methods of the library as I've been bitten before by having too much public, which then drastically increases the maintenance burden. I'll have a think about this one though.

However I would still strongly encourage you not to go down this route, it leads to more headaches than it solves in the long run.

Hi @JeremySkinner, thanks for the agreeably quick response.

I get not wanting to introduce Expressions, I figured performance was going to be an issue, it's not for us in this context but hey I had to try =P

Regarding the scope the FV, that's very fair too of course, although in our particular case the exporting of FV schemas to Yup schemas stemmed from a willingness to avoid duplicated code and to introduce more client side validation at basically reduced cost, simply put the exporter can't export everything, by being a bit careful it will only export what's common between sever and client validation (meaning no validation against the DbContext) and Yup schemas are easily customizable/overridable

How about adding something like this on AbstractValidator ? :

	public IDisposable OnRuleAdded(Action<IValidationRule<T>> onItemAdded) {
		return Rules.OnItemAdded((_) => onItemAdded(_));
	}

No need to make public anything that isn't already, won't solve all of my problems but it should take care of the When(condition, action) case

Butter fingers on my part, reopening the ticket

11.8 is released with this change