flag to hide list item from UI #3

New Issue

k2s · 2022-06-18T13:16:24Z

k2s commented

2022-06-18 13:16:24 +00:00

We need Vikunja to support 100.000 and more list items.
Current UI is not able to handle 10.000 lists.
The list items will probably not have meaningful name

My idea is to have in list model flag to decide if this item is useful for UI.

We need Vikunja to support 100.000 and more list items. Current UI is not able to handle 10.000 lists. The list items will probably not have meaningful name My idea is to have in list model flag to decide if this item is useful for UI.

k2s added this to the Curo integration project 2022-06-18 13:16:24 +00:00

konrad commented

2022-06-18 17:38:08 +00:00

I think the proper way to handle this would be pagination. Right now, all lists are loaded into the browser, processed and then rendered in the UI which probably causes all the problems. Doing this with pagination would mean a few things:

We need a new solution for the sidebar menu - maybe only show the first 200 lists there + favorites and paginate everything in the "Namespaces & Lists" page, the same way we're currently handling tasks on a list?
Searching through lists via the gloabal search is currently done locally as well because that's faster. That would need to happen on the server as well.

I'm not even sure if there is a performant way to show that many lists at once so you'll probably need pagination either way.

I think the proper way to handle this would be pagination. Right now, all lists are loaded into the browser, processed and then rendered in the UI which probably causes all the problems. Doing this with pagination would mean a few things: 1. We need a new solution for the sidebar menu - maybe only show the first 200 lists there + favorites and paginate everything in the "Namespaces & Lists" page, the same way we're currently handling tasks on a list? 2. Searching through lists via the gloabal search is currently done locally as well because that's faster. That would need to happen on the server as well. I'm not even sure if there is a performant way to show that many lists at once so you'll probably need pagination either way.

k2s commented

2022-06-18 17:52:40 +00:00

In general, pagination would be good improvement.

For our needs I am sure we need the flag to disable list from UI:

I don't want to store persons (list items) details in Vikunja
I don't need search for parson by Vikunja
- search will be performed on Curo side and Vikunja will be asked to return tasks for set of lists
- if (still open if this will be needed) we will allow user to use Vikunja frontend, search by labes and date range will be most common and when rendering item, some HTML snipped (#5) will be requested from Curo and shown as part of ticket

@konrad Is the hide_from_ui flag something you see as a problem to add to the main branch?

In general, pagination would be good improvement. For our needs I am sure we need the flag to disable list from UI: * I don't want to store persons (list items) details in Vikunja * I don't need search for parson by Vikunja * search will be performed on Curo side and Vikunja will be asked to return tasks for set of lists * if (still open if this will be needed) we will allow user to use Vikunja frontend, search by labes and date range will be most common and when rendering item, some HTML snipped (#5) will be requested from Curo and shown as part of ticket @konrad Is the `hide_from_ui` flag something you see as a problem to add to the main branch?

konrad commented

2022-06-18 18:09:57 +00:00

I think a hide_from_ui flag takes away the "unopinionatedness" (if you can call it that) from the api. IMHO the API should not make assuptions about how its being used, therefore a ui flag would not feel like a good idea.

Even if likely more work than a simple flag the proper way to fix this problem would be paginating tasks I think. That way other people with a lot of lists would also benefit. A hide_from_ui flag needs to explicitely be set, pagination is implicit.

I think a `hide_from_ui` flag takes away the "unopinionatedness" (if you can call it that) from the api. IMHO the API should not make assuptions about how its being used, therefore a ui flag would not feel like a good idea. Even if likely more work than a simple flag the proper way to fix this problem would be paginating tasks I think. That way other people with a lot of lists would also benefit. A `hide_from_ui` flag needs to explicitely be set, pagination is implicit.

k2s commented

2022-06-18 18:57:46 +00:00

small objection to unopinionatedness :-) ... if there is already table favorites with column kind ... then it could be renamed to flags with added property type

where type could be favorite, hiden ... not most efficient for searching, but aligned how the UI favorite flag is stored

At this point I don't see pagination as solution for us, becasue our list title will not be meaningful for user.
I would like to have visible lists like personal, ambulance, ministry of health and then list per each patient in Curo without any personal data.

small objection to `unopinionatedness` :-) ... if there is already table `favorites` with column `kind` ... then it could be renamed to `flags` with added property `type` where `type` could be `favorite`, `hiden` ... not most efficient for searching, but aligned how the UI `favorite` flag is stored At this point I don't see pagination as solution for us, becasue our list title will not be meaningful for user. I would like to have visible lists like `personal`, `ambulance`, `ministry of health` and then list per each patient in Curo without any personal data.

konrad commented

2022-06-18 19:14:16 +00:00

At this point I don't see pagination as solution for us, becasue our list title will not be meaningful for user.
I would like to have visible lists like personal, ambulance, ministry of health and then list per each patient in Curo without any personal data.

Okay, I think I now understand better what you want to achieve.

I'm still not sure whether a flag like the one you proposed is the way to go here but maybe it's just the naming that bothers me.

> At this point I don't see pagination as solution for us, becasue our list title will not be meaningful for user. I would like to have visible lists like personal, ambulance, ministry of health and then list per each patient in Curo without any personal data. Okay, I think I now understand better what you want to achieve. I'm still not sure whether a flag like the one you proposed is the way to go here but maybe it's just the naming that bothers me.

k2s referenced this issue

2022-06-18 19:19:02 +00:00

external reference ID in list model #2

Sign in to join this conversation.