Cascade

A code-to-column change-impact knowledge graph for AI coding agents.

View the Project on GitHub alexsoft-hq/Cascade

English 한국어

웹 레인(프런트엔드) 설정

웹 레인은 왕복의 화면 쪽을 읽습니다. 엔진의 나머지는 HTTP 엔드포인트에서 시작해 아래로 내려가지만(endpoint → service → mapper → SQL → table → column), 이 레인은 엔드포인트 위쪽 코드를 읽습니다. 그 엔드포인트를 호출하는 프런트엔드와, 사용자가 어느 화면에 있는지를 정하는 라우트입니다.

먼저 이것부터 읽으십시오. 이 버전의 전체 모양입니다. 이 레인은 프런트엔드의 호출을 이 pack 이 서빙하는 엔드포인트에 붙이고, 그것을 등급이 매겨진 CALLS_HTTP 엣지로 만듭니다. 그리고 라우터 자신의 선언을 화면으로 바꾸어, 각 화면이 마운트하는 컴포넌트의 함수들과 잇습니다. 그래서 컬럼 영향 답이 컨트롤러를 지나 위로, 라우트를 부르는 api 함수와 그 함수를 부르는 뷰를 거쳐, 사용자가 보고 있는 화면까지 닿습니다. 브라우저 기록(--har)은 같은 엣지 위에 런타임 증거로 겹쳐 놓을 수 있으며, 보여 주기만 하고 걷지 않습니다.

이 레인이 쓰는 모든 엣지는 무엇에 근거했는지를 말하고, web 축은 프런트엔드에 대해 아무것도 추측하지 않았을 때만 shipped 입니다. 엔진이 매칭 개수를 세어 알아낸 접두사나 가정한 경로 별칭이 있으면 축은 degraded 가 되고, 무엇을 선언하면 되는지 이름으로 알려 줍니다.

무엇이 필요한가

Node, 그것뿐입니다. 파서가 동봉되어 있으므로 (adapters/web/vendor/babel-parser.cjs, @babel/parser 7.29.8, MIT) npm install 도, 락 파일도, 분석 시점의 네트워크도 없습니다. 저장소 NOTICE 가 그것을 밝히고, adapters/web/vendor/README.md 가 정확한 바이트와 고정된 sha256, 그리고 갱신 방법을 적어 둡니다. cascade doctor 에는 파서를 실제로 적재해서 statement 하나를 파싱해 보는 web lane parser (vendored) 줄이 있으므로, 잘린 체크아웃은 “프런트엔드 호출 0 개”가 아니라 이름 붙은 실패로 드러납니다.

무엇을 읽는가

각 소스 루트 아래를 재귀적으로 훑어 .js, .mjs, .cjs, .jsx, .ts, .tsx, 그리고 .vue 단일 파일 컴포넌트의 <script> 블록을 읽습니다. .vue 파일의 줄 번호는 템플릿까지 포함한 .vue 파일 안의 줄이므로, 사실이 가리키는 자리가 여러분이 커서를 놓을 자리입니다.

건너뛰는 것은 이렇습니다.

건너뛰는 것 어디서 왜
node_modules, .git, .cascade 깊이 무관 1차 소스인 적이 없습니다
__tests__, __mocks__ 깊이 무관 테스트는 어디에 있든 다른 프로그램입니다
dist, build, coverage, public 소스 루트나 그 패키지 디렉터리의 직계 자식일 때만 거기서는 출력물이고, 더 깊은 곳에서는 그냥 평범한 이름입니다
*.d.ts 전부 타입 선언에는 호출이 없습니다
*.test.*, *.spec.* 전부 __tests__ 와 같은 이유입니다
*.min.js 전부 소스가 아니라 번들입니다
2 MB 초과 파일 전부 skipped: "too-large" 로 기록하며 조용히 버리지 않습니다

세 번째 줄의 위치 규칙은 예의가 아니라 핵심입니다. “build 라는 이름은 무조건 건너뛴다”로 하면 src/views/tool/build/ 를 조용히 버립니다. 이 레인을 측정한 프런트엔드 중 하나에서 그것은 폼 빌더이고 진짜 화면 여섯 개였습니다. 빌드 디렉터리는 출력이 나가는 자리에 있을 때만 빌드 디렉터리입니다. 패키지의 꼭대기이거나 소스 루트의 꼭대기입니다. 그 밖의 자리에서 그 단어는 그냥 단어입니다.

