[interpreter] evaluate returns [object Object] as a string
tmarsik42 opened this issue · comments
Describe the Bug
Evaluate returns an object as a string
Steps to Reproduce
Expected Behavior
returned object like in feelin's evaluate or properly stringified
Environment
- Library version: 1.1.0
I see, well this is an interesting one for sure. I mean I know why it's doing that, but we need to think about what the appropriate behavior should be here. After all, feelers is a text templating tool, with also the ability define your text from as a simple feel expression. By design it only outputs strings.
The easy first part is, we should JSON stringify objects no matter what. It makes sense that someone might want to display the object itself as part of a template.
Second thing, only vaguely related but we need to stop functions definitions from rendering. They really should error.
Now for the somewhat challenging part. How do we allow users the freedom to stringify inline and expanded? Configurations are good but limited to the global scope, so that wouldn't allow mixes of inline and tabbed objects when writing templates. It would be sufficient for feel itself though.
Another approach we could take, would be to create helpers for stringification within feelers. This is more work and maybe a bit harder to figure out for users.
@nikku Any thoughts on this general topic?
After all, feelers is a text templating tool
@Skaiir I share your assessment.
[functions] really should error.
Considering FEEL basic null safety I think they should produce null, not error.
To sum up my rationale:
(1) we should produce strings wherever we inject the results of an expression into the host language
(2) the user may not explicitly cast the values to strings, but we want to be forgiving
(3) I hence propose to wrap any FEEL output into a string($$USER_INPUT) expression. This ensures that we return null for everything that is not natively stringifyable in FEEL, and otherwise returns the FEEL string() representation. Note that I refer to string(), the FEEL built-in function here.
What do you think?
Sorry I misspoke on the functions, you're right we should get null out of that 👍. It's a nice solution actually, that way we can at least follow something non-arbitrary, the feel implementation itself.
@tmarsik42 This gives you a simple workaround for the time being, stringifying within the feel expression instead of outside of it.