Add 'all' as default DID search type (#446)

[Haiderkhan64]

Modified DIDSearchPanel.tsx to add 'all' as a default DID search type. Introduced SearchType union to extend DIDType with 'all'. Updated onSearch to omit the 'type' parameter when 'all' is selected, allowing the API to fetch all DID types. Resolves #446.

Note: The API (/api/feature/list-dids) may need an update to handle queries without a 'type' parameter, as noted in the issue.

[maany]

Hey @Haiderkhan64 , was this issue discussed ? I believe we are not using 'all' to prevent database queries having to parse extremely large results.

[Haiderkhan64]

Hi @maany, thanks for the feedback! I implemented 'all' as the default DID search type per #446’s request to allow listing all DID types intuitively. I wasn’t aware of prior discussions about avoiding 'all' due to large result sets—my apologies if I missed that context.

To address this, would it be better to:

• Keep 'all' but add pagination or a limit to the query (e.g., via a limit parameter)?
• Revert 'all' as the default and make it an optional selection instead?
• Coordinate with an API update to handle large results safely?

I noted in the PR that the API (/api/feature/list-dids) might need adjustment to support queries without a 'type' parameter. Happy to adjust based on your guidance—let me know how to proceed!

[lobis]

Sorry to jump in, but have you considered using some kind of client caching mechanism to remember the selection of the DID type? I am frequently changing from dataset to file and this would really make usage more confortable, and I guess it would also partially address #446.

Would love to hear your thoughts on this @maany

[Haiderkhan64]

Hi @lobis and @maany,

@lobis, thanks for the suggestion! I agree that a client-side caching mechanism to remember the DID type selection would make the UI more comfortable, especially for frequent switches like 'dataset' to 'file'. I could add this using localStorage to persist the last selected type across page loads. It could complement the 'all' option or work independently to improve UX, partially aligning with #446’s goal.

@maany, I’m still awaiting your input on the large result set concern. Combining caching with 'all' (e.g., default to 'all' but cache the last choice, plus a limit parameter) might balance usability and performance. Alternatively, I can revert 'all' as default and make it optional, as I suggested earlier. What are your thoughts on @lobis’s caching idea, and how should I proceed with 'all'?

Let me know—I’m ready to update the PR accordingly!