chore: add comments on why we implement the lazy load pagination we way we did (#67)

Author: PatrickDinh

src/features/common/constants.ts

@@ -1,5 +1,9 @@
 export const ZERO_ADDRESS = 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY5HFKQ'
 // The default limit when we fetch data from the indexer
-// In most places, we use page size 10, 20, 30, 40, 50.
-// 100 items will give us at least 2 pages of data.
-export const DEFAULT_FETCH_SIZE = 100
+// We chose 100 because:
+//   - In most places, we use page size 10, 20, 30, 40, 50. 100 items will give us at least 2 pages of data.
+//   - 100 is small enough to not cause performance issues.
+//     For example, for the account EXECUTOREZZDJN3NFLVZNXE7UZKCERNFC6FD7SBXMVKASKRF4ZASJKN5BE
+//     the response size of fetching 100 items is 180Kb (Gzipped), which is ok.
+//     if we up it to 200, the response is 400Kb and can cause performance issues.
+export const DEFAULT_FETCH_SIZE = 200

src/features/common/data/lazy-load-pagination.ts

@@ -20,6 +20,10 @@ export type ViewModelPage<TViewModel> = {
 
 type FetchRawData<TData> = (nextPageToken?: string) => Atom<Promise<LoadDataResponse<TData>>>
 
+// We had to implement this way, instead of fetching items page per page
+// because the indexer doesn't return a deterministic number of items
+// it supports "limit" param, but that means the upper limit.
+// for example, when getting transactions with limit 10, it a maximum of 10 items, sometimes it returns 4 or 5 items
 type CreateLoadableViewModelPageAtomInput<TRawData, TViewModel> = {
   fetchRawData: FetchRawData<TRawData>
   createViewModelPageAtom: (