How does reskit need to be structured in order to better support outputs app user behaviour?

[francisbarton]

If this matters at all - that is, if there is any significant performance difference in behaving a certain way.
It may be that it doesn't make any significant difference to outputs app performance, in which case reskit can just be structured in whatever way is most convenient.

At the moment, reskit provides umbrella 'compile_*' functions for data preparation for each table and chart.
These functions allow the user (where relevant) to specify an activity type, a measure, a selection of "pod"s, and so on.

Current behaviour: Run compile function with all parameters

1. Pull the relevant table(s) from a 'results' object
2. Run initial part of data preparation process
3. Filter to default, or selected, activity type, measure, pod(s) and site(s).
4. Complete data preparation process, including calculation of totals etc
5. If the user selection of parameters changes, start again from 1

Potentially better behaviour?

1. Pull the relevant table(s) from a 'results' object
2. Run a complete data preparation process, providing a "full" prepared table
3. Filter to required activity type, measure, pod(s) and site(s), as selected by user
4. Resummarise / recalculate totals etc ?
5. If the user selection of parameters changes, start again from 3.