Improve attribute parser - #6
Merged
Merged
Conversation
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR improves the attribute parser and adds more tests around it.
The scenario
One major change is in how dynamic attributes are handled.
Previously, if you had a component like this:
Which internally looked like this:
When it got rendered, it was outputting:
The problem
When the dynamic attributes were swapped with placeholders, the value for
hrefwould becomeATTR_PLACEHOLDER_0.So then when the component is rendered by Blaze to fold it, the rendered version before placeholders were restored, was:
Now the issue is that when Blaze goes to restore the placeholder, because the
{{ }}that was around$urlpreviously has now been removed by Blade when it rendered$url, the attribute's raw value is being output in the HTML. Hence why we are getting<a href="route('dashboard')">.I know that the AttributeParser code is something that you mentioned could be improved. So I reviewed the
parseAndReplaceDynamics()method closely, I found that it was doing extra work that probably was unnecessary and it was also handling dynamic content in a couple of different ways depending on what the content was that probably wasn't needed.There was previously 3 different ways the value of a dynamic attribute could be handled.
""and stared with a$.For some reason it was handling both
:name="$name"and:name=$name, which I don't believe is valid in Blade anyway.We'd actually by passed that regex check by manually stripping the
""before processing, so it was now redundant and being skipped.This left two remaining conditionals.
$.In this scenario, presuming the first scenario was false, it would then take the attribute value and wrap it in
{{ }}.This meant that when the placeholder was restored in the HTML, if the dynamic value started with a
$like$foo, then it would be output as{{ $foo }}in the HTML.The problem with this final condition's strategy is that the content is dynamic, which means that it should be executed as PHP. But outputting the value directly without processing it means the raw PHP values will be output, which is unexpected and what is happening in the example above with the link component.
The solution
The solution in this PR is to wrap all dynamic attribute values in
{{ }}, to ensure it can still be rendered properly after the placeholders have been removed.I've also remove the handling for both
:name="$name"and:name=$name, which has simplified the code.Now there is no conditional logic as all dynamic attributes are handled in the same way.
I added some tests for the
parseAndReplaceDynamics()function too; and reviewed and cleaned up theparseAttributeStringToArray()function, that I added the other day, to match the changes inparseAndReplaceDynamics()as they both use similar logic.Note: The caveat for this change is that, now people can pass any dynamic attributes into the component, but the way they are used inside the component must just be a basic echo statement. Anything more complex and it will fail.
One other thing we're not handling is if it is echoed using
{!! !!}instead of{{ }}. I reckon we could add detection for this though if we wanted, but that will require inspecting the source of the component.