[🐞] attribute of the layout or parent component doesn't be reactive from the change of the context of the child components.

[genki]

Which component is affected?

Qwik Runtime

Describe the bug

I am making a layout that changes its look depending on its child, but the attributes of the layout is not reactive when the context is updated in the child components.
Strangingly, the contents of the layout is correctly changed reactively according to the update of the context.

The expected behaviour is the attribute should be changed reactively when the context updated.

Reproduction

https://qwikdev-build-v2.qwik-8nx.pages.dev/playground/#f=7VbBCsIwDP2V0pPCELw4HOhl4MmfEB1exMLwoMz%2Bu2mSptlWZR68eeu2vCxJX5KnSLMqyxxpiiHTCtmaeMJtjCe20OdI1w96BimwPzygJ2kIb7BAR3dxbWVs25zs057bprnacANUT7Kvb3ewHjaC8rWdWZhR8GQhW4bunAugHL3JgBBgozpQ%2Fgd%2BTFINCWoYtsC4ASwhG%2BPnqnVEjIU4Og3y8JoVGCAm9SMLKC6bSKNeBSg6KidWM0aUGSqSZkFOMduRmIwaqUt7tyJ7TsRPk5vwHYogFK3pxjvtaSRL38%2BZ5Vop6W%2FmTI%2BR%2FynziynzAg

Steps to reproduce

Please see the link above and confirm the style attribute is not changed despite of its content is changed.

System Info

System:
    OS: macOS 14.6.1
    CPU: (8) arm64 Apple M2
    Memory: 109.88 MB / 24.00 GB
    Shell: 3.6.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 20.12.1 - /opt/homebrew/opt/node@20/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 10.5.0 - /opt/homebrew/opt/node@20/bin/npm
    pnpm: 9.11.0 - /opt/homebrew/bin/pnpm
    bun: 1.1.26 - ~/.bun/bin/bun
  Browsers:
    Chrome: 130.0.6723.117
    Safari: 17.6
  npmPackages:
    @builder.io/qwik: file:../clone/qwik/packages/qwik => 1.10.0 
    @builder.io/qwik-city: file:../clone/qwik/packages/qwik-city => 1.10.0 
    typescript: ^5.3.3 => 5.3.3 
    undici: ^5.28.4 => 5.28.4 
    vite: ^5.3.3 => 5.3.3

Additional Information

No response

[JerryWu1234]

@wmertens @Varixo Did you fix this bug? Maybe I can try it

[wmertens]

This is expected behavior and it is the same in v1:

https://qwik.dev/playground/#f=7VbBasMwDP0VzRd3NJT11BFIdyjstJ8onelgo4GwwYrrf6%2BsZ8tOCaXXQm9OIil%2Bkp70qqZ5Xa2mmqa57LRGt6acZBvLKVnU59yusMScu9aE0g8f2yMTFBO5k2zt%2Bp9%2BaMkM7tPQicx%2BcO5gYkGQXnhsfv%2FZ%2FpIXVbT1zPDI4ifD4JPre99Hp6luhwE82KYipP6P41AREcUVzll82N3X9rB39lm%2BIOBCMHHY8WPXkWWUlt4ySmrJYs1wgohCDJJ5GCWZxIwofB0p8GtINqbmbeQGXN4d2OICGCWbvcSfJrWWyqI6bJTfjL2UK195YoRpFhtElWSOicEAsiLz1Zpv4ZCSFgJ9u2Pn89UXPJr%2FXCi8EMFadJoH5rH5fB7W%2BY1qXKXlMpFQOjcy8Ym5t9TvMf1KtQ3Q%2B%2BqKsRpaD1DvMS%2Fvcl6eAQ

What's happening is, the div style is output and then the child renders, which changes the context color. So the div is already sent to the browser and can no longer be changed.

When you run this in the browser (click rerender), it updates as expected.

[genki]

@wmertens
I think this behavior is too strange to be the spec.
I wish if we could set the attributes in the closing tag.
As the second best solution, how about to append the script tag that modify attribute immediately the components that provides contexts if they have changed in the children?

<script>
document.currentScript.previousElementSibling.attributes = ... ;
</script>

[wmertens]

As the second best solution, how about to append the script tag that modify attribute immediately the components that provides contexts if they have changed in the children?

This is really complex and in any case you'll get a flash of wrongly styled content + you require JS.

There are two real solutions:

1. don't output anything until all its children were rendered
2. change the app logic so nothing needs to change HTML that was already sent

Solution 1 uses more memory and slows down time-to-first-byte.
Solution 2 just needs some careful thinking at the beginning of writing your app.

[genki]

@wmertens
I found the real problem.
That is there should be 2 kinds of useContextProvider but there's only 1.
The two are such that useImmutableContextProvider and useMutableContextProvider.
The former is providing readonly contexts that can ignore the update among the children.
The later is providing read/write contexts that can be updated among the children, so thus the rendering should wait the output for the mutation of it until the all user of contexts have been rendered or rather the update will be happen in the client side.
I think the later examples are mainly the placeholder components for slow contents. So the useMutableContextProvider can just delay the rendering to the client side.

[genki]

The typical placeholder component will be vanished if its contents is not found.
The vanishment is belonging to the mutable context, it is happening at the client side.

[wmertens]

@genki actually the SSR code assumes that it can emit HTML while visiting the JSX tree, and implementing what you propose would be a big hit in performance, plus it would be a lot of code changes.

Why can't you make sure that context values are fixed before you render? You can change them from tasks before you do the first output. You could also render on the client instead of on the server (with a useVisibleTask that changes a signal that rerenders).

[genki]

@wmertens
Yes, it is possible if I use the useVisibleTask$.
But it means we have to use always useVisibleTask$ in the cases to change the value of context getting from the useContext.
Because the child component that call useContext doesn't know the change would modify the parent rendering or not.
I feel there's strong pressure to avoid using useVisibleTask$, I think it conflicts to that design.
It is good if there is something specialized useTask$ variant that runs in the client and casually usable.

[genki]

To achieve that, there can be useMutableContext that gets the mutable context value and marks the caller component as to suspend execution of useTask$ until the client rendering (it means all useTask$ in the component act as useVisibleTask$).
And then existing useContext would be changed to be getting frozen readonly value.