DEV Community: Zahra Mirkazemi

How to Pass Data into a Static JavaScript File Using data-* Attributes

Zahra Mirkazemi — Sat, 24 May 2025 08:32:11 +0000

As a front-end developer, one of the common challenges you'll encounter when working with embeddable scripts or static widgets is how to inject dynamic configuration into a static JavaScript file.

Since static files can't fetch data from a backend or receive props like React components, they must rely on what's available in the DOM.

One elegant and widely supported solution is to use HTML data-* attributes.

In this article, I'll walk through how this pattern works, when to use it, and why it's a reliable choice for flexible, embeddable scripts.

🎯 The Problem

Let's say you're distributing a static script — for example, a survey button, a help widget, or a third-party plugin. You want other developers (or non-dev users) to embed your script and be able to customize things like:

Color scheme
Position (left/right/bottom)
Icon

But your JavaScript file is hosted on a CDN and cannot be dynamically modified.

So, how do you make it configurable?

✅ The data-* Attribute Pattern

HTML data-* attributes let you attach custom metadata to elements. These values are accessible via JavaScript using the .dataset API.

Here's how it works:

<div
  id="my-widget"
  data-theme="dark"
  data-position="right"
  data-lang="en"
></div>
<script src="https://cdn.example.com/widget.js"></script>

Inside widget.js:

const el = document.getElementById("my-widget");
const config = {
  theme: el.dataset.theme || "light",
  position: el.dataset.position || "left",
  lang: el.dataset.lang || "en"
};

// Use the config to customize your widget
initializeWidget(config);

This pattern is clean, readable, and doesn't require any global variables or external communication.

🧰 Why Use This Pattern?

✅ Pros

Fully decoupled: Your static JS doesn't rely on server-side rendering or build-time variables.
Declarative: Easy for developers and non-developers to understand.
Multiple instances: You can use this pattern for multiple widgets on the same page, each with its own configuration.
Safe & flexible: Works across browsers, respects caching, and doesn't interfere with global scope.

❌ Cons

Data is limited to string values — you'll need to manually parse JSON or booleans if needed.
Relies on correct HTML structure (e.g., an element with the right id or class).
If not documented properly, consumers may miss available options.

✍️ Best Practices

Use clear naming: Stick to data- attributes like data-color, data-user-id, etc.
Set safe defaults: In your JS, always provide fallback values.
Validate input values (e.g., allowed themes or positions).
Avoid sensitive data: Don't pass secrets, tokens, or anything private via data-*.

🤔 But Wait… This Isn't the Only Way

While data-* attributes are great, they're definitely not the only option. Depending on your use case, you might consider one of these too:

1. Global Variables

<script>
  window.myWidgetConfig = {
    theme: 'dark',
    position: 'right',
    lang: 'fa'
  }
</script>
<script src="https://cdn.example.com/widget.js"></script>

This works well for more structured data, but it pollutes the global namespace — which can be risky in large apps or when multiple scripts are involved.

2. Query Parameters in Script URL

<script src="https://cdn.example.com/widget.js?theme=dark&lang=fa"></script>

You can then parse these inside the script using document.currentScript.src. This is quick and easy for small config values, but can get messy fast if your configuration grows.

3. JSON Inside `<script type="application/json">`

Another trick is embedding configuration data as JSON in a special script tag:

<script type="application/json" id="my-widget-config">
  {
    "theme": "dark",
    "lang": "fa"
  }
</script>

Then in your JS:

const raw = document.getElementById("my-widget-config").textContent;
const config = JSON.parse(raw);

A bit more setup, but great for complex configs.

🏁 Conclusion

If you're building embeddable JavaScript for third-party use, data-* attributes offer a simple, scalable, and standards-compliant way to receive configuration from the host HTML.

This pattern strikes the right balance between flexibility and safety — especially in environments where your script is embedded across many contexts and domains.

