Forem: Eckehard

getElementBy... ...destructuring

Eckehard — Thu, 02 Apr 2026 21:11:54 +0000

I've always wondered how verbose and cumbersome some very common web constructions are. One of this is getElementBy..., which is used as a central interface between Javascript and HTML

const myElement = document.getElementById("demo");
myElement.style.color = "red";

This are 81 bytes pure text plus one constant in the global namespace, just to change a color. You can also write this as a oneLiner:

document.getElementById("demo").style.color = "red"

still 52 bytes used.... You can also use

document.getElementsByClassName()
document.getElementsByName()
document.getElementsByTagName()

holy shit, what a waste of bandwidth.

Not only that the command is lengthy, it forces you to define an ID and a variable. And how do you know, that "myElement" and "demo" refer to the same element? Is this programming or a shell game? And - this is javascript used in a browser. You not only need to write it, each letter also has to be transferred over the internet. They could have used something smarter like DOM.ID(), which would reflect the tag you used for definition. But who cares.

I found a pretty nice solution to stop this waste of space: Use a Proxy!

getById = new Proxy(
    {},
    { 
      get: (_, tag) => {
        return document.getElementById(tag);
      },
    },
  );

You can also write this as a oneLiner too:

getById = new Proxy({},{get:(_, tag)=>{return document.getElementById(tag);},},);

Proxies are strange, but very helpful in this case. This is how you use it:

HTML:
<input id="filename"/>
<span class="chip-label">Search:</span>
<input id="search-input" placeholder="Suchen…" />
<button id="btn-search-prev" class="btn">↑</button>

Javascript:
 const {filename, 
       "search-input":searchInput, 
       "btnSearch-prev": btnSearchPrev
       } = getById;

You can use the ID as a variable name, like "filename" above. But a name like "search-input" is not valid in Javascript, so the proxy allows renaming: "search-input":searchInput declares the renaming rule.

HTML ID´s are fixed, they do not change during program execution. So using getById is safe and maybe much better than spreading getElementBy... over your whole codebase.

Happy coding....

About the "S" in Solid

Eckehard — Sat, 29 Jun 2024 22:33:39 +0000

You probably know the "SOLID principles", which should help you to be a better programmer. And maybe, you are still struggeling with the "S", the Single-responsibility principle (SRP). Maybe I can give you a different view on this topic.

Ok, we are talking about OOP, the Object Oriented Programming. As Robert C. Martin (Uncle Bob), the originator of the term, was editor-in-chief of C++ Report magazine, we can assume he probably was using this langauge. Did you ever wonder about the strange formulation:

"A class should have only one reason to change"?

Often enough, we find this explanation: "A class should have only one reason to change, meaning it should only have one job or responsibility". But, what is "a job?" Is it a complex task or keeping a single state? If a class has the job to print something, in which kind is it changed, if it is doing the job? Let´s say: We get more questions than answers.

So, maybe we should have a look back to what C++ was used for in 2003. This is an overview of the Microsoft Foundataion Classes (MFC):

Ok, this is the 1st of three charts, but all classes are derived from CObject, which implements the most basic behavoir of MFC-Objects. You will find all kinds of Interface objects that can be used to build User Interfaces, but also handle Drag&Drop-Actions, store the current UI state and so on. This are the building blocks of all Windows Applications:

"The Microsoft Foundation Class (MFC) Library and Visual C++ provide an environment that you can use to easily create a wide variety of applications." (Source).

If you are building with User interfaces in C++, you usually do not start building classes from scratch. You select an appropriate class that provides most of what you need, so you just add some specific code. So, you start with one of the foundation classes or one of it´s decendants. As an example, you want to create a new input field to be used in the Application UI. As the UI only accepts classes that are derived from certain core classes, you need to start with one of the existing classes. Therefore you inherit a lot of skills that each UI-element must have. To minimize your work, you select an element that is very similar to what you want and add only what you need. Thanks to inheritance and polymorphism, this is possible without breaking the existing code.

