OK, this is a pretty massive PR, so @rynowak / @javiercn / @pranavkm - would any of you like me to give you a 30-minute tour of the changes and new features? Or if you prefer just to dive into the code that's completely fine with me too.

Features

• EditContext - this tracks metadata about an edit process (e.g., what's been modified, current validation messages, etc.). It doesn't do any actual validation itself, but rather has an API designed to let external systems hook into it. External things can get notification about when fields are edited so they can choose to validate if they want.
• EditForm - this creates an EditContext for you and cascades it down to contents. It also provides extra events (OnValidSubmit, OnInvalidSubmit, though you can still use OnSubmit directly if you want to trigger the validation yourself based on your own lifecycle design).
• DataAnnotationsValidator - this attaches data annotations support to an EditContext
• ValidationSummary - like the one in MVC
• Built-in input components (InputText, InputCheckbox, InputSelect, etc.). These provide default behavior of validating on edit and changing their CSS class to reflect field state. Some of them have useful parsing logic (e.g., InputDate and InputNumber handle unparseable values gracefully by registering them as validation errors). The relevant ones also support nullability of the target field (e.g., int?).

For usage examples, see the new test cases in the E2E BasicTestApp:

• SimpleValidationComponent
• TypicalValidationComponent
• NotifyPropertyChangedValidationComponent

Still to do for preview 3

• Make the build pass. Need to check with @natemcmaster what's needed to deal with the platform manifest error. Should be OK now.
• Rebase on master. This is tricky because in the last few days, the repo stopped taking a dependency on DataAnnotations, so I need to put that back. And first I need approval to join the darc group, etc. Done
• E2E tests. The test cases themselves are implemented - I just haven't written the Selenium automation for them yet. Done
• Maybe implement a ValidationMessage component, which would be trivial. Or developers can implement it themseles. By design, these sorts of things don't require priviledged access to any internal APIs. Implemented.
• Remove the manual usages of *Expression from the test cases once this enhancement gets merged into Razor: Components that accept bind-Something can request SomethingExpression razor#213 Not waiting for this.

Further enhancements planned for after preview 3

• Async validation. I have a design in mind, but there's only so much can get done in time for Preview 3, and it would be good to get some customer feedback before trying to do everything.
• Maybe some way to configure a default validation system, so you don't have to put <DataAnnotationsValidator> in every EditForm if that's what you're using.
• Maybe some way to override the default CSS classes on the built-in Input* components
• Ideally (though nontrivial), support for splatting attributes on Razor Components. Then we could make the built-in input controls automatically pass through all extra attributes, and developers who subclass them can still get that attribute passthrough behavior. Until we do something like this, some basic use cases like setting a maxlength on InputText just aren't supported (or at least, you have to subclass InputText and put that feature on your subclass, which is inconvenient).