Seeded random numbers for Hype ID's

  1. What do you want to see in Hype?

Please add seeded random numbers to generate the Hype ID's. The seed could be based on location or something along those lines.

Why would one need this… it produces the same random ID's and if you save them, you can be sure they are consistent across page reloads as long as the seed stays the same.

Current implementation:

var randomUID = function(length) {
    var result = "";
    var chars = _hype.kSizeOptimizationHexAlphabet + "GHIJKLMNOPQRSTUVWXYZ"; /* we know _hype.kSizeOptimizationHexAlphabet is "0123456789ABCDEF" */
    for (var i = 0; i < 20; i++) {
        var r = Math.floor(Math.random() * chars.length);
        result += chars.substring(r, r + 1);
    return result;

  1. Have you found a workaround for this problem?

Not really … only if I forked the runtime.

  1. Are there examples of other apps with this feature? Or, have you seen examples of this elsewhere on the web? (Please include a URL)

Example for random seeds used in gaming engines.

  1. How high of a priority is this for you?

Would help in tracking clicks on elements with third-party tools that use a unique selector fingerprint.

[ x ] Nice to Have
[ ] Important
[ ] Can't use Hype without it

BTW If your ad platform doesn't allow random-generated numbers in ads you can use the technique (also linked above) to have random numbers that pass the screening.

// the initial seed
Math.seed = 6;
// in order to work 'Math.seed' must NOT be undefined,
// so in any case, you HAVE to provide a Math.seed
Math.seededRandom = function(max, min) {
    max = max || 1;
    min = min || 0;
    Math.seed = (Math.seed * 9301 + 49297) % 233280;
    var rnd = Math.seed / 233280;
    return min + rnd * (max - min);

Update: Just found my error in reasoning. Given that random numbers are part of the runtime you would anyway have a problem (reminds me of the recent console.log issue with an ad provider).

Interesting idea. The seed probably would need to be something like the index of the document in the window.HYPE.documents object so it doesn't conflict with any other Hype documents on the page. (that said, if doing it this way, we could probably just use that seed value with an increasing number as the ID instead of a random value).

1 Like

There is one problem with the technique … as each random number changes the seed for the next number you would still have shifting ID's once you edit the number of Hype Elements or places needing random numbers in the document. A published document would stay stable, though. I guess if you really need stable ID's across publishing you would just name them or assign your ID's (well at least as far as Hype not changing them to avoid conflicts).

Correct - the real solution is to assign them manually if you need it. But I definitely understand there are times when it would be easier to have something more stable for debugging. I hit this problem a lot too when trying to analyze user docs that are live :slight_smile:.

In earlier versions of Hype, the IDs were generated by the Hype app itself when the element was created (rather than on demand by the runtime). This wasn't ideal for several reasons: they basically had to be long UUIDs always in an export, copy/pasting an element would need special management, would conflict if you had two instances of the same doc running on the page, and so forth. They should definitely be generated by the runtime in a way that doesn't conflict with other IDs, whether the other IDs come in before or after generation.

I added the seeded random function into the runtimes using a full export: (175,4 KB)

The seed is the one from the example above and should be based on something unique. Something that offers the most stability agains small changes. I made these exports just for have a testing ground and so people see what we are talking about in this thread.

Here is the same export without the changed runtime: (160,6 KB)

1 Like