[FEATURE] Data list overrides

[esmeetewinkel]

What?

• Longer term ideally we want a system where anything (including data lists) can be overwritten at runtime, however it will only make sense to implement once we have a single system that handles loading data (otherwise it means a lot of copy-paste for templates, data lists, and any other flow type). This is part of what is proposed with other issues related to integrating json instead of ts files

• Additionally, because these datalists are statically defined we could also integrate a system that replaces files during compile so that only the relevant datalist ever makes it into the app. This would be quite easy to do once we've integrated pr Feat/deployment workflows #1210 (moved to [FEATURE] - Deployment multiple gdrive folders #2081)

Other details
See also issue #1261

[esmeetewinkel]

@chrismclarke Can we close this considering the work that went in on data items, or would you say this is something different?

[chrismclarke]

I think it might still make sense to have long term so that data lists can be overridden in the same way that templates are (e.g. theme/language-dependent data lists, instead of relying on templates to know all the variations). So I'd say keep open for now, but low priority

[jfmcquade]

@ChrisMarsh82 @esmeetewinkel This relates to your discussion

[ChrisMarsh82]

@chrismclarke How difficult would this be to do? I was hoping for the facilitator to have all the same templates but have overwritten data_lists for each deployment.

[chrismclarke]

I tried giving a quick go in #2040, although a few extra threads started to unravel and I didn't have time to finish. Will keep you updated as I progress (would guess about a half day's work if I can find the time)

[chrismclarke]

As a quick update most of the backend code is in place, however the frontend code is a bit more tricky as most of the logic that handles dynamic variables (e.g. @field.some_field) is tightly coupled with the templating system and requires significant refactor to generalise.

I've started work on the refactor and I think the code is about ready for test/review, however will likely wait until more of the current backlog of PRs is merged as quite prone to conflict (particularly #2019, #2035 and #2041)

[chrismclarke]

Close first point with #2040 and move second to #2081