Qute - should a tag template be executed in isolation?

[mkouba]

Currently, a tag template can reference data from the parent context. However, it might make sense to disable this behavior and execute the tag as an isolated template, i.e. without access to the context of the template that calls the tag. There is a PR #22003 where the _isolated argument was added to control the behavior.

However, we're not entirely sure whether the default behavior should be changed as well, i.e. execute the tag as an isolated template by default.

The main disadvantage of the current behavior is that if an argument is not overriden on the call site a value from the parent context may unexpectedly leak to the rendered tag:

{! myTag !}
Name: {name}

and

{! parent template !}
{#let name='Foo'}
   {#myTag name='Bar' /} -> renders Name: Bar 
   {#myTag /} -> renders Name: Foo
{/let}

AND AFTER THE CHANGE:

{! parent template !}
{#let name='Foo'}
   {#myTag name='Bar' /} -> renders Name: Bar 
   {#myTag /} -> failure or NOT_FOUND
{/let}

OTOH the current behavior may come in handy in some situations. Also it would be a breaking change - although it was not documented before and it would not be the first one and definitely not the last one ;-).

[gastaldi]

I like the current behavior. It seems that are a few use-cases where isolation may be useful compared to not isolated, so IMHO we're good :)

[FroMage]

I strongly think we should model tags and scoping after what the Quarkus users are most used to, which is Java and lexical scoping. It's very confusing and error-prone to access data that doesn't come from the current scope, because copying one tag from one place to another might yield different results that are hard to understand. Also it's contradictory with the idea of passing parameters to it. And last, it pretty much breaks tag parameter declaration and type-safety.

[maxandersen]

I prefer explicit over implicit here but I can also see how it can be annoying having to pass every parameter through.

How about having syntax or explicit parameter to be able to pass the current template state to the next ? Like call in the same scope but be explicit about wanting that behavior ?

If not I'm on same side as step to make state scope/access explicit.

[FroMage]

Yeah, OK, I still don't see how it can be useful, but if we had syntax in the tag to specify that it wants access to stuff that's outside of it, that's where I'd put the flag, because it can already declare its parameters, it might as well declare that it's using the Eye of Sauron to see undeclared stuff.

[maxandersen]

The time when I see the ability to access the outside scope is the exact reason I add methods to a class - to access/share state without having to pass it around constantly. In that case, one views the templates as "methods" on a shared state object rather than 100% standalone templates.

I think this is common (but not necessarily majority). Also, it doesn't help on type-safety, so I'm still more inclined to say default is isolated, and optionally at call point, you can basically pass "this" into the call. come to think of it - kind of how Python does classes :)

[mkouba]

So the user tags were not designed to be "standalone" templates alhough they can be used like this. I think I mentioned this already but the original idea was to introduce named includes and it was documented this way: "User-defined tags can be used to include a template and optionally pass some parameters". And I think that in the template world it makes sense, that an included template has access to the data from the parent scope.

Also, it doesn't help on type-safety, ...

I don't get this argument about type-safety. Right now, an author of the tag should define the parameter declarations for all expressions that should be validated during build. The fact, that a variable name comes from a parent scope or is a user tag param, is irrelevant. Ofc, we can do better and try to add some "call site validation" like we have for @CheckedTemplate but we're not there yet and I'm not quite sure it's doable... need to find some time to analyze the possibilities.

and optionally at call point, you can basically pass "this" into the call. come to think of it - kind of how Python does classes :)

🤢 :-)

[FroMage]

The time when I see the ability to access the outside scope is the exact reason I add methods to a class

Except in this case, it's an include, so it's as if that method was part of many classes, all of which have different internal state. Think macros more than methods. I prefer methods. Macros are often unhygienic: https://en.wikipedia.org/wiki/Hygienic_macro

[ia3andy]

Hey folks,

Sorry to pop this subject up but:

Yesterday I had an issue which took me a while to find and fix, a tag I was using which comes from the web-bundler use name as variable AND my template also used name because obviously I didn't think about the clash in the first place.

It feels like a tag shouldn't use the scope data but only what is sent through params unless explicitly configured too.
Something like {#tag _scoped} when you actually want to use the parent scope.

The current behavior is hazardous, unnatural and very hard to spot or debug.

• Includes are mostly used for layouting so passing the context makes sense.
• Tags are used as "snippets" or "components" and meant to be use many times and in different places making the default behavior of using the parent scope very risky!

[mkouba]

Guys, I don't read any solid arguments in the comments above. It's more about feelings, expectations and different backgrounds.

That said, I'm ready to introduce a breaking change, i.e. change the default behavior for tags but keep the current behavior for includes. Here's a DRAFT PR: #35600

If we agree that this compromise makes sense then let's close this discussion and continue on the PR...

[tomocesnik]

I agree, it is definitely about feelings and expectations - like most of the things in software. :)

From my personal point of view, I think it would be nice to have some good way of defining "components" - similar to what React has (although I am not really experienced with it), but without all the additional mechanisms. The feeling is that people mostly expect this kind of behavior from Qute tags, but I might be wrong. Also lots of people using Java might have at least some experience with JSP tags (again not an expert in it): https://docs.oracle.com/cd/E19159-01/819-3669/bnalj/index.html.

So basically, it would be cool to have a way to "include" a bunch of HTML in a page, where all the parameters are explicitly passed at the call site (no implicit it parameter) and the context is not implicitly inherited. Supporting insert sections in such a construct would maybe also go against the core philosophy (unless they are evaluated in the context of the call site?).

In any case, I think it doesn't make sense to keep include and tag functionality to share the same behavior.
Therefore I would suggest to keep this discussion open and try to partially redesign how tags work - if we all agree that this would be useful.

[ia3andy]

@tomocesnik this is what we try to achieve here:
https://docs.quarkiverse.io/quarkus-web-bundler/dev/advanced-guides.html#server-side-web-components

[mkouba]

I agree, it is definitely about feelings and expectations - like most of the things in software. :)

👍 😄

From my personal point of view, I think it would be nice to have some good way of defining "components" - similar to what React has (although I am not really experienced with it), but without all the additional mechanisms. The feeling is that people mostly expect this kind of behavior from Qute tags, but I might be wrong. Also lots of people using Java might have at least some experience with JSP tags (again not an expert in it): https://docs.oracle.com/cd/E19159-01/819-3669/bnalj/index.html.

So basically, it would be cool to have a way to "include" a bunch of HTML in a page, where all the parameters are explicitly passed at the call site (no implicit it parameter) and the context is not implicitly inherited. Supporting insert sections in such a construct would maybe also go against the core philosophy (unless they are evaluated in the context of the call site?).

But I don't think that components should be part of the Qute core. Qute is not JSP/JSF/etc. It's a general purpose templating library. See @ia3andy's work for web-specific stuff.

In any case, I think it doesn't make sense to keep include and tag functionality to share the same behavior. Therefore I would suggest to keep this discussion open and try to partially redesign how tags work - if we all agree that this would be useful.

For sure, we can keep this discussion open.

[tomocesnik]

Jeah "component" is a pretty overloaded word - for the sake of convincing I just wanted to point out the main benefit of "component" "things" through a few examples. Their main point is: Encapsulation of smaller pieces to a separate/independent context.
The advantage is that one can reason about such "component" solely based on its inputs and not on some implicitly inherited state, which makes it much easier to avoid bugs as encountered by @ia3andy.

Therefore I am definitely for changing the default behavior of tags to support such encapsulation.

Points to discuss:

• Should the tags be allowed to inherit the state by using a special flag - reverse behavior as what we have now?
• Should implicit unnamed parameter it be supported or should all parameters be named explicitly?
• Should insert sections be allowed and how would they get evaluated (in which context)?

[mkouba]

#35600