Feat: data query

[chrismclarke]

PR Checklist

• PR title descriptive (can be used in release notes)

TODO

Core

• Fix broken test
• Add support for actions (e.g. data_changed trigger)
• Review sort authoring (likely inconsistent with items/data_items)
• Add tests
• Create standalone component demo for included markdown row type (split PR?)

Documentation

• Add PR demo
• Add general documentation
• Update RFCs

Future Follow-up

• Consider ways to make fully 'headless' components (no UI rendered but templating lifecycle still available)
• Improve styling of markdown component (expose to theming system)
• Extend system to allow authors to define queries in a query_list (or similar) that run in the background and persist to fields (would require changes to how templates manage change-detection and re-render if field updates from outside of template)

Description

Main Changes
Add new data_query row type used to extract single data rows via querying and store to local variable

Component Sheet: component_data_query

Additional Changes
Create additional markdown row type used to directly render markdown with styling. This is more useful for things like tables or code blocks, which will be mostly unstyled when rendered within a text or other component.

Add support for storing parameter_lists within data_lists in the correct format. This should also make it possible to refer to a different data ref to populate a row's parameter_list, reducing the need for copy-paste. e.g.

type	parameter_list
button	@data.some_data.some_row.parameter_list

Author Notes

This deviates somewhat from the existing RFC, opting to provide an inline syntax for creating local data_query rows instead of global queries.

The RFC will be updated accordingly once syntax finalised,

Review Notes

Dev Notes

In order to provide a ref for pulling in a data_query from an external source (e.g. data_list), I realised that data_lists would also need to make sure they process columns such as paramter_list in the same way as template. Hence the minor refactor to move parameter_list processing to the default parser. I don't anticipate this having any major knock-ons (not aware of people using parameter_lists in data_lists), but any diffs should show up following git sync (hard to review at the moment as debug content sheets currently outdated with git)

The only other potential knock-on comes from the changes made to template-variables.service.ts. I noticed it wasn't easily possible to pass json data from a data_list into a component directly (I think we have various component-level workarounds to manage things like processing lists). When trying to import a parameter_list column from the data_list into the template row it would try use the evaluated data as a key to replace, resulting trying to assign values such as { [{key: value_1}] : true} (which in console logs read {"[obj obj]": true} instead of spreading the object into the value {key : value_1}.
Again, I don't think this is something that we try to do anywhere else, so wouldn't expect the changes to have any knock-ons.

One of the major challenges with implementing the querying system is handling mapping from JS logical operators to the syntax used by RXDB. I actually just threw the challenge at AI (using Gemini 2.5 flash) and I think it seemed to handle the immediate cases I had, but would appreciate a second pass on the code and tests to see if looks reasonable.

The markdown component addition was more just to provide an easier way in the component demo to display proposed authoring in a table format. I noticed the default markdown parser that gets called in components like text doesn't include any styling for things like tables or codeblocks, and couldn't find a good way to pass without interrupting the text component styles. So I think having a dedicated component makes sense to handle these types of cases, although again I just used AI to supply a broad list of styles so could do with some refining in the future (deciding what we do/don't want to couple more tightly with theming system) - I think likely this could be a follow-up issue as wouldn't really impact the rest of this PR

Git Issues

Closes #

Screenshots/Videos

If useful, provide screenshot or capture to highlight main changes

[chrismclarke]

@ChrisMarsh82 - is it still on your radar to give a first pass at this? I sent a couple reminders on mattermost both in April and May so just want to make sure it doesn't fall between the cracks

[ChrisMarsh82]

@chrismclarke I did have a brief look at this but thought it would be better to get the updating variables out of the way before revisiting this as I feel that is an underlying structure change that could effect this.
On the bits I did look at it looks good but I thought it would build on our existing data_items with similar syntax. This looks like it is quite different. Do you see this running along side our existing system or replacing it?