I found myself thinking last night of the problem in Angular that is the form validations and the puzzle of what to do as suggested here. My incel (involuntary celibate) acerbic persona has no children as this is what I do with my time on the weekends. It's probably best that I'm a programmer instead of a project manager or scrum master or something. Anyhow, I wrestle with whether or not it is best to serialize a set of validation rules and hand them over the wire from the headless app to the Angular frontend as there is a performance hit with that. I'm leaning towards concluding that this information should just come once and then get cached. I hate the idea that it would only exist in the UI as the UI is really a different app and that would mean that the main app would have no idea of how to validate itself. That might be fine but my mind fights it. It seems like rulesets for what is sane are part of the core logic in Onion Architecture. I guess you can break with the DRY principal and write validations in both places. Honestly, as it is we are writing dupes for C# side POCOs that make their way into TypeScript and the TypeScript classes their object instances map to. This talk touched on trying to fix the bigger duplicate code maintenance problem but I don't recall it mentioning the validations and there is probably not support for that. You don't want to roll your own code generation implementation as other developers will hate you when they follow your work and deal with the thing you thought was awesome that isn't really awesome. Don't get creative.
No comments:
Post a Comment