Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #35978 > unrolled thread
| Started by | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| First post | 2019-02-05 17:41 +0100 |
| Last post | 2019-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.
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
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2019-02-05 17:41 +0100 |
| Subject | Re: 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]
| From | Julio Di Egidio <julio@diegidio.name> |
|---|---|
| Date | 2019-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]
| From | Julio Di Egidio <julio@diegidio.name> |
|---|---|
| Date | 2019-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