Haven't heard of that one either. Just from reading the landing page you linked me, I was struck by:
1) Overriding css seems hacky; I must use !important?! Srsly? How about it not use it's own classes at all if something's passed in?
2) it paints the DOM structure for literally the whole form. The approach satisfies me as an engineer but I have a feeling it won't mesh well when you have a pure designer (HTML/CSS) on the team. Or if designers made pretty input box elements or whatever in a library; can it somehow use that, not knowing the internal structure of proprietary ui components?
3) I don't see how it knows to compare passwords in the last example. Convention over configuration?
4) formControlName seems redundant between having both title and type around. (Granted, type is rarely unique, but sometimes it is, and title is almost certainly unique.) Yeah I know that's Angular's not the library's. Icon seems like it should be part of the CSS class, not in the code, and could also hang off of the type attribute.
5) passing the text of the submit button seems highly over-specific, but I understand it's making the whole form from scratch.
6) unclear why every AbstractControl must clutter the controller.
7) IIRC the validators array can also take a lambda accepting.. the value? the whole form? ... but I seem to remember Angular having a bad time if the lambda depended upon an outside var. Like it wouldn't re-render or something. Have to check my old Stackoverflow posts. Still, it's mostly good.
8) async doLogin didn't return its promise, so the form would know when teh server is done? (Oh, it's used as an event handler.)
It's got potential as a nice solution as long as #2 isn't a practical problem. Even then I nitpick the syntax as too verbose. Maybe every FormField object should add a property for the AbstractControl so they aren't running around loose in the controller. Maybe the FormField[] and the errors[] could be under a single umbrella object to avoid cluttering the controller, or, each FormField has its own errors. Maybe FormField itself could be slimmed down with reasonable defaults for formControlName and removing icon or other CSS completely. Using one's own CSS should never be so clunky. Maybe the umbrella object can have a prop for a Promise-returning submit function so it knows when to re-run validation on server return in case of server-side validation failing.
The final comment in one example regarding "we know fields X and Y are at indexes 0 and 1" screams "hacky magic numbers" to me.
Maybe #2 could be addressed by configuration: inform the library of the shape of your datepicker, of your styled inputs and validation errors, by way of some sort of template passed to forRoot(), so the form it dynamically creates matches your employer's chosen standard.
Thanks for the feedback , you have some great points I appreciate the time you took going into detail with each one.
This is a new project I made while working on a very simple app so I will have to make the form builder more configurable to meet other people's needs
To address some of your points
1) It actually does work like that , when you pass in css classes it uses those instead , When explaining how it works , I was leaning more towards explaining the usage example , I will change the the docs to be more clear on that
2) Probably another case of better docs , the form builder uses mostly ion-components , so DOM structure should be customisable a very decent amount.
3) When your FormFeild object array contains the controllers password and confirm_password then the form builder knows its a case of password validation
4) type is the input type i.e
<inputtype="text">
title is for the label , and formControlName is used by angular formbuilder when building the actual form , these could be very different
8) If you read the the scenario description , I make the assumption that there is a service api that implements a login function that returns a promise, doLogin just calls that function and when it fails the catch block handles that error. This is for the purpose of describing a use case for setting individual field errors
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article , Here is one of those solutions to make it nice
dev.to/ronaldhove/a-custom-form-bu...
Haven't heard of that one either. Just from reading the landing page you linked me, I was struck by:
1) Overriding css seems hacky; I must use !important?! Srsly? How about it not use it's own classes at all if something's passed in?
2) it paints the DOM structure for literally the whole form. The approach satisfies me as an engineer but I have a feeling it won't mesh well when you have a pure designer (HTML/CSS) on the team. Or if designers made pretty input box elements or whatever in a library; can it somehow use that, not knowing the internal structure of proprietary ui components?
3) I don't see how it knows to compare passwords in the last example. Convention over configuration?
4) formControlName seems redundant between having both title and type around. (Granted, type is rarely unique, but sometimes it is, and title is almost certainly unique.) Yeah I know that's Angular's not the library's. Icon seems like it should be part of the CSS class, not in the code, and could also hang off of the type attribute.
5) passing the text of the submit button seems highly over-specific, but I understand it's making the whole form from scratch.
6) unclear why every AbstractControl must clutter the controller.
7) IIRC the validators array can also take a lambda accepting.. the value? the whole form? ... but I seem to remember Angular having a bad time if the lambda depended upon an outside var. Like it wouldn't re-render or something. Have to check my old Stackoverflow posts. Still, it's mostly good.
8) async doLogin didn't return its promise, so the form would know when teh server is done? (Oh, it's used as an event handler.)
It's got potential as a nice solution as long as #2 isn't a practical problem. Even then I nitpick the syntax as too verbose. Maybe every FormField object should add a property for the AbstractControl so they aren't running around loose in the controller. Maybe the FormField[] and the errors[] could be under a single umbrella object to avoid cluttering the controller, or, each FormField has its own errors. Maybe FormField itself could be slimmed down with reasonable defaults for formControlName and removing icon or other CSS completely. Using one's own CSS should never be so clunky. Maybe the umbrella object can have a prop for a Promise-returning submit function so it knows when to re-run validation on server return in case of server-side validation failing.
The final comment in one example regarding "we know fields X and Y are at indexes 0 and 1" screams "hacky magic numbers" to me.
Maybe #2 could be addressed by configuration: inform the library of the shape of your datepicker, of your styled inputs and validation errors, by way of some sort of template passed to forRoot(), so the form it dynamically creates matches your employer's chosen standard.
Thanks for the suggestion.
Thanks for the feedback , you have some great points I appreciate the time you took going into detail with each one.
This is a new project I made while working on a very simple app so I will have to make the form builder more configurable to meet other people's needs
To address some of your points
1) It actually does work like that , when you pass in css classes it uses those instead , When explaining how it works , I was leaning more towards explaining the usage example , I will change the the docs to be more clear on that
2) Probably another case of better docs , the form builder uses mostly ion-components , so DOM structure should be customisable a very decent amount.
3) When your FormFeild object array contains the controllers password and confirm_password then the form builder knows its a case of password validation
4) type is the input type i.e
title is for the label , and formControlName is used by angular formbuilder when building the actual form , these could be very different
8) If you read the the scenario description , I make the assumption that there is a service api that implements a login function that returns a promise, doLogin just calls that function and when it fails the catch block handles that error. This is for the purpose of describing a use case for setting individual field errors