Cache the detail query to avoid page crashing after refreshing

[ansjcy]

Description

Currently the details page crashes after refreshing the page, because the corresponding query that is passed to the detail page won't be available after refreshing. Fixing this bug by adding the query to session storage. Also added several unit tests for the details page and refactored the code.

Issues Resolved

#12

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[derek-ho]

Pulled it locally and it works. From a high level I feel like this session storage approach has some downsides mainly:

• Complexity of involving session storage
• Cannot have a consistent/sharable URL (for example if I want to link a specific query for others to view, I cannot do that with this new approach)

@ansjcy What do you think of the above? If we have some UUID/can reconstruct the query from the hash only I think that would solve the above issues without introducing new concepts?

[derek-ho]

Pulled it locally and it works. From a high level I feel like this session storage approach has some downsides mainly:

• Complexity of involving session storage
• Cannot have a consistent/sharable URL (for example if I want to link a specific query for others to view, I cannot do that with this new approach)

@ansjcy What do you think of the above? If we have some UUID/can reconstruct the query from the hash only I think that would solve the above issues without introducing new concepts?

For more color on the above, what the usual paradigm we use for these specific detail UI pages would be to include a hash in the url, such as queryInsights/${UUID_of_specific_query}. Then on page refresh, the call can be made to fetch the details of that specific UUID. That way the page can be loaded without first visiting the list page, and this page can also be shared and loaded by anyone else with access to that query.

[ansjcy]

That make sense! We should use an UUID (maybe query hashcode?) instead of session storage.. This is a very valid use case.

That way the page can be loaded without first visiting the list page, and this page can also be shared and loaded by anyone else with access to that query.