알아 둘 만한 결과가 하나 있습니다. cascade init 의 발견 단계는 일괄 스킵 목록(src/core/discover.mjs)을 쓰는데, 같은 목록이 Java 레인을 Gradle 의 build/ 출력으로부터 지키기 때문입니다. 그래서 발견이 보고하는 webFiles 와 vueFiles 개수는, 그리고 cascade estimate 가 그것으로 출력하는 개수는, 레인이 실제로 읽는 것보다 몇 개 적을 수 있습니다. 측정한 프런트엔드 하나에서는 발견이 .vue 91 개를 세는 동안 레인은 97 개를 읽었습니다. 실행 후에 출력되는 lane 줄이 측정된 숫자이고, estimate 의 숫자는 하한입니다.

파서가 아예 읽지 못한 파일은 줄과 열과 메시지를 붙여 parse_error 로 기록하고 lane 줄에 출력합니다. 파싱에 실패한 파일은 호출도 라우트도 내놓지 않으며, 실행 중 다른 어떤 것도 그 사실을 말해 주지 않습니다.

소스 루트와는 별개로, 패키지 디렉터리(가장 가까운 package.json 이 있는 디렉터리)마다 한 번씩 다음을 읽습니다. dotenv 파일(.env, .env.local, .env.<mode>, .env.<mode>.local), 개발 서버 프록시 표를 위한 vue.config.js 와 vite.config.*, 그리고 경로 별칭을 위한 tsconfig.json 이나 jsconfig.json 또는 번들러 설정입니다. 이 셋이 함께 호출 속의 '/api' 가 실제로 어디에 닿는지를 정하고, 브리지는 셋을 모두 씁니다.

무엇을 기록하는가

사실 하나에 JSONL 레코드 하나이며, 전부 파일 국소적입니다. 워커는 파일을 넘나드는 해석을 전혀 하지 않습니다. 그것은 브리지의 일입니다.

레코드 무엇을 말하는가
file 언어, Vue 스크립트 블록, 파서가 복구한 오류 수
import / export 이 파일이 무엇을 받고 무엇을 주는가. 동적 import() 포함
function 이름 있는 함수들. 콜백은 자기 이름을 갖지 않고 가장 가까운 이름 있는 함수에 귀속됩니다
constant 문자열 멤버로 된 enum 이나 객체 리터럴, 그리고 export const X = '/x'
binding 초기화가 호출이나 new 또는 다른 이름인 최상위 const, 그리고 거기서 만들어진 baseURL
class 클래스와 그것이 선언하는 메서드와 필드. 클라이언트를 클래스로 쓰는 것은 함수로 쓰는 것만큼 흔합니다
assign 클래스 본문 어디서든 나오는 this.<field> = …. binding 과 같은 init 모양을 갖습니다. 클래스가 요청을 보낼 클라이언트를 넣어 두는 자리입니다
call import 나 지역 바인딩을 거치거나, URL 처럼 생긴 인자를 들고 있거나, fetch 또는 XMLHttpRequest.open 인 호출 지점
route 라우트 선언. 쓰인 그대로의 경로, 컴포넌트, 부모, 자식 수
config 위에서 말한 env 값, 프록시 규칙, 별칭

function 은 본문 최상위의 마지막 return 이 호출이나 new 일 때 무엇을 반환하는지도 함께 기록합니다. 팩토리(return new Client(opts))와 전달 메서드(return this.request(…))를 따라가는 방법이 그것입니다. 클래스 본문 안의 this 로 시작하는 피호출자는 자기가 어느 클래스에 속하는지 밝히므로 (binding: {kind: "this", class: "…"}), this.inner.request(cfg) 를 생성자가 대입한 필드까지 추적할 수 있습니다.

call 은 URL 인자를 한 파일이 허용하는 만큼 해석해 들고 있습니다. 리터럴, 템플릿('/things/' + id 와 `/things/${id}` 둘 다 /things/{*} 가 됩니다), 같은 파일에 선언된 상수의 멤버, 또는 한 번 따라간 지역 const 입니다. 해석하지 못한 것은 이유를 밝힙니다. parameter, expression, imported-constant 이며, import 된 상수는 브리지가 찾아갈 수 있도록 바인딩을 유지합니다.

플래그

cascade analyze [--web-src <dir>... | --no-web] [--openapi <file>... | --no-openapi]
                [--har <file>...]

