Version 0.0.5 of my GuildRunner sandbox Angular 2 application was focused on updating the model object graph of the application (mainly to provide more opportunities for exploring forms), which included the following changes:
- Removed the Address domain class and replaced it with a Location object containing traditional, basic address properties.
- Created a Person class containing properties such as first name and last name as well as a "residence" property that is an instance of Location.
- Added the concept of "Chapter", where each Guild has a number of geographically-based Chapters. Each Chapter domain class is associated with a Guild and has a "location" property that is an instance of ChapterLocation, another new domain class that extends Location and contains properties like "floors" and "entryPoints".
- Removed the Member domain class and replaced it with ChapterMember, which extends the Person class.
- Simplified the Guild domain class.
- Created new master list view for the Chapters and ChapterMembers and added them to the navigation bar.
Version 0.0.4 of my GuildRunner sandbox Angular 2 application is now available.
In an earlier post, I shared my thoughts after working through the examples on the official documentation page for template-driven forms. I came away underwhelmed with the features designed to help with validating the form input:
The classes Angular adds to form controls to indicate the control state are based on interactions with the DOM and don't reflect the state of the model data attached to the control (for example, once a form control is marked as "dirty", changing the control value back to its original value does not re-mark it as "clean").
Some basic form control attributes (like "required") could be used to set validation constraints that Angular would use to toggle the valid/invalid class on the control, but not the validation attributes introduced in HTML5, and there was no documentation about what worked and what didn't.
Even when Angular could toggle the valid/invalid class correctly, that only indicated that the form control should be considered invalid, not why it was invalid.
(The change log for the recently released RC6 version of Angular 2 hints that some of these issues may have been addressed.)
So when I decided that the next feature of GuildRunner would be a detail component for adding or editing a guild, I knew figuring out my strategy for validating the form would be a big part of the work involved. What I came up for this release is a rough, first draft of an approach where the form takes its validation cues from validation logic and state data stored in the component. There is a lot of room for improvement should I decide that this approach is viable and a reasonable alternative to the other method of generating and managing forms in Angular 2 (dynamic forms