(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #1) > possibly a simple checkbox to "show all subtests" ? Yes, I like this idea. > FYI - the performance/summary endpoint is currently designed to query for either tests or subtests, not both (this is for performance reasons). If you want to see subtests for multiple tests, you'd need to modify the parent_signature param here in order to accept multiple parent_signatures (assuming this is performant - otherwise it'll be n queries for each tests' subtests), and then the query would need to occur after the initial queries on the compare view resolves in order to get the parent signatures. Indeed, these are the main aspects to consider when implementing this. Basically, chain some promises that'll request from this API. First promise will fetch the big tests. Then, if the "show all subtests" checkbox is checked, we'll requests from the same API *(with different params)* in digestable batches, until we go through all the big tests. Maybe 2-3 big tests at a time. In terms of UX, showing some spinning wells under the big tests will let the user know the UI is still waiting for being fully loaded.
Bug 1316590 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #1) > possibly a simple checkbox to "show all subtests" ? Yes, I like this idea. > FYI - the performance/summary endpoint is currently designed to query for either tests or subtests, not both (this is for performance reasons). If you want to see subtests for multiple tests, you'd need to modify the parent_signature param here in order to accept multiple parent_signatures (assuming this is performant - otherwise it'll be n queries for each tests' subtests), and then the query would need to occur after the initial queries on the compare view resolves in order to get the parent signatures. Indeed, these are the main aspects to consider when implementing this. Basically, chain some promises that'll request from this API. First promise will fetch the big tests. Then, if the "show all subtests" checkbox is checked, we'll request from the same API *(with different params)* in digestable batches, until we go through all the big tests. Maybe 2-3 big tests at a time. In terms of UX, showing some spinning wells under the big tests will let the user know the UI is still waiting for being fully loaded.
(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #1) > possibly a simple checkbox to "show all subtests" ? Yes, I like this idea. > FYI - the performance/summary endpoint is currently designed to query for either tests or subtests, not both (this is for performance reasons). If you want to see subtests for multiple tests, you'd need to modify the parent_signature param here in order to accept multiple parent_signatures (assuming this is performant - otherwise it'll be n queries for each tests' subtests), and then the query would need to occur after the initial queries on the compare view resolves in order to get the parent signatures. Indeed, these are the main aspects to consider when implementing this. Basically, chain some promises that'll request from this API. First promise will fetch the big tests. Then, if the "show all subtests" checkbox is checked, we'll request from the same API *(with different params)* in digestable batches, until we go through all the big tests. Maybe 2-3 big tests at a time. In terms of UX, showing some spinning wheels under the big tests will let the user know the UI is still waiting for being fully loaded.
(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #1) > possibly a simple checkbox to "show all subtests" ? Yes, I like this idea. > FYI - the performance/summary endpoint is currently designed to query for either tests or subtests, not both (this is for performance reasons). If you want to see subtests for multiple tests, you'd need to modify the parent_signature param here in order to accept multiple parent_signatures (assuming this is performant - otherwise it'll be n queries for each tests' subtests), and then the query would need to occur after the initial queries on the compare view resolves in order to get the parent signatures. Indeed, these are the main aspects to consider when implementing this. Basically, chain some promises that'll request from this API. First promise will fetch the big tests. Then, if the "show all subtests" checkbox is checked, we'll request from the same API *(with different params)* in digestable batches, until we go through all the big tests. Maybe 2-3 big tests at a time. In terms of UX, showing some spinning wheels under each big test will let the user know the UI is still waiting for being fully loaded.