[mustache_template] Adds onMissingVariable to support custom rendering for unresolved variable tags#11403
[mustache_template] Adds onMissingVariable to support custom rendering for unresolved variable tags#11403vlidholt wants to merge 1 commit intoflutter:mainfrom
onMissingVariable to support custom rendering for unresolved variable tags#11403Conversation
…ing for unresolved variable tags.
There was a problem hiding this comment.
Code Review
This pull request introduces an onMissingVariable callback to the mustache_template package, allowing for custom rendering or fallback values when variable tags are unresolved. The changes include updates to the Template interface, the internal Renderer logic to support the callback, and the addition of a MissingVariableContext class to provide metadata such as template name and source offset. The package version is bumped to 2.1.0, and comprehensive tests have been added to verify the functionality in both strict and lenient modes. I have no feedback to provide.
Please see the repository README. (We wouldn't require issues as part of the template if we didn't have an issue tracker.) Please do file an issue and expand there on the reason for the proposal. We generally don't want to expand the API surface of this package, and it's not clear from the PR description why a client wouldn't be able to provide values for template variables in advance. |
|
(Marking as a draft pending an issue where the feature request is discussed and evaluated in more detail.) |
|
Thank you @stuartmorgan-g, I missed where to place the issue. I have now created an issue in the Flutter repo, which is linked in the PR description. |
There was a problem hiding this comment.
Code Review
This pull request updates the mustache_template package to version 2.1.0, introducing an onMissingVariable callback to the Template rendering methods for custom handling of unresolved variables. The implementation includes the new MissingVariableCallback and MissingVariableContext types, along with corresponding updates to the Renderer and a comprehensive test suite. Feedback suggests that the htmlEscape property in MissingVariableContext should be modified to account for the template's htmlEscapeValues setting in addition to the tag's escape status.
| templateName: templateName, | ||
| source: source, | ||
| offset: node.start, | ||
| htmlEscape: node.escape, |
There was a problem hiding this comment.
The htmlEscape property in MissingVariableContext should accurately reflect whether the rendered output will be HTML-escaped. Currently, it only considers node.escape (whether the tag is {{var}} vs {{{var}}}), but it should also account for the htmlEscapeValues setting of the template. If htmlEscapeValues is false, no escaping is performed regardless of the tag type.
| htmlEscape: node.escape, | |
| htmlEscape: node.escape && htmlEscapeValues, |
Issue for this feature lives here:
flutter/flutter#184452
This is an addition to the
mustache_templatepackage. It adds aonMissingVariablecallback to the render methods. This allows the user of the package to dynamically handle template variables that aren't predefined. This can be useful in a variety of cases.New
renderStringsignature:Usage:
Example use cases:
{{image.avatar.128.128.webp}}{{date.createdAt.yMMMd.en_US.utc}}{{money.total.USD.en_US.2}}{{class.button.primary.large}}{{route.userProfile.42.settings.mobile}}{{icon.warning.red.24.filled}}{{cdn.heroBanner.dark.2x.webp}}List which issues are fixed by this PR. You must list at least one issue.
This repository does not have issues enabled.
Pre-Review Checklist
[shared_preferences]///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2