The dates for stats should be changeable without limit

[irfano]

The dates for stats should be changeable without limit on the TRAFFIC tab.

[dangermattic]

Thanks for reporting! 👍

[notandyvee]

@guarani are we sure about this? What's the point of allowing a user to view stats in dates that don't exist?

[irfano]

@notandyvee, there is currently a limit on the date picker even though the site has more data. For example, the limit is 15 days on 'By day'. Site's created time is irrelevant to this issue. We cannot know if the lack of data for certain dates is due to the site not existing at that time or if there was no traffic. So it should be limitless, similar to iOS and the web.

[irfano]

💡 The structure related to this limit is a bit complex. Currently, we're caching certain data for dates upon the initial load. For example, we cache 15 days for "By day'. To remove the limit, we can call TrafficOverviewUseCase.fetchRemoteData() when the user selects the first date from the cached date list. This is just an idea.

[guarani]

What's the point of allowing a user to view stats in dates that don't exist?

Thanks for bringing this up! While there isn't a documented "site creation date" on https://developer.wordpress.com/docs/api/1.1/get/me/sites/, I found a created_at parameter in the response of that endpoint:

{
   ...
  "options": {
    ...
    "created_at": "2020-06-23T20:29:23+00:00",
  }
}

I think this could be used as a limit, wdyt @irfano and @notandyvee?

[irfano]

Good catch, @guarani! We can use it. So, there are 2 tasks

1. Remove the current limit, which is set at 15 dates.
2. Add the site creation date as the limit.

These are technically separate tasks. We can address "1." in this issue and target beta. We can open issues for "2" for both iOS and Android, without targeting the beta.

[notandyvee]

Hey @irfano . So you were right that the logic is a bit complex. I've looked through the code. And took your advice about looking into TrafficOverviewUseCase. I've made edits and noticed interesting behavior. Namely that there doesn't appear to be any pagination. Or at least nothing obvious. I tried looking at the stats endpoints (https://developer.wordpress.com/docs/api/), but can't find any docs on that specific one. So even if we increase the limit, this issue will persist.

I didn't want to move forward without making sure that the logic as it stands matches what I describe? Basically, we front load most of the stats at the beginning and it appears like we never paginate anything. If I am wrong, let me know. That will require more extensive edits if I am understanding it. Since you are more familiar with stats I wanted to run it by you first.

[irfano]

That's correct, this is not a quick fix. There's currently no pagination. We can also describe "remove the limit" as "add pagination".

The API already supports pagination, and it's implemented in FluxC. We're sending query parameters "date" and "quantity" that will return a specific count of data before the given "date".

You can consider addressing this issue as a HACK week project.

[notandyvee]

Thanks @irfano . I just didn't want to go down a rabbit hole in case there was a simpler fix. This is good info 🙏🏻