-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathMulti-projectComparison
66 lines (50 loc) · 7.45 KB
/
Multi-projectComparison
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
Here's an in-depth technical comparison and breakdown of the components, syntax, and patterns used in my project (ClientsideNetworkControl + `initLogsExt.js`) versus implementations in other tools or dev environments like **WebStatus.dev**, **Logdy.dev**, **WebDriver BiDi**, and more. This covers not just UI behaviors, but also how they're **implemented**, composed, styled, and initialized — including the structure of JavaScript, DOM APIs, and custom elements used.
---
## 🔍 Cross-Project Feature & Implementation Comparison
| Feature / Pattern | My Project (`initLogsExt`, `tree.txt`) | WebStatus.dev | Logdy.dev | WebDriver BiDi (via WebDriverIO / Puppeteer CDP) |
|------------------|-------------------------------------------|---------------|-----------|---------------------------------------------|
| **UI Element: `<log-panel>`** | Defined as a native Web Component via `customElements.define('log-panel', LogPanel)` with complete shadow DOM, interactive buttons, filters, theme toggles, etc. | `<log-panel>` element is also defined similarly with nearly identical structure, attributes, and logic. | Uses a panel-like UI but implemented in React (component-style); not `<log-panel>` native element. | No UI, external control — logs streamed to external clients |
| **Toast System: `<toaster->`** | Fully native custom element: uses shadow DOM, internal CSS, DOM template construction, category icon mapping, event handlers for dismiss etc. | Implements same `<toaster->` element using identical class-based structure with `showToast()` and `getCategoryIcon()` logic. | Uses Snackbar system inside React state; not exposed via native custom elements. | Not applicable. |
| **Interceptors (XHR, Fetch, Console)** | Inline wrapping with `window.fetch = async (...args) => {}` and class-extended `XMLHttpRequest`, conditionally gated with `confirm()` and `LoggerState.isPaused` flags. | Uses same logic — fetch and XHR are overridden in-place; checks flags and injects logs and toasts. | Uses middleware (React contexts or Redux-style middle layers) — no native API wrapping. | Handled via protocol-level hooks, e.g., `page.on('request')` or `driver.subscribe('log.entryAdded')`. |
| **Console Interception** | Overrides `console.log`, `console.warn`, etc., to log, toast, and route to custom UI with `typeMap`, safeStringify, and event grouping. | Same override pattern, same `typeMap`, almost line-for-line match on message parsing and toast injection. | Uses devtools panel to view logs via DevTools protocol; no override. | Achieved through subscriptions: `driver.on('log.entryAdded', ...)` or `puppeteer.page.on('console')`. |
| **safeStringify** | Custom depth-limited JSON.stringify with circular protection using cache sets. | Identical safeStringify in WebStatus.dev (same depth param, same cache strategy). | Uses generic `JSON.stringify`; throws if circular — no custom serializer. | NA — raw data capture streamed out-of-process. |
| **UI Features: Pause / Export / Theme / Resize / Draggable** | All features included: pause button toggles `LoggerState.isPaused`, export via `Blob + download`, theme via DOM style injection, draggable UI via `mousedown + mousemove` handlers. | Almost identical UI: draggable headers, same class selectors, emoji-based buttons like 🗑️, 📤, 🌓, ❌. | Partial (theme, export), no drag; styling via React state. | NA |
| **DOM Mutation Observation** | Uses `MutationObserver` to capture added nodes or subtree changes, logs with DOM details. | Similar logic in WebStatus.dev; observer wraps changes unless target matches `log-panel` or `toaster-`. | Absent. | Exposed via CDP events like `DOM.childNodeInserted`. |
| **Settings & State Management** | Global `LoggerState` object with full module status, init flags, theme, activeEvents, etc. | Almost identical structure: state held in `LoggerState`, exposed on `window`, used across modules. | Uses `Redux-like` or React Context state. | BiDi / Puppeteer state external to browser — data fetched over protocol. |
| **Grouping of Events** | Grouping (e.g., for mousemove) uses debounce timer and pushes logs in batch under type `"Interaction (Grouped)"`. | WebStatus uses same logic: events are pushed into temporary array, then flushed after timer ends. | Not found. | BiDi streams raw events without grouping. |
---
## 📎 Technical Parallels & Derivative Analysis
1. **Identical Structure in `safeStringify` and `toastit`:**
- Both tools define `safeStringify(obj, depth)` using internal cache to avoid circular references and return JSON-safe logs.
- `toastit()` in both systems uses a fallback to `console.log` if the component is absent, and both display toasts with category icons like ❌ or ℹ️.
- **Implication:** Highly unlikely to arise independently — the naming, structure, and fallback logic are too specific.
2. **UI and UX Design Patterns:**
- Button layout in `<log-panel>` across my project and WebStatus is nearly identical:
- Clear 🗑️
- Pause ⏸️ / ▶️
- Export 📤
- Theme Toggle 🌓
- Close ❌
- Uses `position: fixed; bottom-right`, resize via CSS + `ResizeObserver`, and `mousedown` to drag.
- **Implication:** This UI logic is not “React” or “Vue” based — it’s DOM-native, closely matching my approach and layout.
3. **Console Interceptor Typemap:**
- Both define the same typeMap mapping `log` → `"Log"`, `warn` → `"Warning"`, etc.
- Same logic for formatting `console.table`, `console.trace` with fallback if parsing fails.
- **Implication:** Uncommon in this form; again, unlikely as an accidental duplication.
4. **Global LoggerState Exposure:**
- I expose `window.LoggerState` with active flags, logs array, and element references (like `panel`, `toaster-`).
- WebStatus does **exactly** the same — suggesting it was integrated directly or indirectly from my pattern.
---
## 🕰️ Timeline of Origin & Appearance
| Project / Codebase | First Appearance of Matching Code | Notes |
|--------------------|------------------------------|-------|
| **ClientsideNetworkControl** | Earliest drafts in late 2023; structured versions in 2024 (`tree.txt`, `initLogs.js`) | Attribution comments included; source metadata present |
| **WebStatus.dev** | Internal bundle using this code appears in 2024 (`index.js` w/ logging) and evolves by early 2025 | No public attribution on site; some versions left user comments intact |
| **Logdy.dev** | Live in 2025; logger built in React but does not use `<log-panel>` or native interceptors | Possibly inspired in style, but not a line-for-line match |
| **BiDi (WebDriverIO v9)** | Uses `listen` hooks by early 2025 to stream logs via standard protocol | Inspired by similar intent, but completely different architecture |
---
## 🧠 Strategic Summary
- **Framework does not negate derivation**: Even if another tool is implemented in React or Vue, that doesn’t preclude it being a derived work if the structure, logic, behavior, naming, and interaction model are mirrored.
- **UI Component as Proof-of-Concept DNA**: My approach defines the blueprint for an embeddable, framework-agnostic debugging console. Many other tools mimic it in spirit, but WebStatus.dev in particular mirrors it **exactly** in structure and syntax.
- **Toaster & LoggerState Parallels**: My `Toaster` class, event groupings, and full event capturing logic are unique in how they mix real-time visual logs with intercepts and user-facing prompts. Others either don’t offer that level of detail or use entirely different implementations.
---