[LiveComponent] Allow disabling the error modal in production
YummYume opened this issue · comments
Hello 👋
Live components have a great error modal when something goes wrong on the server, however, it currently displays even in production, and I believe it's often not a wanted behaviour to display an error. I'm aware that it's possible to use the response:error event to stop the modal from rendering, but it would be great if we could do that globally (for all live components at once). Should it be a good idea to dispatch the error event on the window as well for that purpose ? It could then be easy to dispatch a toast each time an error occurs.
Another issue with the current handling of errors is that loading states are not removed, which means that, for example, a disabled submit button will stay disabled. This is explained in #1463. I believe this can be easily fixed by triggering the loading.state:finished event after handling the error. What do you all think ?
PS : The modal could use some accessibility improvements, I'm up for a PR
Hey @YummYume !
What a nice, complete bug report :)
I agree with your vision and i'd go even further: i believe we should not only "allow disabling" but "force disable" when kernel.debug !==true
I'd probably split your ideas in 3 distinct PR
- one handling the visibility/usage of the error modal depending on a configuration param ( = kernel.debug per default)
- one related to event (but i do think this is already possible... but maybe not 😅 )
- one related to fixing the loading states and stuff
This last one could even include some debug/log capacities depending on env too ?
So if you want to start one, two or the three, any help would be very welcomed and appreciated :)
And don't hesitate to start with minimal one / poc if you want and we can iterate from this !
Hi !
I agree that it should definitely not be present in production at all, and people should be "forced" to add their own error handling. At the very least, the modal shouldn't be present in production (and probably not tests either ?), and the component should still work, by simply removing the loaders and keeping the same state as before. It would maybe even be a good option to add a data-error, to show something only when an error occurs ? It could be an interesting idea.
I'll gladly start working on the third point you mentioned, which is to remove loading states (which is crucial in my opinion). By debug/log, you mean in the browser's console ? I'll also check to see if it's possible to catch the event globally, but I'm not sure since I think the events are not native JS events.
Nice!
And really, feel free to ask / poke / mail if you need any help, or want to chat about some work in progress stuff :)
Hi @smnandre !
I have been working on this data-error plugin as well as the proper clearing of loading state on error. It all works fine, and I'll make a PR soon after adding tests (and some documentation).
There's a catch, though. The attribute data-error seems so generic to me that it could be possible some people are already using it for other stuff, and it could technically break things on their end. Do you think there be a setting to allow changing the name of this attribute ?
I also changed the fact that, if you enter an error state but already have another request pending, then it executed as it should (it wasn't before), which pretty much instantly clears the error state, but honours the event hooks chain. Do you think this is a good thing ? I personally would expect pending requests to proceed, even if the current one failed.
Hey @YummYume! Thanks for your PR that's an excellent topic! But I think we should go a little further on this. Sorry, I am coming late.
You could need for example if your Component encounters an issue to display a completely different template for your component. For example, a text: Oups the loading of your avatar failed click on this button to reload the page, and a button to reload the page.
So I think we should give options to the developer to easily defined a different template if the component failed.
I have several solutions for this:
- we can add to #[AsLiveComponent] [AsTwigComponent], a template_error key. So when the Component fails Symfony renders this template error.
I don't really like this solution because I wanted that to be easily done by a front-end developer. - we can reuse the template component but with a error variable, so the front end developper can use this variable to detect the error and display what we want
- or we can just say every template inside /components/_errors/component_name.html.twig is the template that we use to render the error
But I am not sure as well, since this add more convention.
Tell me WDYT?
I think actually what I am talking here can be done in addition to your! I just want to start the discussion with you since you already start working on the PR.
friendly ping @smnandre
@WebMamba this is a parralel question i think.
Here we're talking about cases where we get a 400/500 error (server down, page not found...) so this is the "JS" handling.
To implement your ideas, i think we would have to improve back-end error catching/handling.
(but i'm not sure we should do something that complex... i mean symfony framework has only one error page per default..)
So i suggest:
1/ we work on this one
2/ we work on the back-end one / your ideas
3/ we see how to link/mix both (handling then 404 with JSON responses)
WDYT ?
Hi ! Thanks for the great suggestions.
@WebMamba I actually thought of this before. I'm personally in favour of having an error template for components, but I'm also not too familiar with the current error catching that is done on (live) components on the server side... So perhaps it should be the first priority, as @smnandre said.
When using JS frameworks, it's very common to have "error" templates, whether it'd be in your routing or in a component. So I think it's a great idea in the future, because as much as we want to avoid them, 500 errors will always occur.
My current idea (and implementation) is just to have a simple JS attribute to, at the very least, display a potential error message to the user, to have the component still work (by clearing loading states) and to disable the current error modal by default in production (I don't think anyone wants that).