플래그가 없으면 레인은 발견이 찾은 루트 위에서 돌지만, 프로파일이 web 프레임워크 팩을 선언한 경우에만 그렇습니다. cascade init 은 vue, react, @angular/core, svelte 에 의존하는 package.json 을 찾으면 그것을 선언하고, 같은 패키지가 라우터에 의존하면 vue-router 나 react-router 를 더합니다.

브리지가 하는 일과 그 정직한 등급

src/adapters/web_bridge.mjs 는 Java 브리지 다음에 돌고(라우트가 필요합니다), 각 호출 지점을 그것이 닿는다고 보일 수 있는 라우트마다 하나의 엣지로 바꿉니다.

증거 등급 왜
플랫폼 싱크(fetch, XMLHttpRequest.open)의 URL 이 이 pack 이 서빙하는 라우트와 맞음 SOUND_SET 요청을 브라우저가 직접 보내고 URL 인자가 계약상 URL 입니다. 이것이 HTTP 호출이라는 판단이 필요 없습니다
선언 팩이 이름을 아는 HTTP 클라이언트 인스턴스를 그 라이브러리의 동사 메서드로 호출 SOUND_SET 라이브러리가 요청을 보내고, URL 은 라이브러리가 읽는 인자입니다
각 이름이 무엇에 묶였는지를 따라가 위의 둘 중 하나까지 도달한 래퍼 SOUND_SET 모든 홉이 레인이 실제로 읽은 바인딩이고, 그 홉들이 엣지에 실립니다(evidence.sink.chain)
어떤 싱크로도 추적하지 못한 호출에 넘겨진 URL 모양의 인자 HEURISTIC 그 호출이 이 URL 을 보낼 수도, 그저 만들기만 할 수도 있습니다. 규칙 하나를 추측했습니다
위의 어느 경우든 접두사를 매칭 개수로 골랐거나, 경로 별칭을 가정했거나, 호출에 메서드가 아예 없는 경우 HEURISTIC 답의 한 부분이 추측이면 엣지 전체가 추측입니다
해석은 되었지만 이곳의 어떤 라우트도 답하지 않거나, 다른 호스트를 가리키는 URL UNRESOLVED 모든 모드의 하한 아래이므로 어떤 걷기도 따라가지 않습니다. 라우트는 outbound, source: "web" 으로 표시된 노드로 남습니다

URL 을 아예 해석하지 못한 호출은 엣지를 얻지 못하고, 워커가 준 이유 (parameter, expression, importedConstant)로 집계됩니다. 브리지에서 오는 이유가 셋 더 있습니다. noMatch(해석은 되었으나 이곳의 무엇도 서빙하지 않음), outsidePack(다른 호스트), allHoles 입니다. 조용히 사라지는 것은 없습니다.

래퍼란 무엇인가

프런트엔드가 axios 를 직접 부르는 일은 거의 없습니다. 자기 함수를 부르고, 그 함수가 또 다른 함수를 부르고, 결국 라이브러리에 닿습니다. 이 레인은 그 사슬을 이름이 아니라 모양으로 따라갑니다.

접두사, 그리고 그것을 선언하는 법

소스 속의 URL 은 거의 언제나 백엔드가 서빙하는 URL 이 아닙니다. 그 사이에 클라이언트의 baseURL 과 개발 서버 프록시가 있습니다. 브리지는 클라이언트 인스턴스마다 이 순서로 결정하고, 그 답을 모든 엣지에 evidence.prefix.from 으로 싣습니다.

  1. declared: 프로파일의 gatewayRoutes 가 이름을 댔습니다. 추측이 없으므로 엣지는 등급을 유지합니다.
  2. derived: 소스에서 base URL 을 읽었고(리터럴, .env 파일의 값, 절대 주소의 경로 부분), 그중 무엇이 서버에 닿는지를 개발 프록시 규칙이 설명해 줍니다. rewrite 가 있는 규칙은 떼어 내고, 없는 규칙은 유지합니다. base URL 없이 만든 클라이언트도 빈 접두사로 derived 입니다. 추측이 아니라 라이브러리가 그렇게 동작하기 때문입니다.
  3. auto: 소스의 무엇도 그것을 말해 주지 않습니다. base URL 이 어떤 .env 파일도 선언하지 않는 env 값을 가리키거나, 모드마다 값이 다른데 정리해 줄 프록시 규칙이 없거나, 상대 접두사에 프록시 규칙이 아예 없는 경우입니다. 그때는 모든 후보를 이 pack 이 서빙하는 라우트와 대조해 정확히 맞는 것이 가장 많은 후보가 이깁니다. 그것은 추측이므로 그 접두사를 지나는 모든 엣지가 HEURISTIC 이고, 후보별 개수가 엣지에 실립니다.
  4. none: 그마저도 아무것과 맞지 않아 URL 을 쓰인 그대로 씁니다.

