Reprocess time elements on mutation

[northeastprince]

Fixes #151.

[josefarias]

Thanks for this @northeastprince

I don't think creating mutation observers within processElements would work, since that method can be called repeatedly from outside this class, and also in a recurring interval:

local_time/lib/assets/javascripts/src/local-time/controller.coffee

Lines 20 to 22 in 28a2d68

	startTimer: ->
	if interval = config.timerInterval
	@timer ?= setInterval(@processElements, interval)

That would result in tons of observers being created, possibly overwhelming the runtime.

Observing each element was my first instinct, too, when I first learned about this bug. But I'm not super keen on that approach because it has no upper bound on the amount of observers we're creating (even if only one per element). Plus, every observer will have the same purpose. Feels like we should be able to handle this further upstream.

I'll have to look at the morphing implementation (my colleagues @jorgemanrubia @afcapel are more familiar with that than I am) — but I wonder if we could dispatch an event after morphing (if we're not already) and force a reprocess when that happens. We could add a one-liner snippet to the readme to take care of this scenario, for users who happen to use both libraries.

Or, we could modify the single existing page observer to catch characterData mutations, in addition to childList ones.

local_time/lib/assets/javascripts/src/local-time/page_observer.coffee

Lines 30 to 37 in 1395c56

	processMutations: (mutations) =>
	elements = []
	for mutation in mutations
	switch mutation.type
	when "childList"
	for node in mutation.addedNodes
	elements.push(@findSignificantElements(node)...)
	@notify(elements)

I feel like observing characterData might be a bit much (and I'm not even sure it would work). So I'm partial to acting on a morph event. Will revisit this next week if time allows.

[northeastprince]

Agreed, we should just add something to the README. I opened #155 to add compatibility instructions.