Change search pattern across the application
Proposal
We should switch to a more traditional search pattern, where a user fills in a search form, the application queries the database, and returns a small set of results for the user to then take action against. For example, when directly adding people to a workshop, the admin would type a name into a search bar. They click 'search' and receive a list (or possibly just one) result. They click on the result and then take action.
Why this?
The application was originally built without realising how massive our chapters would get. As a result, we load hundreds of Member records into the frontend, and then filter them using javascript. This slows the application down and makes it really difficult to use for admins.
Why now?
We've got a small team set up around maintenance, and this would be a significant quality of life improvement.
(Near) shameless plug: A few years ago, I built plete a web component that can be used for this scenario :)
There are probably better solutions out there these days, but I thought it was an interesting coincidence.
I would prefer not adding more javascript if possible. I believe a more old-fashioned approach of thin client + thick controller is more in line with the current architecture
@jonodrew, could you provide some steps to reproduce, maybe with screenshots? That would make it much easier to understand where and what the issue is
I would say this is the best indication https://github.com/codebar/planner/issues/627#issuecomment-3146995408
This code is a good example: https://github.com/codebar/planner/blob/59bb8320c1c2a56cdddd6d99611a968d762d6e0f/app/views/admin/workshops/_invitation_management.html.haml#L19
We pull every member who's not accepted an invite. For some chapters that's hundreds. I think the better approach is to have a big button that says "Add a member to a workshop" and then go into a more old school search approach. I've popped a couple of ideas in that thread, from simple search to a directory for multi-add
This is being worked on in #2260