Next time you're working on a static JS file that needs to behave dynamically, consider this technique. It's declarative, reliable, and works in every browser that matters.

💬 Got thoughts, questions, or your own favorite tricks?

Let's continue the conversation in the comments.

Have you implemented something like this before? Which method did you go with, and why?
Have you tried more advanced techniques like Web Components or JSON-LD-based configurations?

I'd love to hear your take. Let's share ideas — there's always something new to learn 🌱

🙌 If you found this useful, feel free to share it with your team or give it a clap!

Query Strings vs. Hash Fragments: What’s the Real Difference?

Zahra Mirkazemi — Fri, 23 May 2025 17:48:12 +0000

Understanding URL Query Strings vs Hash Fragments

The other day, I stumbled upon something interesting. I was checking out a survey and noticed two URLs that looked like they pointed to the same place:

https://example.com/page?panel_view=true

and

https://example.com/page#/?panel_view=true

At a glance, you might think: "Same link, right?" Well… not exactly.

Let's dig into what's going on here — and why this small detail might actually matter, especially if you're working with modern web apps.

The Curious "#"

In the second URL, you'll notice a hash (#) followed by a slash:

#/?panel_view=true

That little hashtag, also called a hash fragment, plays a special role in web development.

🔍 TL;DR:

Everything before the # = sent to the server
Everything after the # = stays in the browser

In other words: the server doesn't care about anything after the #. It never even sees it. But if your app is a single-page application (SPA) — built with something like React, Vue, or Angular — it might care a lot.

So, Why Use the Hash at All?

Back in the day, # was mostly used for scrolling to sections within a page (like #about-us).

Now, in modern SPAs, it's often used for routing. When you see something like #/dashboard or #/login, that's your front-end framework deciding what content to show — without refreshing the page.

Do They Work the Same?

They might! Or they might not.

If the app is a traditional server-rendered page, it likely uses query strings (?) to load different content.

If it's an SPA, the app might rely entirely on the hash (#/) to trigger internal views.

Using the wrong one could lead to weird issues — like skipping required steps, not loading the right view, or even breaking analytics.

What About Caching?

Great question. Here's where things get even more interesting:

🧠 Browsers and CDNs treat query strings and hash fragments very differently when it comes to caching.

Query strings (?panel_view=true) affect the full URL — including server-side caching and CDN behavior. So: Different query strings = different cached versions. This can be good (for dynamic content), but sometimes bad (if it busts the cache unnecessarily).
Hash fragments (#), on the other hand: Do not affect caching. The browser sees https://example.com/page#about and https://example.com/page#contact as the same resource — it just scrolls to a different part or changes state after the page loads.

💡 If you want to bust cache or serve different content from the server, use query strings. If you only need to affect front-end behavior, use hash fragments.

Catching These in Next.js

If you're using Next.js, here's how you grab each type:

✅ Query Strings

Next.js handles query strings natively using the useRouter hook:

import { useRouter } from 'next/router';

const Page = () => {
  const router = useRouter();
  const { panel_view } = router.query;

  return <p>panel_view is {panel_view}</p>;
};

📦 Hash Fragments

Hash values aren't part of Next.js routing — they live only in the browser. You'll need to use window.location.hash:

import { useEffect, useState } from 'react';

const Page = () => {
  const [hash, setHash] = useState('');

  useEffect(() => {
    setHash(window.location.hash);
  }, []);

  return <p>Current hash is: {hash}</p>;
};

Just remember: since this uses window, it must run client-side only (e.g., inside useEffect).

A Tiny Detail, A Bigger Lesson

This small difference is a great reminder that URLs are more than just links — they carry instructions. And depending on how your app is built, the format of those instructions can change what users see (or don't see).

Next time you copy-paste a link, give it a second look. That tiny # could be doing a lot more than you think. 😉

Ever been bitten by a query string or hash behavior in a project? Drop a comment — I'd love to hear your story!