This PR aims to solve how errors are both sent from FuelPHP's core and handled by the front-end.
Changes
Adds 'status' field to Msg objects
post_call and get_call in fuel/app/classes/controller/api.php are responsible for handling responses. These will now recursively search for a 'status' field in the called function result and set that as the response status rather than an erroneous 200.
Adds a global error handler to api.js. This essentially checks the status code if the response returns not OK and throws an error for individual error handlers to catch. This handler accounts for the variety of responses that can be sent from the back-end. For example:
If a response uses the Response class rather than the Msg class, the error will be stored in the body field and must be parsed as JSON.
If an error was stored in the body of a response with a 200 status code, the handler will throw an error. I tried to find all accounts of this happening, but it's possible I missed some, so I've left this check in.
Changes all fetch calls to the api/json/___ route to use fetchGet which automatically configures the POST options and invokes the global error handler.
I also took the liberty of reorganizing API calls by route
Moves all error handling from success handlers to error handlers.
This caused an issue with how the header detects whether a user is logged in by using user_get. The user_get function returns a 403 error if the user is not logged in. A non-logged in user would then get spammed with 403's in the console. Instead of changing user_get, which needs to return 403 in some situations, I added apiAuthorVerify to gate this API call.
Collaborator dialog similarly ran into issues, and these have been fixed
Added alert dialog to several components, including My Widgets Page, Profile Page, and the Settings Page
Updated styling for error/success feedback in the Support Dashboard to be more obvious
Updated tests
What's Left
Not all errors are being appropriately communicated to the user, except for perhaps invalid login. For example, deleting a widget in the Support Dashboard without the appropriate permissions would simply say "Error: Delete Unsuccessful" without giving a reason why. I need to do more research into what exactly should be conveyed to the user.
This PR aims to solve how errors are both sent from FuelPHP's core and handled by the front-end.
Changes
Msgobjectspost_callandget_callinfuel/app/classes/controller/api.phpare responsible for handling responses. These will now recursively search for a 'status' field in the called function result and set that as the response status rather than an erroneous 200.api.js. This essentially checks the status code if the response returns not OK and throws an error for individual error handlers to catch. This handler accounts for the variety of responses that can be sent from the back-end. For example:Responseclass rather than theMsgclass, the error will be stored in thebodyfield and must be parsed as JSON.fetchcalls to theapi/json/___route to usefetchGetwhich automatically configures the POST options and invokes the global error handler.user_get. Theuser_getfunction returns a 403 error if the user is not logged in. A non-logged in user would then get spammed with 403's in the console. Instead of changinguser_get, which needs to return 403 in some situations, I addedapiAuthorVerifyto gate this API call.What's Left