Open groner opened 9 years ago
Could you try and make a plunker that reproduces your scenario first?...
The reason I ask is that I just fixed an issue in 0.6.15 which caused allot of errors. But regardless of the errors, urls always catched up ones the parameters where there.
That being said, I have been around the idea my self, and I would be fine with an option for catching these errors in the link directive (if configured to do so) and mark them with a meaningful class instead.
But that might not solve the situation where sref does not watch correctly. And I would like to investigate that further, to see if that is because of the use or because of a bug.
Here is a plunk showing the issue.
The problem that caused the sref not to recover should be fixed as of the latest commit, it will by default still display the error in the console by default.
What is done now is delegating the error to the $exceptionHandler service (in angular) which defaults to logging it to console.error, obviously that can be overwritten, but then it's done so for all errors inside angular (something you might wan't to do for other reasons anyways, as logging these errors to the server or something)...
The suggestion about allowing for silently ignoring errors is still open. I am considering something more general for all errors in the framework.
We see a lot of errors from the
sref
directive when some parameters are missing. In our application this is normal while resources are still being loaded and it generates a lot of noise.In 0.6.15 the
sref
link function hits this error before the watch is registered, which leads to the url not being updated once the params are defined.It would be useful to have this fail silently, maybe adding a class that could be used to style unqualified links. If logging the error is desirable, maybe it could be made configurable? Would such a change be accepted if I wrote it?