Currently, the Subscriptions Grid contains a feature where it will cache the current state of the filters, fields, sort, and scroll position when navigating between App Details as well as a couple other places.
This behavior is unique to the Subscriptions Grid because that grid is not on the new grid framework. It currently is also done is a poor way that is not technically scalable or performant.
A requirement for the Owners project is to introduce the ability to bulk edit on the Subscriptions Grid. To do so, we must migrate the Subscriptions Grid to the new grid framework.
As it stands, the new grid framework does not have caching functionality. This means we either have to build some sort of caching functionality into the new grid framework or come up with an alternative solution.
This solution requires us to build out a new caching system within the new grid framework. This was the original idea, but comes at a high cost. After doing some research Law, Jeremy, and myself have come to the conclusion that because of the complexity, edge cases, and re-architecture that would need to be done it will take about a month to build out.
The way this cache would behave is that for every top-level grid (Subscription, Payments, Team, etc) on the new grid framework it would save the configuration of the filters, fields, sort, scroll position, etc. when navigating to a child of that grid. Then when the user navigates back to the top-level grid we could pull that cache and re-render the grid in the state of that saved cache.
Some things we still would need to figure out:
- Currently the Subscriptions Grid is cached when navigating to Suppliers/Multi-Org, would we need to do that? (I think no)
- No devation from current UI behavior
- Fixes caching on all framework grids and any future grids
- Solution could take up to a month, which stalls progress on bulk editing / subscription grid conversion
- Could lead to a slew of bugs given the fact that each grid has it's own unique set of filters and columns
- Net new solution that has not been implemented before, so there's no existing logic we can leverage
- Bloats memory storage on the front-end, which could lead to decreased performance
- Maintaining such a complex peice of functionality long term would be difficult and likely will be prone to bugs.
- Defining when to cache and the exact pattern for caching could get tricky and prone to inconsistencies.
- It likely will only become more cumbersome the more we add to the grid framework.
In this experience, instead of taking a user directly to the Detail View of the row, it would open a side panel that would give a slightly condensed view of the details of the row with the ability to edit (if allowed). Something similar to the left sidebar in App Details.
This panel would live along side the grid in the interface so that you could scroll both in the grid and side panel. If you click a different row in the grid that Subscriptions details would replace the side panel.
An option would be provided to expand the side panel into a full detailed view where we provide all of the information currently on the full detailed view (think of App Details, basically all of that).
The "Back to Subscriptions" link would close the details view and place the user back at the same grid they were looking at before.
In this solution, we would be removing caching as we know it today while reusing some of our existing functionality to create a cache-like system.
- Solution would likely take less time than the caching solution and would provide some new functionality
- Circumvents caching issue since the orginal grid is still behind the side panel / modal
- Probably no net new components, which greatly speeds up development
- Faster navigation experience to get back to main grid
- Solution is not blocked by subscription grid conversion
- Gives the user the ability to edit a filtered set of data individually without leaving the page
- Fairly modern UX seen in many popular online applications
- Differring behavior from current navigation. Not sure how end users would react to this change
- Likely needs to be user tested before it is implement
- Side panel will not be as detailed as the actual App Details, but could have an overlay with full details
- Mock ups do not exist and will have to be created and agreeed upon before development begins
- This is still a relatively new idea, we don't have much in terms of designs or user research.
Cache me outside, how bout dat.