Skip to content

Fix attributes after with multi-word props #1625

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

joshhanley
Copy link
Member

@joshhanley joshhanley commented May 23, 2025

The scenario

Currently if we have a component within another component, we can forward attributes to the inner component using a prefix. For example if we call the table component, we can pass props to the paginator component like this:

<flux:table paginator:preserve-scroll>

But if the preserve scroll prop is defined as camelCase inside the paginator component, and the prop is passed in using kebab-case then the value isn't being forwarded properly.

@props([
    'preserveScroll' => false,
])

If we use camelCase when calling the table component though, it works happily.

<flux:table paginator:preserveScroll>

The problem

When attributes are forwarded like that, under the hood, Laravel tries to detect if there are any props defined in the attribute bag, and if they are, it sets the values and removes them from the attribute bag.

But, the way it does it, is it looks to see if the prop name (with the casing as defined in @props), for example preserveScroll is in the attribute bag.

The issue is that what is in the attribute bag is actually preserve-scroll, so when Laravel looks up preserverScroll it can't find it.

This problem has been raised here laravel/framework#48956

And attempted to be fixed here laravel/framework#48983
And here laravel/framework#49146

But it hasn't been accepted.

The solution

The solution is to implement a fix internally. When we extract the attributes that should be passed on to the nested component, we can just ensure there is a camelCase version of that attribute/ prop name so Blade matches it correctly and filters it out of the attributes.

I also did a check to make sure that the props are correctly filtered out of the attribute bag, due to now having both naming schemes in the attribute bag, and it does.

But I just realised as writing this out, that filtering only happens for matching prop names, so there will still be a double up of normal attributes with both cases. 😕

image

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.

1 participant