Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #35978 > unrolled thread

Re: Attributes containing JavaScript

Started byThomas 'PointedEars' Lahn <PointedEars@web.de>
First post2019-02-05 17:41 +0100
Last post2019-02-06 20:19 -0800
Articles 3 — 2 participants

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Attributes containing JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-02-05 17:41 +0100
    Re: Attributes containing JavaScript Julio Di Egidio <julio@diegidio.name> - 2019-02-05 10:51 -0800
    Re: Attributes containing JavaScript Julio Di Egidio <julio@diegidio.name> - 2019-02-06 20:19 -0800

#35978 — Re: Attributes containing JavaScript

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2019-02-05 17:41 +0100
SubjectRe: Attributes containing JavaScript
Message-ID<ee0cb136-b0aa-ec5e-5fb5-ded1b3166b04@PointedEars.de>
Stefan Ram wrote:
>   From the point of programming style, how do you assess the
>   following two approaches to add a click-handler?
> 
>   1.) Add the handler in JavaScript
> 
> <span id="span">

The ID that has been chosen here is unwise at best: also, the markup is
incomplete (there is no end tag) and therefore invalid.

> ..
> incrementSpan = () => span.innerHTML = +span.innerHTML + 1;

Reading and writing the “innerHTML” property requires serialization and
deserialization of the document tree.

If the content does not contain markup, the “textContent” property should
be used instead, which is more efficient, less error-prone, and more secure
(code injection is not possible this way).  Even if the content contains
markup, it is more efficient and secure to only modify the “textContent”
property of the child elements whose content is supposed to change.

> span.addEventListener( "click", incrementSpan );
> 
>   2.) Add the handler in HTML
> 
> <span id="span" onclick="span.innerHTML = +span.innerHTML + 1">0</span>
> 
>   (end of "2.)")
> 
>   What are the advantages and disadvantages of each approach?

There are those who say that the separation of script and HTML is an
inherent advantage of the first approach.  Although I do see certain
advantages in that, I am not one of those people.

A disadvantage of the first approach is the dependency on a particular
event model (and the need to handle alternative models, although those
are technically obsolete now) and decreased transparency as to what the
document does.  There is also the possibility that the document does not
do what is intended before a sufficient number of its components have
been loaded.

A disadvantage of the second approach is the risk of writing “spaghetti
code”, and having to deal with the possibility that characters
in script code need to be escaped that have significance in markup.

An advantage of the second approach is that the event listener can be
removed without relying on a framework with an event registry by assigning
the “null” value to the corresponding event-handler property.  However,
further event listeners may have been added to the same element for the same
event which would not be removed this way.  If *only* the second approach is
followed, that is also one of its disadvantages.

Because there is a third option: Something to the effect of

  <script>
    var my = {
      incrementSpan (target) {
        target.textContent = (+target.textContent) + 1;
      }
    };
  </script>
  …
  <span id="span" onclick="my.incrementSpan(this)">0</span>

There are probably lengthy discussions about this all over the Web.
Read, think, post.  In *that* order.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [next] | [standalone]


#35980

FromJulio Di Egidio <julio@diegidio.name>
Date2019-02-05 10:51 -0800
Message-ID<470622bf-4777-40c1-9636-b447855da522@googlegroups.com>
In reply to#35978
On Tuesday, 5 February 2019 17:41:13 UTC+1, Thomas 'PointedEars' Lahn  wrote:
[I reply here as I cannot see Ram's posts.]
> Stefan Ram wrote:
> >   From the point of programming style, how do you assess the
> >   following two approaches to add a click-handler?

Little to no significant difference and both very rookie in several ways.
Anyway, to make a long story short, that is a problem already solved: a
*two-way data-binding engine*, and you get ZERO plumbing.  Then, unless
you want to reinvent the wheel, use Knockout.js (which in fact is even
more than just data-binding).

HTH,

Julio

[toc] | [prev] | [next] | [standalone]


#35987

FromJulio Di Egidio <julio@diegidio.name>
Date2019-02-06 20:19 -0800
Message-ID<b6c600f6-ce6d-469e-9798-1771b414e657@googlegroups.com>
In reply to#35978
On Tuesday, 5 February 2019 17:41:13 UTC+1, Thomas 'PointedEars' Lahn  wrote:
> Stefan Ram wrote:

>   <span id="span" onclick="my.incrementSpan(this)">0</span>
> 
> There are probably lengthy discussions about this all over the Web.

There rather are several considerations that go beyond the little details of
the syntax, as in: architectural, design, and code structuring considerations.

That said, not only that is a discussion only among competent people otherwise
there is nothing to "discuss", moreover I wouldn't call discussions the tons of
crap that rather one finds all over the web.

HTH,

Julio

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.javascript


csiph-web