Later Robert C Martin explained the SRP as cohesion: "Gather together the things that change for the same reasons. Separate those things that change for different reasons". You surely need more than one thing to gather something.

In C++, class hierarchies can be quite complex and deeply nested. But if you follow the SOLID principles, you will be able to manage this complexity. Think of a class always as part of a hierarchy. Each new class, you add to this hierarchy, sould have a single task. This does not mean, it should only have one method or one state. But all properties and methods it implements should be focused on the same task. I suppose, this is, what Uncle Bob meant.

There is another aspect of the SRP that you can only understand thinking in hierarchies: A hierarchy is like a tree, each method you add to the root is inherited by all the branches and leafs. If you choose the wrong position, you might be forced to implement the same code in multiple branches. To keep your code maintainable, you should try to find a position where every task needs to be implemented only once. This could also be seen as a "single responsibility principle": For each task (in a class family), there should only be one member that is responsible for this task.

Finally I´m not sure what Uncle Bob was really trying to say, but I know, that using OOP without taking benefit of inheritance does not make much sense.

One Byte Explainer: Homogenous coordinates

Eckehard — Fri, 14 Jun 2024 20:21:12 +0000

This is a submission for DEV Computer Science Challenge v24.06.12: One Byte Explainer.

Explainer

To display a 3D scene on a 2D screen, each point needs to be projected. This can include multiple steps. Homogenous coordinates, introduced by A.F. Möbius in 1827, provide a way to combine the whole transformation pipeline into a single matrix operation.

Object Oriented Programming

Eckehard — Fri, 14 Jun 2024 12:56:33 +0000

This is a submission for DEV Computer Science Challenge v24.06.12: One Byte Explainer.

Explainer

Class based OOP is a paradigm that uses classes as templates for reusable code modules (objects). Objects can have their own private data and functions. Inheriting child classes is the way to extend functionality while keeping the existing codebase stable.

Flems.io

Eckehard — Wed, 05 Jun 2024 10:06:17 +0000

Today I would like to do some advertising. Do you know

Flems.io ?

Flems.io is a simple, but very smart prototyping platform ideal for testing oder demonstration of HTML/CSS/Javascript or even Typescript. Ok, simple might not be the right wording, it´s just super simple to use. Under the hood, it provides quite a lot:

Flems supports TypeScript, LiveScript and Babel (standalone) compilation too. You can add CSS & JS dependencies by specifying a full URL pointing to the desired file, or by giving a reference to an NPM package (and optional path) - these will be taken from unpkg.com (See the documentation for more info.)

Flems.io is similar to online editors like CodePen or JSFiddle, but has one unique selling point. You do not need an account or any external memory: Flems.io stores all data in the URL!. This is ideal for short tests and demos provided on dev.to or other online media.

Flems-URL´s can get quite long as they store all information + page settings, so you might push the limits using windows desktop links, which are limited to 256 characters. But using Flems-URL´s on online platforms like dev.to is usually not a problem. Unlike other platforms Flems.io does not require any initialization, so it is up and running in no time. It´s best usable for short demos or just for a quick test of some lines of code.

Here is an example, i alredy provided here

EXAMPLE

Happy coding!

Revisiting the "Revealing Module pattern"

Eckehard — Sat, 27 Apr 2024 13:33:27 +0000

(Cover Image source)

Maybe you've heard of the "Revealing module pattern" [RMP], which is a way to create protected code modules in Javascript. Unlike JS class objects, code inside the modules cannot be altered from the outside, which can be a huge benefit to protect your code from it´s worst enemy: you yourself! There are quite some explanations on the pattern on the net (even on dev.to), but I like to show some extensions to make the patter more useful.

The RMP uses the fact that local functions and variables created inside a function cannot be reached from the outside. The function body forms a local scope, that is insulated from the rest of the program. To make elements inside the function body available, the main function returns an object containing the all referencs that should be accessible. See an example here:

