[#763] v_summary.js: ensure getFiltered() is only called once when reloading page

[jamessspanggg]

Fixes #763

When reloading the report page, the data in v_summary such as
filterSinceDate, filterUntilDate, filterTimeFrame etc will change based 
on the URL hash values. The changes in data will trigger the watchers 
for those data, and each of them will call getFiltered() method.

Only one call for getFiltered() is required after rendering the filter 
hash, the other getFiltered() calls by the watchers are redundant.
When the report is large in size, repeatedly executing getFiltered()
when reloading the report will also significantly affect the loading 
performance of our report.

Let's only allow watchers to execute getFiltered() after the first 
cycle of watcher updates to prevent redundant calls to getFiltered().

[fzdy1914]

I am wondering how can you judge how many times getFiltered is called?

[jamessspanggg]

@fzdy1914 The number of modified toolbar controls. (Modified as in not the same as the default value)

By default, the watcher for tmpFilterSinceDate and tmpFilterUntilDate will be called as their default values are empty strings ‘ ‘.

So if the user changes group by to ‘groupByAuthors’ and granularity to ‘week’ (both are different compared to their default values), getFiltered will be called 5 times. (1 time for created() hook in v_summary, 2 times for tmpFilterSinceDate and tmpFilterUntilDate, and another 2 times for group by and granularity)

[fzdy1914]

LGTM, I have tested, it indeed reduce the filter times from 3 to 1.

[yong24s]

Should this be method with a descriptive name?

[jamessspanggg]

Yes I think it would be better to make this as a method.

[eugenepeh]

instead of doing this, why not just return in getFiltered if this.isWatcherUpdated is false instead?
It doesn't really quite make sense to name the method getFilteredAfterWatcherUpdated if all has to check for isWatcherUpdated