Introduce FE lib/logger for errors
- Introduce FE lib/logger for errors
- Log hello message in browser console
- Add logging docs to FE guide
What does this MR do?
This MR introduces a ~/lib/logger
module and a simple logError
function which will be the standard for client-side logging of errors. Currently, we just have a number of places where we console.error
with a eslint-disable
. Having a single function for this will help us control and promote logging errors.
Other potential benefits:
- Improved control of testing for
logError
in tests vs.console.error
- Improved control for how we want to observe the
logError
events. We want client-side logging to be complete and helpful, but we might only want to observe a sample of these.
Screenshots or Screencasts (strongly suggested)
How to setup and validate locally (strongly suggested)
This MR refactors a recent console.error
addition to a Deploy Freeze enhancement (see !66331 (merged)) to use logErorr
.
To test this error logging:
- Open the CI/CD settings for a project (e.g.
/gitlab-org/gitlab-shell/-/settings/ci_cd
) - Open the browser's console and open the "Network" tab
- Scroll to
Deploy freezes
and insert a new deploy freeze (if one doesn't exist already) - In the browser's developer network tab, find the request used to insert / fetch the deploy freeze (
api/v4/projects/2/freeze_periods
). Block the URL of this request (found by right clicking the request). - Click the trash icon next to the newly added deploy freeze.
- The request should fail since the URL was blocked and an error will be logged to the console.
Does this MR meet the acceptance criteria?
Conformity
-
I have included changelog trailers, or none are needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides. -
This change is backwards compatible across updates, or this does not apply.
Edited by Paul Slaughter