추측을 멈추려면 .cascade/profile.json 에 매핑을 선언합니다.

{ "gatewayRoutes": { "/dev-api": "" } }

키는 프런트엔드가 쓰는 접두사, 값은 백엔드가 서빙하는 접두사입니다. "/dev-api": "" 는 “개발 서버가 이것을 떼어 낸다”는 뜻입니다. 키 "*" 는 프로젝트의 모든 호출에 적용됩니다. 이것을 선언하면 축이 degraded 에서 shipped 로, 엣지가 HEURISTIC 에서 SOUND_SET 으로 올라갑니다.

HTTP 클라이언트 팩

어떤 라이브러리가 요청을 보내고 그중 어떤 메서드가 동사인지는 코드가 아니라 선언입니다. adapters/web/packs/http-clients.json 입니다.

{ "module": "axios",
  "instanceFactories": ["create"],
  "verbs": { "get": "GET", "post": "POST", "put": "PUT", "delete": "DELETE" },
  "generic": ["request", "(call)"],
  "configUrlKey": "url", "configMethodKey": "method", "configBaseUrlKey": "baseURL",
  "defaultMethod": "GET" }

"(call)" 은 인스턴스 자체를 호출할 수 있다는 뜻입니다(service({ url })). 레인이 모르는 라이브러리를 가르치려면 그 파일에 행을 하나 추가하면 됩니다. 고칠 코드는 없고, 브리지의 어디에도 라이브러리 이름은 나오지 않습니다.

라우터 선언 팩

