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

[4.x] Antlers: Allow number literals inside variable bindings #9503

Merged
merged 1 commit into from
Feb 12, 2024
Merged

[4.x] Antlers: Allow number literals inside variable bindings #9503

merged 1 commit into from
Feb 12, 2024

Conversation

JohnathonKoster
Copy link
Contributor

This PR removes an existing papercut by allowing number literals inside Antlers parameter variable bindings. Currently, it is difficult/non-obvious on how one should go about passing a numeric value to a tag, as normal parameters are converted to strings:

{{ my_tag param="1234" }}

We can now simply use variable binding syntax to pass along the numeric literal:

{{ my_tag :param="1234" }}
{{ my_tag :param="-1234" }}
{{ my_tag :param="1234.56" }}

The current behavior would treat the numeric literal as a variable name, which is invalid, and always end up returning null, so I don't see this is as a breaking change. This PR does not automatically cast numeric values in all other situations since that would be a breaking change:

The following will remain a string value:

{{ my_tag param="1234" }}

The behavior of the following has not been changed, as it is possible for tags to start with numbers:

{{ my_tag param="{404}" }}

@jasonvarga jasonvarga merged commit e6599bb into statamic:4.x Feb 12, 2024
19 checks passed
@jasonvarga jasonvarga deleted the antlers-easer-way-to-pass-numbers-in-parameters branch February 12, 2024 14:52
@aerni
Copy link
Contributor

aerni commented Feb 19, 2024

I believe this is a breaking change.

I've got this Antlers code:

{{ partial:components/section_header
    :eyebrow="block:header:eyebrow"
    :title="block:header:title"
    :text="block:header:text"
}}

Before this update, the dump inside this partial looked like this:
CleanShot 2024-02-19 at 16 10 12@2x

After this update, the dump looks like this:
CleanShot 2024-02-19 at 16 11 32@2x

This is the header data:
CleanShot 2024-02-19 at 16 14 02@2x

@aerni
Copy link
Contributor

aerni commented Feb 19, 2024

Using the {} syntax instead of : works:

CleanShot 2024-02-19 at 16 15 54@2x

@aerni
Copy link
Contributor

aerni commented Feb 20, 2024

@JohnathonKoster tracked it down to be related to PR #9499 and not this PR at all. Fix is incoming. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants