错误触发事件的替代方法(Alternative to Falsely Triggering an Event)

错误触发事件的替代方法(Alternative to Falsely Triggering an Event)

JS 下面的 JS小提琴演示

我一直在参与重新创建首选JS库的基础工具，以更好地提高我的技能。 目前我正致力于角色的功能数据绑定。

数据绑定的想法是获取数据并将其绑定到元素，以便在操作时，订阅的所有元素都将相应地更改。 我已经开始工作，但我没有考虑过的一件事是innerHTML vs value的问题。 根据您需要更改其中一个元素（在上面的演示中，您将看到我需要在条件语句中专门挑出按钮元素，因为它有两者，但这是一种边缘情况）

问题是，为了捕获我需要触发事件的SPAN标签更新，最简单的操作为Text Boxes / Textareas是'keyup'。

在我的函数中，如果你传入一个没有value属性的元素，我们假设你将更新innerHTML，我们设置一个观察者来确定元素是否会发生变异，如果它发生变化，观察者将发出一个'keyup'事件。

if (watchee.value == void(0)) { var keyUpEvent = new Event('keyup'); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(mutation) { watchee.dispatchEvent(keyUpEvent); }); }); observer.observe(watchee, { childList: true }); }

现在，这可能只是我的偏执狂，但似乎我可能会通过伪造一个本来不具备这种支持的元素上的“密钥”来挖掘一堆蠕虫。

TLDR：

我很好奇是否有另一种方法可以制作，除了伪造'keyup'/'keydown'/'change'事件之外，还有一个span标签是反应性的吗？ 例如，是否有一种方法可以使我自己的纯事件（纯粹我的意思是不依赖于其他事件）检查innerHTML或值是否已更改，然后执行函数？ 我知道这可能是一个计时器，但我觉得这可能会妨碍表现。

编辑 ：只是放在一边。 在演示中，名为hookFrom的函数通过获取DOM节点并返回一个函数，该函数将接收dom节点并继续返回一个函数，该函数将接收其他接收dom节点。 ：

hookFrom(sender)(receiver); hookFrom(sender)(receiver)(receiver2); hookFrom(sender)(receiver)(receiver2)(receiver3)(receiver4)...(receiver999)...etc

JS小提琴演示（与上面相同）

TLDR Below JS Fiddle To Demo

I've been really involved in recreating the tools that are foundations of premiere JS Libraries to better improve my skills. Currently I'm working on functional data-binding a la Angular.

The idea of data-binding is to take data and bind it to elements so that if manipulated all elements subscribed will change accordingly. I've gotten it to work but one thing I hadn't considered going into it was the issue with innerHTML vs value. Depending on the element you need to change one or the other( in the demo above you'll see that I needed to specifically single out the button element in a conditional statement because it has both, but that's kind of a fringe case )

The issue is that in order to capture a SPAN tag update I needed to trigger an event to happen, and the easiest one to manipulate for Text Boxes/Textareas was 'keyup'.

In my function then, if you pass in an element with no value property we assume you're going to be updating innerHTML, and we setup an observer to determine if the element ever mutates, and if it ever does, the observer will emit a 'keyup' event.

if (watchee.value == void(0)) { var keyUpEvent = new Event('keyup'); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(mutation) { watchee.dispatchEvent(keyUpEvent); }); }); observer.observe(watchee, { childList: true }); }

Now it may just be my paranoia, but it seems like I might be tunneling into a can of worms by faking 'keyup' on an element that doesn't natively have that support.

TLDR:

I'm curious if there's an alternative way to make, a.e. a span tag reactive other than faking a 'keyup'/'keydown'/'change' event? For instance, is there a way that I can make my own pure event(by pure I mean not reliant on other events) that checks if innerHTML or value has changed and then performs a function? I know that this is probably possible with a timer, but I feel like that might hinder performance.

EDIT: just an aside. In the demo the function called hookFrom works by taking a DOM node and returning a function that will take the receiving dom node and continues to return a function that will take additional receiving dom nodes. :

hookFrom(sender)(receiver); hookFrom(sender)(receiver)(receiver2); hookFrom(sender)(receiver)(receiver2)(receiver3)(receiver4)...(receiver999)...etc

JS Fiddle To Demo (same as above)

最满意答案

在本来不具备该功能的DOM节点上创建类似事件本身并没有错。 事实上，在很多情况下，当尝试为单独的浏览器和平台填充功能时会发生这种情况。

做这种DOM魔术的唯一问题是它可能导致其他事件的冗余。 例如，本文中给出的示例： https ： //davidwalsh.name/dont-trigger-real-event-names显示了使用相同事件名称的新创建事件如何导致问题。

该建议很有用，但在这种特定情况下可忽略不计。 代码在文本框，div，跨度等之间添加相同的功能......并且它们都是以相同的方式有意地处理的，并且如果事件将冒泡到另一个事件，那么它将是有意和有计划的。

简而言之：有一种蠕虫可以在伪造已明确定义的事件名称时进入隧道，但在这种情况下，代码很好！

There is nothing inherently wrong with creating a similar event on a DOM node that doesn't natively have that functionality. In fact this happens in a lot of cases when trying to polyfill functionality for separate browsers and platforms.

The only issue with doing this sort of DOM magic is that it can cause redundancy in other events. For instance the example given in this article: https://davidwalsh.name/dont-trigger-real-event-names shows how a newly minted event using the same event name can cause problems.

The advice is useful, but negligible in this specific case. The code adds the same functionality between text boxes, divs, spans, etc... and they are all intentionally handled the same way, and if the event would bubble up to another event, it would be intentional and planned.

In short: There is a can of worms that one can tunnel into while faking already explicitly defined event names, but in this case, the code is fine!