Pagination support for proteins and condensates table

Pagination is needed for the table view.

added front-end + 1 deleted label

@sghosh There are several features are disabled if we are using server side pagination.

1. Remove filter: the server side logic does not support local filter e.g. "dro" cannot give all the "*dro*". The datatable local filter does so. You can provide local filter in addition to query.
2. Sorting by "The number of proteins": this is not possible unless the server api contains it as a field. This affects the sorting by evidence stars. Sorting by score is not possible unless the score field is actually provided in the server api.

If you want to insist on the server side pagination, I can implement it but the flexibility will be limited until you implement those requirements. Let me know which you prefer.

Yes, you are correct here. Let me think about this and get back to you.

added api discussion + 1 deleted label

assigned to @sghosh

Hi @moon I have added the number of proteins as a field in the APIs. So, now you get this as an integer field protein_count in Condensate List API and also Protein Details API (condensates in this have protein_count instead of a list of proteins)

For the filtering part, I think the local filter can be removed from both the list pages (proteins and condensates). In these cases, the API query should be enough (or will be improved over time). And for the local tables on details page (condensates table in protein and proteins table in condensate), you can keep the local search here since the whole table data can be retrieved in one API

@sghosh I am currently implementing pagination for protein datatable because the loading time is too long. Could you add the option of Functional Type flag in dd-code-api? Currently functional type filtering is done in the client side. https://dev.ddcode.org/proteins

The option would be ['', 'client', 'driver', 'null', 'regulator'] '' means all items whereas 'null' is unknown.

I think this filter is already there. Can you try once?

Yes, you already made it. Thanks! By the way, is there any way to check all the functional_type values? ['', 'client', 'driver', 'null', 'regulator'] is statically coded currently. How would we handle if there are another type added?

As of now, from the database end, only 4 values are possible ['client', 'driver', null, 'regulator']

I don't think in the near future another possible value will be added. In that case, we might have to again statically code them. But I doubt that will be the case.

closed