document source of pageIndex

[bsutton]

The views use a page controller allowing methods like JumpToPage to move the view to a specific page.

The issue is that, how the pageIndex is related to a date isn't documented.

In digging through the code the index is based on the minDay argument (which is actually a date and perhaps poorly named).

If minDay isn't passed the the epocDate is used (1900/1/1).

Then the index is calculated as the numbers of days since minDay.

The maths is different for a month and week with and alignment operation occuring (to the first day of the month or week).

So the maths is actually slightly non-trivial and it must be right or things go awry.

The result is that the likes of jumpToPage is impossible to use without this documentation.

The maths is complicated enough that I think we should expose a method to translate between the index/date and back.

For reference I'm creating a single page that allows a user to move between views (day, week, month) and the 'current' date needs to be retained as the users swaps.
As the pageIndex is different for a given date I need to translate between page indexes on the different views so knowing how it is calculated is critical to a correct implementation.

[Sahil-Simform]

Hi @bsutton,

Thanks for raising this issue; your observations are absolutely valid.

You're right that while we expose methods like jumpToPage, the way the page index is calculated (based on minDay, with alignment for week and month views) isn't well-documented, which makes it difficult to use jumpToPage effectively.

That said, for most use cases, we recommend using the following helper methods instead:

• jumpToDate() in the Day View

• jumpToWeek() in the Week View

• jumpToMonth() in the Month View

These are also used internally and are designed to handle the complexity of index-date mapping for each respective view. If you're building a unified view switcher and need to retain the same logical date across views, using these methods would be more appropriate and reliable than manually computing page indexes.

I agree with your suggestion that the page index logic should be better documented (or exposed via a utility method), and we can consider that for future improvements. For now, since a working alternative exists and is already in place, we can lower the priority of this issue.

Please let me know if I’ve missed anything or if you have further suggestions.