I have noticed a potential inconsistency in the query editor's user interface regarding how data types are displayed for Eval fields. Currently, when an Eval is created, the interface displays a data type label that seems to be hardcoded to the primary source field rather than reflecting the final output of the transformation chain. For example, if I create an Eval based on a text field but then apply a filter that transforms the output into an integer or a boolean, the UI continues to display the text type instead of updating to show the actual resulting type. This behavior is misleading because it suggests the output is one type while the underlying XanoScript engine is correctly processing it as another, which can lead to confusion and unnecessary manual type-casting when users try to build subsequent logic based on those visual hints. I believe the editor experience would be significantly improved if the interface performed a basic analysis of the filter chain to dynamically update the Eval's type metadata, ensuring that what the developer sees in the builder accurately represents the final data structure that will be returned by the query.
Example: "distance" is not a "geo_point" (is a "decimal"), and "empty" is not a "integer" (is a "bool")
FA