라우트 객체에는 자기만의 구문이 없습니다. 어떤 프레임워크가 정한 키 이름을 가진 평범한 객체일 뿐입니다. 그 이름들은 adapters/web/packs/*.json 에 관례마다 파일 하나로 들어 있고, 워커는 시작할 때 그 디렉터리의 모든 파일을 적재합니다. 오늘 둘이 들어 있습니다.

{
  "pack": "vue-router",
  "routeObject": {
    "pathKey": "path",
    "componentKeys": ["component", "components"],
    "childrenKey": "children",
    "nameKey": "name",
    "metaKey": "meta",
    "titleKey": "title",
    "redirectKey": "redirect",
    "hiddenKey": "hidden"
  },
  "registrars": ["createRouter", "VueRouter", "Router"],
  "routesKey": "routes"
}

객체 리터럴이 라우트가 되려면 문자열 pathKey 가 있고 componentKeys, childrenKey, redirectKey, indexKey 중 하나 이상이 참이어야 하며, 배열 리터럴 안이나 등록자 호출의 routesKey 안에 있거나 최상위 export 객체여야 합니다. 등록자를 하나도 부르지 않는 파일도 라우트를 내놓습니다. 평범한 배열을 export 하고 등록은 다른 데서 하는 프로젝트가 많기 때문입니다.

react-router.json 처럼 jsx 블록이 있으면 어느 JSX 엘리먼트가 라우트이고 어느 속성이 경로와 컴포넌트를 지정하는지 말하므로, <Routes><Route …> 트리를 같은 트리로 읽습니다.

두 팩이 같은 객체를 주장할 수 있을 때는, 그 객체가 들고 있는 구별되는 키를 가진 쪽이 이깁니다(meta/hidden/redirect/name 대 element/lazy/index). 그래도 갈리면 파일이 실제로 부르는 등록자가 결정합니다. 관례를 추가하려면 그 디렉터리에 JSON 파일을 하나 더 놓으면 됩니다. 고칠 코드는 없습니다.

화면

라우트 선언은 화면이 아닙니다. 화면은 사용자가 실제로 있는 경로이고, 그 경로는 읽는 것이 아니라 합성하는 것입니다. 라우터는 중첩되므로 {path: '/panel', children: [{path: 'rows'}]} 는 /panel/rows 라는 화면 하나입니다. 합성 규칙 전체는 이렇습니다.

노드 id 는 screen:<합성된 경로> 이며, flow screen= 과 browse kind=screen 이 그것으로 부릅니다.

RENDERS: 화면이 실제로 실행하는 것

screen --RENDERS--> symbol 은 화면과 그것이 실행할 수 있는 프런트엔드 함수를 잇습니다. 이름으로 추측하는 부분은 하나도 없습니다.

프런트엔드 자신의 호출

컴포넌트의 함수와 그것이 때리는 라우트 사이에는 보통 홉이 하나 더 있습니다. api 모듈입니다. symbol --CALLS--> symbol 이 그 홉이고, 등급은 그 이름을 어떻게 따라갔는지를 말합니다.

등급 언제
EXACT named 나 default 지정자를 쓴 정적 import 를 상대 경로나 선언된 별칭을 통해 이 레인이 읽은 함수까지 따라간 경우, 또는 한 파일 안에서 이름으로 부른 경우(getList(), this.getList())
SOUND_SET 같은 경우이되 이름이 export * 배럴이나 재export 사슬을 거쳐 왔고, 그래서 어느 파일에서 왔는지가 선택이었던 경우
SOUND_SET 여기서는 아예 호출되지 않았고, 다른 호출에 값으로 넘겨진 경우. 받은 쪽이 그것을 부를 수 있습니다
HEURISTIC 경로 위에 가정된 별칭이 있었던 경우

값으로 넘겨진 함수. 뷰에서 api 함수를 아예 부르지 않는 프런트엔드가 많습니다. 훅에 넘깁니다.

const { rows, reload } = usePagedList({ api: listRows })
useSubmit(saveRow, { immediate: false })

listRows 를 이름으로 부르는 호출 지점이 없으므로, 호출만 따라가는 규칙은 뷰에서 멈춥니다. 워커는 무엇이 넘겨졌는지를 기록합니다. 인자 위치의 식별자, 또는 객체 인자의 프로퍼티 값을 한 단계 깊이까지 어떤 키 아래에서든 기록하되, 그 파일이 그 식별자를 import 나 자기가 선언한 함수에 묶은 경우에만 기록합니다. 네임스페이스 import 의 멤버(api.list)는 뿌리와 경로를 유지합니다. 문자열은 참조가 아니고, 호출은 이미 호출이며, 인라인 화살표 함수의 본문은 이미 그것을 둘러싼 함수에 귀속되어 있습니다.

브리지는 그 이름을 피호출자와 똑같이 해석해 symbol --CALLS--> symbol 을 놓고, evidence.rule: "passed-as-value" 와 via(argument 또는 property), 키가 있었다면 key, 지정자와 출처를 함께 기록합니다. 등급은 SOUND_SET 이며 절대 EXACT 가 아닙니다. usePagedList 가 자기 api 를 실제로 부르는지 여기서 들여다본 적이 없기 때문입니다. 그것을 보려면 값을 다른 모듈의 본문 속까지 따라가야 합니다. 경로 위에 가정된 별칭이 있으면 HEURISTIC 으로 내려가고, 호출도 되고 넘겨지기도 한 쌍은 호출 쪽의 EXACT 를 유지합니다.

HTTP 에 닿는 함수만 노드를 얻습니다. 요청을 보내거나 이 엣지들을 통해 요청에 닿는 함수는 그래프에 들어가고, 포매터나 날짜 헬퍼는 집계만 되고 (laneStats.web.functions) 빠집니다. 그러지 않으면 아무 질문도 하지 않을 코드 때문에 pack 이 두 배가 되기 때문입니다. 컴포넌트 파일(.vue, .tsx, .jsx) 안의 함수는 component: true 를 달고 있어서, 도구가 화면 안의 함수와 api 함수를 구분할 수 있습니다.

라우터를 서버가 채워 줄 때

앱이 시작할 때 백엔드에서 메뉴를 받아 오는 관리자 제품이 많습니다. 그러면 이 레인이 볼 수 있는 화면은 그 앱이 아니고, 축은 소스 안의 것들이 제품 전체인 척하게 두는 대신 그렇다고 말합니다.

규칙은 호출입니다. 프런트엔드 자신의 호출 중 하나가 이 pack 이 서빙하는 라우트로 해석되었고 그 경로가 /getRouters, /menu, /menus, /routes, /nav 로 끝나는 경우입니다. 그 밖에는 아무것도 요구하지 않습니다. 집계는 serverDriven: {detected, detectedBy: "menu-call", routes, ceiling, menuEndpoints} 로 기록되므로, 독자가 규칙을 그대로 받아들이는 대신 확인할 수 있습니다.

라우트 개수는 결정하지 않고 문장만 고릅니다. 30 개 상한 아래에서는 대부분의 화면이 앱이 돌 때 도착한다고 말하고, 그 위에서는 선언된 N 개를 넘는 화면이 앱이 돌 때 도착한다고 말합니다.

이것으로도 잡히지 않는 경우는 측정해 두고 그대로 두었습니다. 메뉴를 메뉴처럼 생기지 않은 엔드포인트에 실어 나르는 제품입니다. 측정한 가장 큰 프런트엔드는 라우트 173 개를 선언하는데 그중 87 개가 프레임워크 자체의 데모 페이지이고, 모든 업무 화면은 메뉴가 아니라 권한을 따라 이름 지은 라우트에서 런타임에 가져 옵니다. 위의 어떤 접미사도 그것과 맞지 않으므로 그 프로젝트의 screen 축은 shipped 로 읽히고, “화면 166 개 중 19 개가 테이블에 닿는다”는 설명이 아니라 부족으로 읽힙니다. 그 프로젝트의 철자를 여기 넣는 것은 그 프로젝트에서만 통하는 규칙이 되므로, 철자 표는 일반적인 채로 두고 대신 이렇게 적어 둡니다.

발동하면 screen 축은 그 문장과 근거 숫자를 달고 degraded 가 되고, overview 에 screens-from-server 갭이 실립니다. 이것은 무엇이 빠졌는지에 대한 것이지 만들지 말지에 대한 것이 아닙니다. screenAxis.enabled: true 인 프로파일은 여전히 선언된 화면을 전부 만듭니다. 부분적인 화면 축보다 아예 없는 편이 낫다면 screenAxis.enabled: false 로 두십시오.

프로파일 키

{
  "screenAxis": {
    "enabled": true,
    "nameSource": "route-meta",
    "pathRule": "last-segment",
    "codeRegex": "([A-Z]{2}\\d{4})"
  },
  "moduleAttribution": { "codeLength": 2 }
}

축이 shipped 가 되는 조건

shipped 에는 셋이 다 필요합니다. 게이트가 켜져 있고, 최소 하나의 화면이 RENDERS 엣지를 갖고, 읽는 과정에서 추측한 것이 하나도 없어야 합니다. 앱이 서버에서 메뉴를 받아 올 때, 선언된 라우트의 5분의 1 이상이 이 레인이 해석하지 못한 컴포넌트를 지목할 때, nameSource 가 제공하지 않는 것을 요구할 때, 화면은 만들어졌는데 그중 어느 것도 함수에 닿지 않을 때 degraded 입니다. 게이트가 꺼져 있거나 라우트를 하나도 읽지 못한 경우에만 not-shipped 입니다. 꺼져 있을 때는 축 이유가 위의 세 규칙 중 무엇이 껐는지를 밝힙니다.

기록(HAR)

HAR 파일은 브라우저가 본 것입니다. 어느 페이지가 열려 있었는지와 그것이 보낸 모든 요청입니다. cascade analyze --har <file>(반복 가능)이 하나를 읽고, 프로파일의 runtimeEvidence.har 가 플래그 없는 실행을 위해 이름을 댑니다. 발견은 하지 않습니다. 기록은 일부러 만드는 것이고, 트리에 우연히 있다는 이유로 주워 오면 무관한 캡처가 이 pack 이 무엇을 관측했다고 주장할지를 정하게 되기 때문입니다.

만드는 법

Chrome 에서 앱을 열고 F12 를 누른 뒤 Network 로 가서 Preserve log 를 켜고, 보고 싶은 화면들을 지나간 다음, 요청 목록에서 오른쪽 버튼을 눌러 Save all as HAR with content 를 고릅니다(내용 자체는 여기서 읽지 않고 URL 과 각 요청이 속한 페이지만 읽습니다). Firefox 와 Edge 도 같은 형식을 씁니다.

무엇이 매칭되는가

RUNTIME_ONLY 의 뜻

매칭된 (화면, 라우트) 쌍마다 screen --CALLS_HTTP--> endpoint 엣지 하나가 생기고 등급은 RUNTIME_ONLY, 증거는 {rule: 'har', file, count, firstSeen, lastSeen, methods} 입니다. 그 등급은 모든 질의 모드의 하한 아래이므로,

observed: true 는 화면 노드와 엔드포인트 노드, 그리고 그것들을 이름으로 부르는 flow, browse kind=screen, screen_impact 의 행에 붙습니다. 집계는 meta.laneStats.har 에 있습니다.

이 버전이 하지 않는 것