Would it be possible to have more control when intercepting errors?

[vesper8]

I would like to return additional information when intercepting errors, such as the location.href so I know exactly from which URL the error occurred.. and possibly other things.

Instead of just a true/false option could we maybe use a closure or have a means of transforming the response before it is sent to ray?

Along the same vein, and as we previously discussed on Discord, it would be nice to have a single centralized place where I could add some logic such as "only forward to ray() if X condition is met". So for example I could set it up so that it would only forward to ray if a specific user is logged in, or if a specific query parameter is present. Or if the current date is before a specific date.

Funny anecdote.. we worked together to allow a solution where I can have my production apps forward to my local Ray app using an always-up Expose tunnel.. well I accidentally deployed a version of a PWA with interceptErrors set to true and now I have a bunch of user clients sending a constant stream of errors to my local Ray app.. and even though I can deploy a new version without this flag set to true.. due to the nature of PWAs and service workers.. it could be a while before all those clients actually update to the new version so for the time being I have no way of putting a stop to the stream of errors, even if I've fixed those errors. I'd have to stop the Expose tunnel and set up a new one which would mean that I'd have to change the Ray host config in multiple projects.. very annoying.

In the future in order to avoid such a thing I would always set a condition such as mentioned above so that regular users won't be spamming me with errors.. or if they do then they won't beyond a certain date.

[patinthehat]

I love the idea of allowing a closure instead of a boolean. This feature will be added soon.

I'm intrigued by your idea to conditionally forward calls to ray. My hesitation is that I try to mirror the original spatie/ray features closely, and it doesn't have this feature.

That said, I think your anecdote is instructive and I imagine that you're not the only instance where this has happened. I'll add this feature as well.

[patinthehat]

@vesper8 Are you specifically referring to Vue errors, javascript errors, or both?

[patinthehat]

Preview of the feature for appending additional data to error messages:

[vesper8]

I like it :)

Will that section support arrays too or just strings? I'm hoping both

[patinthehat]

I'm implementing the same code that pretty-prints objects, arrays, etc., so it'll support any data type 😄

[patinthehat]

I'm working on updating the documentation, but v1.16.0 supports specifying the interceptErrors option as a function that returns data to be displayed along with the error message.

As for your other request, I've added payload callback options and an enabled callback option to vue-ray (these get passed directly to node-ray). These callbacks allows using a closure to determine if vue-ray is enabled as well as providing the ability to send data to ray before/after each payload is sent.

Stay tuned for an update to the docs.