Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST]: Alternative to slots that evaluates state inputs at execution time but uses existing template engines to allow more flexibility #66136

Open
lorengordon opened this issue Feb 23, 2024 · 0 comments
Labels
Feature new functionality including changes to functionality and code refactors, etc. needs-triage

Comments

@lorengordon
Copy link
Contributor

Is your feature request related to a problem? Please describe.
I want to love the slots feature, but the current implementation is very limited and the custom parsing is prone to odd bugs. For example, as of this writing, the append feature doesn't even work as documented, because the parsing breaks when there are spaces around the ~.

Instead of trying to create some whole new language syntax and parser for slots, the idea I had was to evaluate state inputs at the point the state is executed, same as slots, but using existing templating engines. Only difference would be customizing the template syntax to distinguish between load-time templating and execution-time templating.

Describe the solution you'd like
Using jinja as an example, where we use {{ ... }} to have jinja render a template value at load time, specify an alternative syntax such as &{ ... }& that still renders the contents with jinja but does so at execution time. This would allow all Jinja syntax, functions, filters, etc within the rendering block. We would get things like "append" just as a builtin feature of the templater.

I'm not sure what the real feasibility or difficulty of this might be. But some kind of powerful and flexible run-time evaluation would be an amazing feature. Slots just are not good enough as is. Nice part of this approach is that it would be backwards-compatible with current slot syntax, and migrating would be fairly straightforward.

@lorengordon lorengordon added Feature new functionality including changes to functionality and code refactors, etc. needs-triage labels Feb 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature new functionality including changes to functionality and code refactors, etc. needs-triage
Projects
None yet
Development

No branches or pull requests

1 participant