Return to Answer

As personal opinion, I wouldn't use config as name for .value, it sounds too generic and can be confused with .config method of the module API.

Putting comments like //default is false looks confusing - why are these not default? Also it is easy to change the defaults and forget to adjust comments. Uncle Bob recommends to minimize comments and use expressive code with descriptive names instead.

function debounce(a,b,c) is great for minimizers but cryptic for code readers

In my view, using .provider is possibly an overkill as there is not much configuration logic here.

The last two comments here also apply. Instead the config JSON can be kept inside .value and decoupled from the provider.

As personal opinion, I wouldn't use config as name for .value, it sounds too generic and can be confused with .config method of the module API.

Putting comments like //default is false looks confusing - why are these not default? Also it is easy to change the defaults and forget to adjust comments. Uncle Bob recommends to minimize comments and use expressive code with descriptive names instead.

function debounce(a,b,c) is great for minimizers but cryptic for code readers

In my view, using .provider is possibly an overkill as there is not much configuration logic here.

The last two comments here also apply. Instead the config JSON can be kept inside .value and decoupled from the provider.