Opened 11 months ago

Last modified 11 months ago

#6450 new change

[meta] Optimize options page for large amounts of filters

Reported by: greiner Assignee:
Priority: Unknown Milestone:
Module: User-Interface Keywords:
Cc: wspee, saroyanm, agiammarchi, mapx Blocked By: #2708, #6440
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by greiner)

Background

We've been encountering various issues when modifying large amounts of custom filters in the options page at once in #6440. Therefore we should make optimizations across our code base to better support such large batch modifications.

There are various areas where we can reduce the overhead such as:

  • message passing
    • use long-lived connections
    • reduce the amount of data
    • reduce the amount of messages
  • filter loading
    • implement lazy loading
    • reduce the amount of operations

What to change


Change History (6)

comment:1 Changed 11 months ago by greiner

  • Cc wspee saroyanm agiammarchi added
  • Description modified (diff)

comment:2 Changed 11 months ago by greiner

  • Blocked By 6440 added

comment:3 Changed 11 months ago by greiner

  • Blocked By 2708 added

comment:4 Changed 11 months ago by mapx

  • Cc mapx added

comment:5 follow-up: Changed 11 months ago by agiammarchi

Just to clarify, #2708 is the infinite list scroll which we decided to not put into the current milestone since it's a way to big story, compared to #6440.

Making it a blocker shouldn't prevent us to ship #6440 a part, since there is already a codereview in place and no need for specifications and/or UX studies, am I correct?

comment:6 in reply to: ↑ 5 Changed 11 months ago by greiner

Replying to agiammarchi:

Making it a blocker shouldn't prevent us to ship #6440 a part, since there is already a codereview in place and no need for specifications and/or UX studies, am I correct?

Correct, the idea is to get the UI into a workable state with #6440 so that we can then work on further optimizations independently.

Note: See TracTickets for help on using tickets.