Help message class

[kingcody]

Hi there,

First off, I'd like to say; nice module, thanks for sharing it!

I'm actually using this for a Bootstrap 4 based project and for the most part it works great. However in bootstrap 4(alpha,beta) the help block's classes have changed. I was wondering if you had any thoughts on a nice clean way that could be customized. Obviously another parameter to the forRoot method would work, but that seems a bit excessive.

For now, I'm using Bootstrap 4 alpha, so I've patched the help block class:

.help-block { @extend .form-control-feedback; }

Which works perfectly and is fairly unintrusive.

Anyways, I just figured it might be a topic worth discussing, thanks again.

[third774]

Thanks for mentioning this!

Can you expand on what you mean by excessive? Configuring the module in one place with a class that should be used everywhere seems reasonable, but I could definitely see situations where people may want to individually customize the classes in a specific place.

Right now there isn't a component that is used to display error messages, but I'm thinking about introducing one to solve the issue (https://github.com/third774/ng-bootstrap-form-validation/issues/6) with horizontal forms. (Quick aside on that - the conditions that the messages are displayed would still be managed internally within the new component) This new error message component could potentially accept a class input to over-ride the top level configuration.

[kingcody]

Hey there, sorry for taking so long to get back to this.

On the thought of how validation messages are configured now; what do you think about using a multi-provider as the means of configuration. It would be inline with how custom validators and interceptors are configured. You could swap your array order for the messages array like this:

  get errorMessages(): ErrorMessage[] {
    return [
      ...this.errorMessageService.errorMessages,
      ...this.customErrorMessages
    ];
}

and then just use something like lastIndexOf

Related to #6, I think that a separate component would definitely be in order. I think the placement logic in the form-group-component is real fun part. lol

Back to the original question, after thinking about it for a bit (ok, about a month lol), configuring the style class in the forRoot static method would work for how this module is used. Most components are configured at a template or controller level so I think it just initially threw me off; but seeing as how this module acts fairly transparently at the component level it makes sense to configure it at a module level.