DEV Community: [CS] Alishopping

I spent 6 months building a Chrome extension with Vue 3 and Shadow DOM -- here are the hard parts

[CS] Alishopping — Fri, 03 Apr 2026 07:00:00 +0000

Your Chrome extension looks perfect in development. The fonts are crisp, the layout is clean, Tailwind utilities work exactly as expected.

Then you deploy it to a real e-commerce site. Every style breaks. The host page has an aggressive CSS reset that overrides your carefully crafted UI. Your text-sm renders at the wrong size. Your flex containers collapse. You add !important to a few rules, then a few dozen, and eventually you realize you are fighting a war you cannot win.

I spent six months building a Chrome extension that injects analysis panels into e-commerce pages. It runs on multiple platforms across thousands of different CSS environments, each one capable of destroying my UI. Here is how I solved it.

The approaches that failed

Before landing on the right solution, I tried three common approaches:

Approach	What it does	Why it fails for content scripts
Scoped CSS	Prevents your styles from leaking out	Does not stop host page styles from leaking in
CSS-in-JS	Generates unique class names at runtime	Runtime overhead, and the host page cascade still applies
iframe	True CSS isolation	Communication with the host page becomes painful. No shared state. Heavy.

None of these give you bidirectional CSS isolation without significant tradeoffs.

Shadow DOM + adoptedStyleSheets

Shadow DOM creates a hard boundary. The host page's CSS cannot cross into the shadow root. Your CSS cannot cross out. And with adoptedStyleSheets, you can load your stylesheets synchronously -- no flash of unstyled content, no <style> tag injection.

The core helper is simple:

// Generic example: creating a CSSStyleSheet for Shadow DOM
function createSheet(css: string): CSSStyleSheet {
  const sheet = new CSSStyleSheet();
  sheet.replaceSync(css);
  return sheet;
}

In a Vite build, you can import CSS files with the ?inline suffix, which gives you the CSS as a raw string instead of injecting it into the document head. This pairs perfectly with adoptedStyleSheets -- you get build-time CSS processing (PostCSS, Tailwind, Sass) and runtime Shadow DOM isolation.

How the mount pattern works

The general approach for injecting a framework app inside Shadow DOM follows this pattern:

// Generic example: mounting a framework app inside Shadow DOM
function injectExtensionUI() {
  // 1. Create a host element in the light DOM
  const host = document.createElement('div');
  host.style.cssText =
    'position:fixed;top:0;right:0;z-index:2147483647;' +
    'width:0;height:0;overflow:visible;pointer-events:none;';
  document.body.appendChild(host);

  // 2. Attach a shadow root
  const shadow = host.attachShadow({ mode: 'open' });

  // 3. Load stylesheets in the correct cascade order
  shadow.adoptedStyleSheets = [
    createSheet(resetCSS),
    createSheet(utilityCSS),
    createSheet(componentCSS),
    createSheet(themeCSS),
  ];

  // 4. Create a mount point and hand it to your framework
  const mountEl = document.createElement('div');
  mountEl.style.pointerEvents = 'auto';
  shadow.appendChild(mountEl);

  // 5. Mount your framework (Vue, React, Svelte, etc.)
  const app = createApp(RootComponent);
  app.mount(mountEl);
}

This is framework-agnostic. The Shadow DOM setup is identical whether you use Vue, React, Svelte, or vanilla JS. The framework-specific part is only the last few lines.

The details that took debugging to get right

z-index: 2147483647. That is the maximum 32-bit signed integer. It ensures the extension panel sits above every element on the host page, including modals and fixed headers.

pointer-events: none on the host, auto on the mount point. The host element covers the viewport corner, but clicks pass straight through it to the page below. Only the actual extension UI captures mouse events. Without this, users cannot click on page elements near the extension panel.

width:0; height:0; overflow:visible. The host element takes zero layout space. The extension UI overflows visually but does not push page content around.

Guard against double-injection. Content scripts can reload when Chrome updates or when navigating within a SPA. Without a guard check (e.g., checking for an existing host element by ID), you get duplicate panels stacking on top of each other.