function Person(myName) {
  let name = myName

  function log(txt) { console.log(txt) }
  function public_talk() { log(name + " is talking") }
  function public_dance() { log(name + " is dancing") }

  // interface
  return {
    talk: public_talk,
    dance: public_dance
  }
}

let father = Person("Peter")

father.talk()
father.dance()

Person returns an object contaning just the two functions talk and dance, so all the "internals" are hiden to the outside world. In contrast to JS classes, the code inside an RMP looks pretty normal, in fact the RMP-body looks and works exactly like a small program inside the rest of the code. But there are some downsides too. Most of all, they lack any form of inheritance, so RMP-modules are not open for extensions. But let´s see, what we can do on this...

JS Tricks and shortcuts

The examples below use some JS-"tricks" that are absolute standard, but which you may or may not be familiar with, so here is a short introduction:

// Destructuring
let {a, b} = myFunction()
-> if myFunction returns an object {a:1, b:2, c:3}, a and b are assigned to local variables.  

// Arrow-functions
function value(){return x}
value = () => x
-> Shorter, if you just need to return a value

// ES6-shorthands
let a=1, b=2
let ob = {a:a, b:b}
-> instead, you can just write ob = {a,b}

// getter and setter
let a=1, b=2
let ob = {
  get a(){ return a}, 
  set a(x){ a = x },
  b
}
-> setter can be used like a normal proerty ob.a = 5, but invokes a function call

This "tricks" are important to know to understand the following code examples.

Improving the Revealing Module Pattern

First, let see if we can make our example a bit smarter:

function Person(name) {
  function log(txt) { console.log(txt) }
  function talk() { log(name + " is talking") }
  function dance() { log(name + " is dancing") }

  // interface
  return {
    talk,
    dance
  }
}

let father = Person("Peter")
...

We do not need a variable to keep the name, as name is already a local variable in the function scope. So Parameters do not need to be stored and can be altered too. And we do not need separate names for our functions using ES6-shorthands.

Removing limitations

But what about changing values from the outside? Ok, you can build a function to to the job. But there are better ways. Let´s try to expose a "variable":

function Person(name) {
  function log(txt) { console.log(txt) }
  function talk() { log(name + " is talking") }
  function dance() { log(name + " is dancing") }

  // interface
  return {
    name,
    talk,
    dance
  }
}

let father = Person("Peter")
father.talk() // --> Peter is talking
father.name = "Paul"
father.talk() // --> Peter is talking

This does not work, as the object just returns a copy of our value. Even if we change the value of name inernally, this would not be reflected in the result. But we can use getters and setter to get what we want:

...
// interface
  return {
    get name(){return name},
    set name(x){name = x},
    talk,
    dance
  }
  father.talk() // --> Peter is talking
  father.name = "Paul"
  father.talk() // --> Paul is talking

Hint: Be careful with getters! They work only in the initial context. So, you can use father.name = "Newname". But if you destructure father, you will receive a string, not a getter:

let {name} = father
name = "Paul" // --> does not change the internal variable
father.name = "Paul" // --> does change the internal variable

How to inherit?

This is my very special pattern to implement a simple form of inheritance. Often it comes handy to be able to extend or change an existing "module" without changing the initial code. Hier is my proposal:

function Person(name) {
  function log(txt) { console.log(txt) }
  function talk() { log(name + " is talking") }
  function dance() { log(name + " is dancing") }

  // interface
  return {
    private: {
      log,
      get name(){return name}
    },
    talk,
    dance
  }
}

function Woman(_name) {
  // Inherit
  let Super = Person(_name)
  let { name, log } = Super.private

  function talk() { log(name + " is a talking woman"); }
  function jump() { log(name + " is jumping") }

  return Object.assign(Super, { talk, jump }) // Override talk
}


let father = Person("Peter")
let mother = Woman("Claire")

father.talk()
father.dance()

mother.talk()
mother.dance()
mother.jump()

Some comments on the code:

Super: This object keeps all references from the "parent" module. You can add new functions to the class by extending the object. Initially i tried this:

return{...Super, { talk, jump }}

This works, but breaks the getters and setters. So, it is advised to use Object.assign() to extend the parent class.

private: This retrns references that are not intended for external use. You do not need to use this, but putting some references inside a sub-object reminds me on the task.

destructuring: You can simply use Super.private.log(), but destructuring make the functions available in the local scope. It´s simply easier to read. But be careful: Destructuring name returns a string. If you want to invoke the getter, you need to use Super.private.name instead.

polymorphism: There is a pretty simple way to even change parent frunctions from inside a child class. Just use a setter to make parent functions mutable:

...Parent: 
// interface
  return {
    private: {
      get log(){log},
      set log(x){log = x}
    }
  }

...Child:
  function mylog(){}
  Super.private.log = mylog

Ok, the RMP will not provide anything a full featured class system may contain, but it has a lot of advantage:

You can use the same code inside and outside the module
Variables and functions are protected by desing until you manually expose them to the public
The RMP is simple Javascript, no hidden gems. So it will most likely work on a wide range of browsers without any polyfilling

The RMP can be a powerful part in your toolbox. With some extensions, it can be even more flexible.

Here is a working example to see all patterns in action

Happy coding!

Measuring performance

Eckehard — Sat, 20 Apr 2024 21:25:36 +0000

Javascript is a powerful but sometimes strange programming language, especially when it comes to performance. Some effects are the result of implementation details and performance may vary between browsers and even between different versions of the same browser. So, the only way to find out is to try. But even that can be a strange journey, as you may see.

Generally, Javascript performance is very high, so we should not care too much about it. There are many things going on while a website is rendered that take much longer than Javascript execution, so it is unlikely to make a slow page fast just by optimizing Javascript. But if you are dealing with large arrays, text parsers or other kind of operations, that include manipulation of thousands or even millions of elements, performance may become critical.

There are several ways to measure time in Javascript (See here), usually I´m using the performance API. It is just not as precise as it could be, as for some reason it is intentionally limited to 100 ms to avoid browser fingerprinting (see here for details), so you need to repeat the code multiple times to get better results. But there is one effect that is important to know and that I cannot really explain.

Can somebody explain?

See the example below. This is a simple loop that changes a static array of 10.000 elements. To make it measurable, the operation is repeated 1000 times. Finally, it finishes in about 100 ms, which means, the total array of 10.000 elements was changed in 0,1 ms - amazing. Each operation took 0,01 us or 10 ns only!

    const count = 1000 // Number of repetitions

    function run() {
      ar1 = Array(10000).fill(" ")
      for (k = 0; k < count; k++) {
        for (i = 0; i < ar1.length; i++) {
          ar1[i] = "+"
        }
      }
    }

    t0 = performance.now()
    run()
    t1 = performance.now()
    run()
    t2 = performance.now()
    run()
    t3 = performance.now()
    run()
    t4 = performance.now()

console.log(`Time 1 = ${(t1 - t0).toFixed()}ms`)
console.log(`Time 2 = ${(t2 - t1).toFixed()}ms`)
....

Console ------>

Time 1 = 167ms  <--
Time 2 = 124ms
Time 3 = 117ms
Time 4 = 124ms

But the strange thing: The first loop took about 40% longer than the next three. I tried this several times, but always the first loop took longer than the rest.

Thigs get even stranger if I rerun the page:

Time 1 = 106ms
Time 2 = 84ms
Time 3 = 89ms
Time 4 = 80ms

The first loop is still slower, but now all loops run about 30% faster. After the second rerun, results get fairly stable, but still vary by about 5%.

I repeated this multiple times with different codes, but always the first loop is significantly slower than the following.

A second test

Here is an extension to the example above. I added a second routine. This is the same code, just instead of for ( ; ; ) I used for ( ..in.. ), which is known to be slower:

    function run2() {
      ar2 = Array(10000).fill(" ")
      for (k = 0; k < count; k++) {
        for (i in ar2) {
          ar2[i] = "+"
        }
      }

    t0 = performance.now()
    run()
    t1 = performance.now()
    run()
    t2 = performance.now()
    run2()
    t3 = performance.now()
    run2()
    t4 = performance.now()

Console ------>

Time 1 = 141ms
Time 2 = 115ms
Time 3 = 1621ms
Time 4 = 1663ms

Amazing enough, for ( ..in.. ) is about 10 time slower than the conventional loop. But the first routine still is also much slower on the first run. Imagine, I would have only compared two loops: My results would have been significantly wrong.

Let´s test in reverse order:

Time 1 = 1737ms
Time 2 = 1533ms
Time 3 = 103ms
Time 4 = 101ms

Differences are - relatively - smaller, but still, the first loop takes about 200ms longer than the second.

I cannot really explain, why the first loop is always so much slower. But it is in any way important to know, as otherwise your comparison could be misleading. Currently, I´m repeating all my tests multiple times to get more reliable results.

If you have any different experience or know a more reliable way to benchmark code, please let me know.

Nano "Typescript" without compilation

Eckehard — Thu, 28 Mar 2024 10:46:06 +0000

Thanks to this post from Toby Farley (Shadow Chicken), I had an inspiration to build my own tiny little nano "typescript" running without compilation.

Ok, typescript provides much more, but if you only need some typechecks, this little routine would do the trick:

/* ==================================================
    Nano typeCheck
    Valid types
    "var": Variant - all types allowed 
    "string"
    "number"
    "bigInt"
    "boolean"
    "object"
    "array"
    "date"
    "set"
    "function"
  ================================================== */
  function typeCheck(v) {
  if ((typeof v) !== "object") throw (`Parameter must be Object in function ${typeCheck.caller.name}`)

  // Build return value array
  let res = Object.entries(v).map((a, i) => {
    let [typ, val] = a;  // get key/values
    typ = typ.charAt(0).toUpperCase() + typ.slice(1) // Capitalize
    if (typ === "Var")  // Variant type
      return val
    if (val.constructor.name !== typ) // check type
      throw (`Type error parameter ${i + 1} is not ${typ} in function ${typeCheck.caller.name}`)
    return (val)
  })
  return res
}

function myFunc(a,b,c,d) {
  typeCheck({ string: a, boolean: b, array: c, var: d })
  console.log(a)
  console.log(b)
  console.log(c)
  console.log(d)
}

myFunc( "5",  true, [1, 2, 3, 4, 5], "Do what you want")

You can also submit typ declaration with the parameters like this:

function myFunc(pars) {
  let [a, b, c, d] = typeCheck(pars)
  console.log(a)
  console.log(b)
  console.log(c)
  console.log(d)
}

myFunc({ string: "5", boolean: true, array: [1, 2, 3, 4, 5], var: "Do what you want" })

Types can be named using the standard type names with lower or upper case, so both would be accepted:

{ string: a, boolean: b, array: c, var: d }
{ String: a, Boolean: b, Array: c, Var: d }

Tell me, what you think.

P.S.: This post was changed after the first sumbission to show different ways of usage.

6 times faster loops in Javascript

Eckehard — Tue, 19 Mar 2024 00:26:54 +0000

Javascript is fast. Really fast - at least if it´s running in a modern browser. So, in general you should not care too much about performance. But when it comes to text processing, things might be worth a closer look:

are there impacts of the way we manipulate strings? Memory managmenet can cause serious bottlenecks
Do the loops make any difference?

I really did not know, so I did some performance testing with interesting results that I want to share here.

Do some tests

My test case was quite simple: Add an "x" to each line of a text of 251 lines. Import of the file was done before measurement, so reading the text into a variable was not part of the test. I used the performance-API on chrome, which is intentionally a bit reduced in precision, but delivers reasonable results if you repeat your task often enough. In this case, I repeated the task 10.000 times.

So, this was my first code (count = 10_000, 251 lines):

for (n = 0; n < count; n++) {
      res1 = text.split("\n").map(line => line + "x").join("\n")
    } // Time 1 = 190ms, average 0.075 us/line

So, here we split the text into an array, convert the array and join the lines again finally. So we get the initial text with x added to every line. And performance is amazing! This are 1.5 Mio. text operations done in 0.19s, each operation was done in about 0,075 Microseconds on my fairly old machine.

But could we do better? Array manipulation might include some memory shifting. This was my second try:

for (n = 0; n < count; n++) {
      ar = []
      text.split("\n").forEach(line => ar.push(line + "x"))
      res2 = ar.join("\n")
    } // Time 2 = 178ms, average 0.071 us/line

Instead of map() I used array.push() to build the array, but this was only slightly faster.

The next try was to avoid join() by adding the string manually:

for (n = 0; n < count; n++) {
  res3 = ""
  text.split("\n").forEach(line => res3 += line + "x\n")
} // 82ms, average 0.032 us/line

This was a big jump: It seems, string concatenation is really fast, cutting the time by more than 50%.

But what about the loops? ferEach does all the heavy lifting, so we should try it out:

for (n = 0; n < count; n++) {
    lines = text.split("\n"); res4 = ""
    for (i = 0; i < lines.length; i++)
      res4 += lines[i] + "x\n"
  } // Time 4 = 33ms, average 0.013 us/line

This was a suprise: The good old loop performs much better! Compared to the inital loop, this was 6 times faster! Amazing!.

But well, this looks a bit oldfashioned, so how about the modern style? See the results:

This is for .. in

for (n = 0; n < count; n++) {
    lines = text.split("\n"); res5 = ""
    for (i in lines)
      res5 += lines[i] + "x\n"
  } // Time 5 = 172ms, average 0.068 us/line

and for .. of

for (n = 0; n < count; n++) {
    lines = text.split("\n"); res6 = ""
    for (line of lines)
      res6 += line + "x\n"
  } // Time 6 = 36ms, average 0.015 us/line

So, finally we are back in the winning row, but results are really surprising: Just changing the loop style can slow you down by a factor of 5-6 (may be different on other machines). I added the code at the end of this post. The results will be different on your machine, as they are also depending much on the processor architecture.

There is absolutely no general rule. Things are much depending on the implementation details, and can be different on different browsers. But as you might see: It is worth to do some performance testing to get better results.

If you want to try out, here is a working example

Better event throttle

Eckehard — Mon, 26 Feb 2024 11:57:47 +0000

Sometime you need to make your code slower to make it faster...

Usually we want our code execute as fast as possible. But in case of DOM events, it can be useful to limit execution rate (see this post). Some events like window scroll may fire with a very high frequency, which may lead to a poor user experience or even blocking of the event chain.

You will find numerous implementations of throttle functions, the most common is presented here. Usually throttle executes the first event and then limits the rate of repetition. But in a UI it may happen, that there is not a single event causing a state change, but a burst of events happening in a short time. You might have some coupled states that depend on each other. Firing the first event would propagate only the first state change, but the depending changes would be suppressed until the next update. To prevent this, you would use a "debounce" function, that waits until the state has settled before propagating the first event.

As the situation happens frequently, I found it helpful to combine both functions in an advanced throttle function:

function throttle(cb, delay = 10, rate = 50) {
  let wait = false
  let args, timeout
  const tf = () => {
    if (args == null) {
      wait = false
      clearTimeout(timeout)
    } else {
      cb(...args)
      args = null
      timeout = setTimeout(tf, rate)
    }
  }

  return (...arg) => {
    if (wait) {
      args = arg
      return
    }
    wait = true
    setTimeout(() => {
      cb(...arg)
      timeout = setTimeout(tf, rate)
    }, delay)

  }
}

This version uses an initial delay before calling the event function. After that, it limits the throttle rate to a different value. After the last event has happened, the execution stops and the next event will be propagated after the initial delay again. The default values of 10 ms and 50 ms have been found the be nearly unnoticeable, but any other value may serve better in your case.

The throttle function can be used as a function wrapper, arguments provided to the result will be forwarded to the wrapped function (see example below)

  function showScroll(){
    out.textContent = "scroll-position = "+window.scrollY
  }
  window.onscroll =  throttle(showScroll,10,250)

  // function wrapper example
  function log(s){
     console.log(s)
  }
  const tlog = throttle(log,500,2000)
  tlog("This is a test")

You can try out a working example here

Better array concat...

Eckehard — Sat, 10 Feb 2024 01:14:59 +0000

There are different ways to concatenate arrays in Javascript. The most common way is using the spread-syntax:

let a,b,c
a = [1,2,3,4]
b = [5,6,7,8]
c = [...a,...b] // -> [ 1, 2, 3, 4, 5, 6, 7, 8 ]

more ways shown here.

But what, if you need to deal with flexible types?

a = [1,2,3,4]
b = 5
c = [...a,...b] // -> b is not iterable

I came across this problem in a routine, that got passed some variables, that could be either arrays or single values. Doing some type checks would be an option, but how to deal with the different possible cases? Finally I came across a dead simple solution, that does not require any programming at all:

a = [1,2,3,4]
b = 5
c = [a,b,6].flat() // [ 1, 2, 3, 4, 5, 6 ]

The flat-operator flatens only one level, so this works also with nested arrays. If you want deepter flattening, you can specify the depth using flat(n).

Talking of functions, the trick can also be used with function parameters:

const concat = (...x) => x.flat()

a = [1,2,3,4]
b = 5
c = concat(a, b, 6) // -> [ 1, 2, 3, 4, 5, 6 ]

More Advantages of using flat()

By default, Javascript creates "shallow copies" of arrays (copy by reference). This might have unwanted effects:

a = [1,2,3,4]
d = a
d[2]=99 
console.log(a) // -> [ 1, 2, 99, 4 ]
console.log(d) // -> [ 1, 2, 99, 4 ]

Here we changed a without touching it. "a" and "d" share the same data. If we want to create a real copy with separate data, flat(0) is one option:

let a,b,d
a = [1,2,[3,4]]
d = [...a]
d = a.flat(0)
d[1]=99 
console.log(a) // -> [ 1, 2, [ 3, 4 ] ]
console.log(d) // -> [ 1, 99, [ 3, 4 ] ]

Easy Math in Javascript

Eckehard — Thu, 08 Feb 2024 10:30:40 +0000

Javascript provides a Math-object, that covers a broad range of useful constants and functions. However, sometimes it may happen, your are missing a function or the builtin function does not provide what you need. And - not everybody is happy that all Math-functions need to be prefixed by the word "Math". But luckily, Javascript is a flexible language and there is some help.

Extending the "Math"-object

Actually, it can be seen as a weak point, that Javascript objects do not have any access protection. In our current case, this is an advantage. You can easily add new functions to the "Math"-object or even change the inbuilt ones. Here is an example of the round()-function, that does not allow to set decimals. But this can be easily fixed:

Math._round = Math.round
Math.round = (f, n = 0) => { 
  let m = Math.pow(10, n)
  return (Math._round(f * m) / m)
}

Here, we store the initial round function in a new property called _round. Then we can overwrite the initial property with a new function.

We can also extend the Math-object with some useful stuff:

Math.PI2 = 2*Math.PI

// Range-Check: True if x in Range (L .. H)
Math.inRange = (x, L, H) => (x < L) ? false : x <= H  

// Constrain value: Limit x to range (L .. H)
Math.constrain = (x, L, H) => x < L ?  L : x > H ? H : x

The new functions work seamlessly as if they where inbuilt.

Math destructuring

So, and how to get rid of the Math-prefix? You can use object
destructuring here:

let {sin, cos, round, inRange, constrain, PI, PI2} = Math

Now the functions are available in the global scope:

round(sin(0.1*PI2),3) // -> 0.588
inRange(3.158,2,4) // -> true
constrain(3.158,4,5) // -> 4

You can play around with the code in flems.io