timeAgo without the timers

[junglebarry]

Description of the Issue and Steps to Reproduce:

Did you search for duplicate issue? [Yes / No]

Please describe the issue and steps to reproduce, preferably with a code sample / plunker:

This is a feature-request, not a bug report. I don't know if it is a good idea, but hoped to start a discussion. As a result, I'm removing the environmental details from the PR template (it's about the structure of code, and will be consistent across environments).

I was using amTimeAgo in my code, and for other reasons I was trying to control time using fakeAsync and tick. That worked perfectly well everywhere except where amTimeAgo was used, and I traced this back to the structure of the timeAgo pipe, which indefinitely schedules a job to update the value output by the pipe (so that it live-refreshes as time passes).

While this is quite clever and a great default behaviour, most of the dates in my app are on the timescale of months and years, and performance is an issue - I'd quite like to be able to disable the timed-updates. I should add that my motives are not just performance: the structure made testing difficult, as fakeAsync throws exceptions when there are tasks left on the queue, and since the pipe reschedules tasks indefinitely, there were always tasks left on the queue. I couldn't find a good way to use fakeAsync around a component containing amTimeAgo.

Might this be something you'd consider adding as a configuration option on the pipe? Does it exist already, and I've just overlooked it?

Many thanks!

[urish]

Hi, you have a good point there. I currently see three options:

1. Create a new pipe with this behavior, then we need to choose a name
2. Add another boolean parameter to the existing pipe
3. Modify the existing pipe so that it accepts an options object, in a backward compatible fashion (so if true or false is passed, it interprets this as the value for omitSuffix.

What are your thoughts?

[junglebarry]

My preference order would be 3 (best), 1, 2 (worst). Having options objects seems the most future-proofed, but introducing a new pipe is explicit.

I'd be reluctant to spoil your API by adding more boolean parameters - values without names are easy to misunderstand amTimeAgo:true,true,true,true..., and while you have only one parameter or clear type distinctions between type parameters, it's less of a concern.

I wonder if it might also be possible to specify the default options at module configuration or injection time. Perhaps the library could provide configuration options as a dependency-injected value (Angular2MomentConfig) with a default provided value, but allow that to be provided explicitly to use a different config? That would allow unit-tests to use a different config, with finer-grained control. I'm not suggesting that needs to be part of providing the above functionality; just a possible alternative/complement to whatever you'd choose. Probably overkill for now.

[urish]

I actually like this idea. Can you please come up with a Pull Request for that?