Skip to content

[FEATURE] Named Slots #1118

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

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

[FEATURE] Named Slots #1118

wants to merge 1 commit into from

Conversation

s2b
Copy link
Contributor

@s2b s2b commented Jun 25, 2025

This patch enables Fluid's components to accept multiple slots. Each
slot is identified by a name argument. The corresponding
<f:fragment> ViewHelper can then be used to fill the slots of a
component.

The available slots of a component are now also exposed properly
via the ComponentDefinition DTO. Unfortunately, the TemplateParser
fails to propagate available slots of the current templates consistently to
the ParsingState, which currently leads to ugly state merging within the
parser. Hopefully, this issue can be addressed in the future to remove this
workaround, which has been documented in the code.

For this first implementation, we limit the usage if the new
<f:fragment> ViewHelper to the context of components. However, we
might expand this ViewHelper to other areas in Fluid, such as a way to
partially extend/overwrite templates.

Resolves: #1109

@s2b s2b force-pushed the feature/namedSlots branch 4 times, most recently from 6fb787a to e40ff6d Compare June 25, 2025 18:46
@s2b s2b marked this pull request as ready for review June 25, 2025 18:46
@s2b s2b force-pushed the feature/namedSlots branch from e40ff6d to e3d8cff Compare June 25, 2025 18:47
@s2b s2b changed the title Feature/named slots [FEATURE] Named Slots Jun 25, 2025
@s2b s2b force-pushed the feature/namedSlots branch from e3d8cff to f27eb1b Compare June 25, 2025 18:51
This patch enables Fluid's components to accept multiple slots. Each
slot is identified by a `name` argument. The corresponding
`<f:fragment>` ViewHelper can then be used to fill the slots of a
component.

The available slots of a component are now also exposed properly
via the `ComponentDefinition` DTO. Unfortunately, the `TemplateParser`
fails to propagate available slots of the current templates consistently to
the `ParsingState`, which currently leads to ugly state merging within the
parser. Hopefully, this issue can be addressed in the future to remove this
workaround, which has been documented in the code.

For this first implementation, we limit the usage if the new
`<f:fragment>` ViewHelper to the context of components. However, we
might expand this ViewHelper to other areas in Fluid, such as a way to
partially extend/overwrite templates.
@s2b s2b force-pushed the feature/namedSlots branch from f27eb1b to c6f4967 Compare June 25, 2025 20:39
@Kanti
Copy link

Kanti commented Jun 26, 2025

Possible Validations:

  1. If f:fragment is used but f:slot is not, it should trigger an Exception and notify the Developer that the slot is not defined.
  2. If f:slot is used but no matching f:fragment is used it should also trigger an Exception. (if the slot is not optional)

@s2b
Copy link
Contributor Author

s2b commented Jul 7, 2025

TBD: <f:fragment name="..."> or <f:fragment slot="...">?

@s2b
Copy link
Contributor Author

s2b commented Jul 17, 2025

TBD: <f:fragment name="..."> or <f:fragment slot="...">?

Since f:fragment might be useful in other contexts later, it's probably better to use the more generic name.

@s2b
Copy link
Contributor Author

s2b commented Jul 17, 2025

Possible Validations:

  1. If f:fragment is used but f:slot is not, it should trigger an Exception and notify the Developer that the slot is not defined.

Unfortunately, this would be a breaking change:

  1. ComponentDefinition currently returns a list of available slots of a component. If the underlying provider is unable to provide that information, it would need to return []. That would mean that those components wouldn't be able to receive any slot content as this would always result in an exception.

  2. Existing components that fill the default slot but don't use it would trigger an exception.

I've created issue #1134 with the "breaking" label.

  1. If f:slot is used but no matching f:fragment is used it should also trigger an Exception. (if the slot is not optional)

I don't think that we should do that. <f:slot> both defines and renders a slot, so it's possible that the definition is nested within an <f:if> or similar. So it should always be assumed that slots are optional and default to an empty string. This is also how frontend frameworks deal with slots.

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.

Named Slots
2 participants