CSS ordering matters

The order of stylesheets in adoptedStyleSheets is not arbitrary. Later sheets have higher specificity, following the standard CSS cascade:

Reset CSS -- Normalizes the shadow root (box-sizing, font defaults)
Utility CSS (e.g., Tailwind) -- Utility classes as the base layer
Component CSS -- Panel layout, component-specific styles
Theme CSS -- Colors, dark mode variables, theming overrides

If you put the theme before the component styles, theme variables get overridden by more specific selectors. If you put utilities after components, utility classes override your custom layout. The order is: normalize, then utilities, then components, then theme.

Supporting multiple platforms with the same pattern

We use this identical architecture across different e-commerce platforms, with different positioning for each:

One platform gets a floating side panel on the right
Another gets a bottom toolbar with a glass-blur effect

Each platform gets its own component CSS and theme CSS, but the shadow root setup, the createSheet() helper, and the framework mounting sequence are identical. Adding a new platform means writing a short mount script and two CSS files -- the architecture scales cleanly.

Note that adoptedStyleSheets and attachShadow are supported in all Chromium browsers. Since we are building a Chrome extension, cross-browser compatibility is not a concern here.

Beyond CSS: other hard parts

CSS isolation was the biggest challenge, but not the only one.

Cross-origin requests in MV3. Content scripts cannot make cross-origin fetch requests. We had to build a message-passing layer where the content script asks the background service worker to make requests on its behalf. The service worker has the necessary permissions and returns the response through the messaging channel. I go deeper into this in a later article in this series.

Client-side scoring. The extension runs multiple scoring algorithms entirely in the browser. Each one is a pure TypeScript function -- no network calls, no ML model, no backend. A product analysis completes in milliseconds. The design of these scoring engines is the topic of the next article.

Trusted Types compatibility. Some e-commerce sites enforce strict Content Security Policy with Trusted Types. Injecting DOM elements through Shadow DOM requires creating a custom Trusted Types policy to avoid CSP violations. This was a particularly frustrating issue to debug because the errors only appear on specific sites.

What I would do differently

Looking back after six months:

Start with Shadow DOM from day one. I wasted three months trying scoped CSS and increasingly desperate !important chains before switching. The migration was painful because styles were already deeply coupled to the assumption that they lived in the main document.
Use strict TypeScript from the start. We migrated gradually (non-strict mode, allowing JS files) which means we still have legacy files mixed in. Starting strict would have caught dozens of bugs earlier.
Build a typed messaging layer from the start. Our background script started with raw string-based message types. A properly typed request/response system would have prevented several runtime errors where the content script sent a message the background script did not expect.

If you are building a Chrome extension that injects UI into third-party pages, Shadow DOM with adoptedStyleSheets is the approach I would recommend without hesitation. It is the only solution that gives you true bidirectional CSS isolation, zero runtime overhead, and full framework support.

What is your approach to CSS isolation in content scripts? I would be curious to hear what has worked (or not worked) for you.

Try it free:
https://chromewebstore.google.com/detail/alishopping-%E2%80%94-aliexpress/agiaehdeifaihlndhnhcmopjpjijnfap?utm_source=devto

Building a scoring engine with pure TypeScript functions (no ML, no backend)

[CS] Alishopping — Thu, 02 Apr 2026 01:34:02 +0000

We needed to score e-commerce products across multiple dimensions: quality, profitability, market conditions, and risk.

The constraints:

Scores must update in real time
Must run entirely in the browser (Chrome extension)
Must be explainable (not a black box)

We almost built an ML pipeline — training data, model serving, APIs, everything.

Then we asked a simple question:

Do we actually need machine learning for this?

The answer was no.

We ended up building several scoring engines in pure TypeScript.
Each one is a single function, under 100 lines, zero dependencies, and runs in under a millisecond.

What "pure function" means here

Each scoring engine follows 3 rules:

No I/O → no network, no DB, no files
Deterministic → same input = same output
No side effects → no global state, no mutations

This makes them:

Easy to test
Easy to reason about
Portable (browser, Node.js, anywhere)

Core pattern: weighted scoring

interface ScoringInput {
  qualityScore: number | null;
  profitScore: number | null;
  marketScore: number | null;
  riskScore: number | null;
}

type Verdict = 'strong_buy' | 'buy' | 'hold' | 'pass';

function computeScore(input: ScoringInput) {
  const quality = input.qualityScore ?? 50;
  const profit = input.profitScore ?? 50;
  const market = input.marketScore ?? 50;
  const risk = input.riskScore ?? 50;

  const overall = Math.round(
    quality * 0.3 +
    profit * 0.3 +
    market * 0.2 +
    risk * 0.2
  );

  let verdict: Verdict;
  if (overall >= 80) verdict = 'strong_buy';
  else if (overall >= 60) verdict = 'buy';
  else if (overall >= 40) verdict = 'hold';
  else verdict = 'pass';

  return { overall, verdict };
}

Handling missing data (critical)

All inputs are nullable.

We default to 50 (neutral).

Why not:

Skip missing values → breaks comparability
Default 0 → unfairly penalizes
Default 100 → artificially inflates

Neutral = safest assumption.

Normalization + clamp

All scores must be 0–100.

function clamp(value: number, min: number, max: number) {
  return Math.max(min, Math.min(max, value));
}

const profitScore = clamp(marginPercent * 2, 0, 100);
const marketScore = clamp(100 - saturationPercent, 0, 100);
const riskScore = clamp(100 - rawRiskScore, 0, 100);

Without clamp:

values can exceed bounds
negative values break logic
NaN propagates silently

Choosing weights

Not all dimensions are equal.

We weighted:

Quality + Profit → higher (controllable)
Market + Risk → lower (external factors)

We considered user-configurable weights but dropped it:
→ too complex for non-technical users

Threshold calibration

Initial thresholds (75 / 50 / 25) were too optimistic.

We:

Scored hundreds of products
Compared with human judgment
Iterated

Lesson:
Never guess thresholds — calibrate them.

Composition > monolith

We built multiple small engines:

Product score
Market score
Platform score

Then combine:

function computeFinalVerdict(
  productScore: number | null,
  marketScore: number | null,
  platformScore: number | null
) {
  const product = productScore ?? 50;
  const market = marketScore ?? 50;
  const platform = platformScore ?? 50;

  const score = Math.round(
    market * 0.4 + product * 0.35 + platform * 0.25
  );

  const confidence = Math.round(
    Math.min(product, market, platform) * 0.8 + 20
  );

  const reasons: string[] = [];

  if (market >= 70) reasons.push('Favorable market conditions');
  if (market < 40) reasons.push('Challenging market');
  if (product >= 70) reasons.push('Strong product');
  if (product < 40) reasons.push('Weak product');

  return { score, confidence, reasons };
}

Key ideas:

Confidence = weakest dimension
Reasons = explainability

Example

Input:

Quality: 75
Profit: 84
Market: 65
Risk: 80

Result:

Score: 77
Verdict: buy

If profit increases → score crosses 80 → strong_buy

This kind of reasoning is trivial with pure functions, impossible with black-box ML.

When you SHOULD use ML

Use ML if:

You analyze images or text
You need pattern discovery
You have high-dimensional data (50+ features)

Otherwise:
→ pure functions are simpler, faster, more transparent

Key takeaways

Start with pure functions
Default missing data to neutral
Always clamp values
Weight by controllability
Compose small engines
Calibrate with real data

No training data. No APIs. No latency.
Runs in-browser in under 1ms.

Not for every problem — but for structured scoring, it’s hard to beat.

Curious:
Have you used similar scoring patterns?
Or did you go with ML instead?

Try it free:
https://chromewebstore.google.com/detail/alishopping-%E2%80%94-aliexpress/agiaehdeifaihlndhnhcmopjpjijnfap?utm_source=devto