브라우저 로그인

모든 노드.js 프로그램은 어떤 단계의 로그를 사용하여 프로그램의 진도를 통신합니다.그러나 우리는 전단 코드에서 로그 기록을 거의 보지 못한다.이것은 주로 다음과 같다.

프런트엔드 개발자는 이미 UI를 통해 많은 피드백을 얻었다.

console 객체의 브라우저 간 호환성 기록은 매우 나쁩니다. 예를 들어 IE8 콘솔에서 DevTools 패널이 열릴 때만 사용할 수 있습니다. 이것은 말할 것도 없이 많은 혼란을 초래합니다.)

따라서 한 전단 개발자가 React 프로젝트의 오류를 기록하는 방법을 물었을 때 나는 놀라지 않았다.

Should logs be freely used everywhere and leave it up to the bundler to handle removal of those? To reduce the size footprint perhaps? I read that some older browsers do not have console defined. So it’s advisable to remove them or handle its presence.

레코더 작성

먼저 알아야 할 것은 직접 사용할 수 없다는 것이다console.log.콘솔 표준이 없는 경우를 제외하고 living draft 사용console.log은 로그에 대한 사전 처리와 집합을 제한합니다. 즉, 기록된 모든 내용이 직접 들어가는 것입니다console.log.
로그가 브라우저의 devtools에 있으면 로그를 필터하고 포맷하는 능력은 브라우저가 제공하는 도구 모음에 국한되기 때문에 기록된 내용과 기록 시간을 제어하고 싶습니다.그 밖에 로그 기록은 확실히 성능을 대가로 한다.요컨대, 약속과 제어 로그를 만들 수 있도록 추상적인 것이 필요합니다.이러한 추상은 다음과 같이 간단합니다.

const MyLogger = (...args) => {
  console.log(...args);
};

응용 프로그램 어디에서나 MyLogger 함수를 전달하고 사용할 수 있습니다.

레코드의 컨텐트 강제 실행

이러한 추상적인 방식을 통해 기록된 내용/시간을 정확하게 제어할 수 있습니다. 예를 들어 모든 로그 메시지가 이름공간과 로그의 심각성을 설명해야 한다는 것을 강요할 수 있습니다.

type LogLevelType =
  'debug' |
  'error' |
  'info' |
  'log' |
  'trace' |
  'warn';

const MyLogger = (namespace: string, logLevel: LogLevelType, ...args) => {
  console[logLevel](namespace + ':', ...args);
};

우리의 응용 프로그램은 많은 모듈을 사용하여 구축된 것이다.나는 이름 공간을 사용하여 어떤 모듈이 로그를 생성하고 있는지 식별하고 다른 도메인 로그 (예를 들어'인증 인증','graphql','루트') 를 분리합니다.또한 로그 레벨은 devtools에서 로그 가시성을 전환할 수 있습니다.

JavaScript 함수를 사용하여 로그 필터링

기본적으로 모든 로그를 비활성화하고 특정 전역 함수가 있을 때만 인쇄할 수도 있습니다. 예를 들어.

type LogLevelType =
  'debug' |
  'error' |
  'info' |
  'log' |
  'trace' |
  'warn';

const Logger = (logLevel: LogLevelType, ...args) => {
  if (globalThis.myLoggerWriteLog) {
    globalThis.myLoggerWriteLog(logLevel, ...args);
  }
};

이 모드의 장점은 기본적으로 콘솔에 아무런 내용도 쓰지 않는다는 것이다. (성능 비용이 없고 불필요한 소음이 없다.) 그러나 실행할 때 로그를 필터하거나 인쇄하는 사용자 정의 논리를 주입할 수 있다. 즉, 최소화된 생산 사이트에 접근하여 devtools를 열고 로그 작성기에 사용자 정의를 주입하여 로그에 접근할 수 있다.

globalThis.myLoggerWriteLog = (logLevel, ...args) => {
  console[logLevel](...args);
};

총결산

이 세 가지 기능 (강제 로그 이름 공간, 로그 수준, 로그 기능 필터) 을 실현하면 좋은 시작을 할 수 있습니다.

로그 문장은 빔 크기에 측정 가능한 영향을 미치지 않습니다.

콘솔 대상이 아직 표준화되지 않은 것은 사실이다.그러나 현재 모든 JavaScript 환경은 콘솔을 구현합니다.로그위로하다로그는 모든 브라우저의 로그 기록에 충분합니다.

API 오류와 같은 중요한 애플리케이션 상태 변경 사항을 설명하는 모든 이벤트를 기록해야 합니다.

로그 양은 무관합니다*.

로그에는 이름 공간이 있어야 하며 지정한 심각도 수준 (예: 추적, 디버깅, 정보, 경고, 오류, 치명적) 이 있어야 합니다.

로그는 정렬되어야 합니다.

원목은 반드시 생산에서 사용할 수 있어야 한다.

나는 로그의 양은 상관없다고 언급했다.기록은 확실히 중요하지 않다. (아날로그 함수를 호출하는 데는 측정할 수 있는 원가가 없다.)그러나 인쇄와 저장의 수량은 매우 실제적인 성능 비용과 처리/저장 비용이 있다.이것은 프런트엔드와 백엔드 프로그램에 적용됩니다.이러한 추상적인 경우, 로그와 관련된 서브집합을 선택적으로 필터링, 버퍼링, 기록할 수 있습니다.
마지막으로 로그를 어떻게 실현하든지 간에 직접 사용하는 것보다 추상적인 것이 있을 것이다console.log.나의 건의는 레코더 인터페이스를 가능한 한 적은 사용 범위로 제한하는 것이다. 작은 인터페이스는 API의 일치된 사용을 의미하고 더욱 스마트한 전환을 지원한다. 예를 들어 나의 모든 레코더 (사용 Roarr 는 로그 수준, 단일 텍스트 메시지와 모든 지원 변수를 설명하는 단일 서열화 대상이 필요하다.