Closed bob2517 closed 1 year ago
The other option to avoid "no network" situations is to always check for a network connection before attempting to load ajax, which can currently be done using the @if statement with regular javascript.
This is now on the branch.
Needs a bit more done on this, otherwise scoped component failure events is going to become an issue - &:afterAjaxError would be a better syntax for self-imploding components. May remove clock-component:afterAjaxError.
[edit] Actually, I'm not so sure about it being an issue. Will test it. That additional syntax would be useful anyway though.
[edit] Yeah, as suspected it's not an issue. The clock-component:afterAjaxError event will work regardless of scope and target the correct element. I'm adding the other & syntax which will be a pseudonym for the main one and that should be it.
Actually, gonna skip it. It might end up getting confusing to use with additional ajax running in the component after initial load, so not sure what benefit it will bring. It will stay as component-name:afterAjaxError etc. for now. It's on the branch.
Closing in preparation for release.
Will be committing a fix for this in a moment.
If a component fails to import HTML or CSS due to an ajax error, it will run one error event even if both html and css fails to load. The assumption being that if either one fails, the component is rendered useless. So we only want one error.
There will be both an afterAjaxError event to catch general ajax errors, and specific events like afterAjax404.
The error event will occur on the element name itself, like:
To repeat, the event will only ever run once, even if it fails on both HTML and CSS import.
When the component fails, an attribute will be added to the component element so that the developer can deal with it manually. It will be done this way so that the developer can clean up as is appropriate for the situation. The component will be useless at this point, and it will be up to the developer to decide how and when it would be redrawn, depending on the circumstance. Eg. a growl message could display saying there's been an error and to try again in a moment, with the developer manually removing the component tag. Or maybe it needs to be a fatal error for whatever reason and the tag would just stay there.
A failed component element will look like this as HTML: