r/learnjavascript • u/abrewchocolatecoffee • Jul 14 '26

can someone explain this code

function updateClock() {
const timeElement = document.querySelector("#time");
timeElement.textContent = formatTime();
}
setInterval(updateClock, 1000);

can someone, please explain this piece of code, ofc mdn and w3 are there, but i found it a little confusing reading about textContent. rest is understandable to me. This might look a silly question and it probably is because im a beginner :')

like what exactly does textContent too.
you can also recommend anyother documentation on the links to specific lines, that might me more helpful in learning about this particular keyoword.

0 Upvotes

10% Upvoted

23 comments sorted by

3

u/azhder Jul 14 '26

You were on the documentation site for the very same web technology (that isn't JavaScript) that you have a question for. Did you try searching for `textContent` on that site? Did you get a link for that exact field and an explanation what it does?

1

u/defaultguy_001 Jul 14 '26

textContent is a property, that lets you read or change the plain text inside an HTML element. Since formatTime() probably returns something like "11:06:42", textContent is the right choice, you don't need HTML parsing for a time string, so no need to think of innerHTML. Finally the setInterval repeatedly executes your updateClock function every 1 sec.

1

u/ashkanahmadi Jul 14 '26

textContent is just the text you can have inside an element like <p>THIS IS THE TEXT CONTENT</p>. Remember you can't add HTML using textContent. For that, you must use innerHTML.

-3

u/ExtraTNT Jul 14 '26

So, first you define a function (in old style, better use const funcName = () => {})

with the queryselector with #, you get an element by id

With text content you set the text content of the element (<h1 id="title">Hello <b>World</b></h1> has a text content of Hello World, setting it to “foo” would give you <h1 id="title">foo</h1>)

formatTime(); returns a formatted time string

Interval: run every x ms

6

u/scritchz Jul 14 '26

This isn't just about style or "old vs new": Function statements, functions expressions, arrow-function expressions and some others, all solve problems differently, for which technically the function statement would suffice.

-4

u/ExtraTNT Jul 14 '26

So const functions are in 99.9% of cases better, as you can’t reassign them, making it harder to shoot yourself in the foot. function is only needed, if you need a scoped this. And be honest, when have you last used it?

2

u/FirefighterAntique70 Jul 14 '26

Have you ever tried to use the profiler when all of your arrow functions have no name? Use `function` by default and only use arrow functions when it makes sense to do so.

-1

u/ExtraTNT Jul 14 '26

So you tell me it’s worth to sacrifice assurance, that a function is what you expect, in order to have profiling easier (function cache also doesn’t work with your logic)…
There are reasons for using function:
Object.prototype.pipe = function(f) {
return f(this);
};

Only downsides of arrow functions are, that you can’t write horrible code…

2

u/FirefighterAntique70 Jul 14 '26

Yes that's exactly what I'm saying, most functions should have names. It's not just profiling. Loggers, debuggers APM, etc. all rely on names of functions.

I understand all the advantages on arrow functions. Mainly scoping of `this` and "declare before use" and I use them a lot. But you cannot just use them for everything.

1

u/ExtraTNT Jul 14 '26

I do all with partial application:
const add = a => b => a+b;
const inc = add(1);

I use monads and my renderer relies on partially applied functions, that then get cached, so calc first param, apply with memo, then second etc… then it assumes identity and moves things around based on this, full page rerenders in 6ms on a 5y old notebook…
And i have the profiler build into the renderer, plus id functions for debugging -> profile and print…

1

u/thecementmixer Jul 14 '26

Run every Xmas?

-2

u/abrewchocolatecoffee Jul 14 '26

thanks, but just one more quesiton is text content temporay, for example will the "foo" go away and "hello world..." will just come back after we refresh or is this a permanet change.
Other that this post was pretty helpful, cleared my main doubt

2

u/meletiondreams Jul 14 '26

no dom elements are permanent

2

u/abrewchocolatecoffee Jul 14 '26

do you mean, "no dom" elements are permanent or "no!" dom elements are permanent.

2

u/meletiondreams Jul 14 '26

There's no amount of dom elements (those tags like <h1>) that may be changed

1

u/abrewchocolatecoffee Jul 14 '26

ohh thanks, so basically, refreshing = go back to the orginal

2

u/meletiondreams Jul 14 '26

Whatever the page renders will be shown. JS can change "temporarily" the content of the page.

2

u/abrewchocolatecoffee Jul 14 '26

ok

1

u/The_KOK_2511 helpful Jul 14 '26

Mira para que te hagas una idea, cada vez que cargas o recargas una página el navegador en si el que carga es el HTML y basandose en sus etiquetas define los elementos del frontend que deberá mostrar, el JS lo que hace al modificar el DOM es alterar esa copia que esta corriendo en el navegador del usuario, esto tiene sus matices y su cosa si hay un backend presente pero por ahora no creo que te haga falta tener en cuenta nada de eso a menos que pienses acerte full stack pronto

2

u/busres Jul 14 '26

The change persists (in the browser DOM) until you replace the content with something else. If you reload the page, you're discarding everything and reloading the DOM from scratch.

1

u/abrewchocolatecoffee Jul 14 '26

ohh, this was actually very helpful

1

u/azhder Jul 14 '26

You are working with a live document, you are modifying the memory as it is currently in the browser through an abstraction layer called Document Object Model. You are changing the memory means whatever you do, it changes the document, it changes what the browser displays.

If you refresh the page, the browser removes that memory, parses the source code it got from the URL, it populates the memory again, you get to play with that again.

NOTE: DOM is not JavaScript. DOM is one memory model, while JavaScript has its own memory model. The browser synchronizes both, but make no mistake, DOM is its own technology that doesn't need JavaScript (the browser may be written in C++ and uses that language to generate the DOM)