Fusion scope (alternative to @context)

Using Neos & Flow
1

Hej,

I have a somewhat basic question about fusion and variable scopes.

Example:

prototype(Some.Package:Content.Example) < prototype(Neos.Neos:ContentComponent) {
    myColor = 'red'

    someClasses = Neos.Fusion:Join {
        something = 'some-class'
        
        // How to access myColor here?
        color = ${myColor}

        @glue = ' '
    }
}

If i defined a variable (“myColor” in this case). How can I access it from objects defined below the current object (“someClasses” in this case)?

The only solution I found was using @context like this:

prototype(Some.Package:Content.Example) < prototype(Neos.Neos:ContentComponent) {
    myColor = 'red'
    @context.myColor = ${this.myColor}

    someClasses = Neos.Fusion:Join {
        something = 'some-class'
        color = ${myColor}

        @glue = ' '
    }
}

Is there another to access “myColor” way without “polluting” @context?

Regards
Leif

2

Hi,

the “Nested Components” pattern could help here:

prototype(Some.Package:Content.Example) < prototype(Neos.Neos:ContentComponent) {
    myColor = 'red'
    
    renderer = Neos.Fusion:Component {
        // Forward props
        @apply.props = ${props}

        someClasses = Neos.Fusion:Join {
            something = 'some-class'
            color = ${props.myColor}

            @glue = ' '
        }

        renderer = ...
    }
}

This basically allows you to add a layer in between your public component API and the props that the final renderer is going to receive.

3 Likes
3

Hi Wilhelm,

thanks for you suggestion. I might use this pattern in the future. I like the idea of a public API.

That being said: It was more a general kind of a question. Is it possible to access the “parent object” or can I pass a variable to a direct child?

If @context is the way to go, I am fine with that. It just feels a bit strange.

Regards
Leif

4

You cannot access the parent because all Fusion sub pathes can be evaluated separately so the parent may not be present at all while a path is evaluated.

That is why @context is the way to influence rendering of subpathes when passing values directly is not an option.

BTW: That also is the reason why you have to configure which parts of the context is important in @cache annotations since those will be restored every time the path is eventually rendered.

5

Ok, thanks for these explanations.