Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge most UI page size settings into one #20550

Open
noerw opened this issue Jul 30, 2022 · 2 comments
Open

Merge most UI page size settings into one #20550

noerw opened this issue Jul 30, 2022 · 2 comments
Labels
type/enhancement An improvement of existing functionality type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@noerw
Copy link
Member

noerw commented Jul 30, 2022

Note: I'm opening this to gauge if there are actually instances out there that use different values for some of these settings.
β†’ πŸ‘Ž reaction means you do, πŸ‘ means you don't


the problem

There's problems with all these page size config settings:

  • they are overly specific, lacking a use case
  • although having very specific names, they are still used for multiple things (IssuePagingNum for issues, projects, milestones)
  • they bloat the docs
  • they are partly undocumented
  • they have the same default value (at least as of Increase default item listing size ISSUE_PAGING_NUM to 20Β #20547)
  • they have a bad naming convention 😬

the proposal

Let's remove:

ExplorePagingNum:    20, // ui.EXPLORE_PAGING_NUM
SitemapPagingNum:    20, // ui.SITEMAP_PAGING_NUM
IssuePagingNum:      20, // ui.ISSUE_PAGING_NUM
RepoSearchPagingNum: 20, // ...
MembersPagingNum:    20,
FeedPagingNum:       20,
PackagesPagingNum:   20,

and replace with

PageSize: 20,

This would leave us with the following UI page size settings:

PageSize:            20,
FeedMaxCommitNum:    5,
GraphMaxCommitNum:   100,
CodeCommentLines:    4,
ReactionMaxUserNum:  10,

I'd say the complexity of providing backwards compat is not worth it, as the resulting breakage will be very minor.
Maybe we could maintain ISSUE_PAGING_NUM as deprecated fallback, that's the setting I've seen used most often (because it defaulted to 10 until #20547)

Screenshots

No response

@noerw noerw added type/proposal The new feature has not been accepted yet but needs to be discussed first. type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/enhancement An improvement of existing functionality and removed type/feature Completely new functionality. Can only be merged if feature freeze is not active. labels Jul 30, 2022
@lunny
Copy link
Member

lunny commented Jul 31, 2022

But release page size should be different. We could have a default one which could be override by others.

@noerw
Copy link
Member Author

noerw commented Jul 31, 2022

Good pointer, that size is not among the list of settings to remove from the [ui] section.
Turns out there is another page size option in config section [repository.release] ([1]), which is the only frontend page size that is in a separate section.

Also, there's some code that makes use of the API page limits in the frontend ([1], [2]), this would also be good to clean up (either move the setting out of the API scope, or add a separate setting for UI).

  • [1]
    listOptions := db.ListOptions{
    Page: ctx.FormInt("page"),
    PageSize: ctx.FormInt("limit"),
    }
    if listOptions.PageSize == 0 {
    listOptions.PageSize = setting.Repository.Release.DefaultPagingNum
    }
    if listOptions.PageSize > setting.API.MaxResponseItems {
    listOptions.PageSize = setting.API.MaxResponseItems
    }
  • [2]
    // NewAbsoluteListOptions creates a list option with applied limits
    func NewAbsoluteListOptions(skip, take int) *AbsoluteListOptions {
    if skip < 0 {
    skip = 0
    }
    if take <= 0 {
    take = setting.API.DefaultPagingNum
    }
    if take > setting.API.MaxResponseItems {
    take = setting.API.MaxResponseItems
    }
    return &AbsoluteListOptions{skip, take}
    }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement An improvement of existing functionality type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

2 participants