[$150] Sorting the project list view should not reload the page if we have all the data

[vic-georgiev]

Expected behavior

Upon reaching the bottom of the grid, I want to reorder it by oldest first. I would expect the conversion to happen without reloading the page -- we have all the data already loaded. Also - changing the sort order should only pass new properties onto the components of the list instead of reloading the whole page -- data should be managed by the grid component and keep the state, pass props to the children components (row). We need to optimize the list view to be a better break down of components and managed components.

Actual behavior

A lot of the actions on the grid require reloading of the page. We can optimize the component architecture so that we can render the components faster and modify the properties with the data instead of reloading/rerendering everything.

[vikasrohit]

@vic-topcoder I think this would work only when we have less than page size records i.e. we have less than 20 projects to display for the user. Otherwise, we have any way call server to refresh the grid.

[vic-georgiev]

Calling the server is ok. Reloading the page to render the grid is not.

[vikasrohit]

If we make a call to server, we have to set a flag in redux state for showing the loading icon because the server call can take time to respond. And when we show the loading icon it unmounts the Grid and when we have the response back from api, we unmount the loading icon and mount the Grid back. So, you will always see the whole grid refresh. If we don't want to show loading icon, we may achieve this but that does not seem to be good user experience specially with low speeds.

[vic-georgiev]

I'd imagine you don't need to refresh the whole grid, just the rows. The header isn't changing, so ideally it won't reload. Also - we should preserve the space to avoid min height or size issues. We have an empty/loading state for rows currently, so I agree that we should show states representing state of the system.

[gondzo]

just to summarize, the tasks here are:

• remove the loading icon completely and use placeholder views - same as when loading more projects
• keep the header displayed at all times
• changing sort order should not reload the page (no api calls) if all the records are loaded
• the above should work with both grid and card view

[vic-georgiev]

Is there a reason to transmit only 20 project records at a time? What is the max data we can keep loading once a user is on a page? I would love if we optimize the data transferred between server and user especially when working with the grid all the time. Albeit this is done only from project managers/copilots, but it is a high frequency task and having most/all the data available would really help. I would defer canceled projects data as the most important ones are the active/reviewed/in review/

[vikasrohit]

@vic-topcoder We always try to load sufficient number of records from the database to reduce the load on database. Fetching all records is always going to be a costlier option and most of the time user does not access all of that data. Right now we have hard coded limit of 20 in API for the page size i.e. no one can request more than 20 projects per request. One more rationale behind putting a hard limit on API is to prevent any crawling or calls from custom tools (e.g. tools created by copilots or challenge architects to facilitate their routine work) from accidentally jeopardising the API backend.
Saying that, we can increase the upper limit of the page size to somewhere around 40-50, but I won't suggest allowing more than that.
Yes, having all projects available at all times is good for end user but that has another issue of updating that data when something changes on server which introduces more complexity to the infrastructure.

[vic-georgiev]

What I mean is - do we optimize the size of the call/packets for transferring the right amount of data? 20 projects isn't always enough, I would be happier if we increase the limit to 50. Do we know what is the burden on loading more data (less calls) vs. more requests (calls)?