[html] failure to initially run effect

[trusktr]

Describe the bug

In some cases, Solid will mysteriously not run effects (not even the initial first run).

Your Example Website or App

https://playground.solidjs.com/anonymous/fdbfd2dd-56ee-49cb-b77e-a615cb8af653

Steps to Reproduce the Bug or Issue

1. write a template with a function as a child in text content
2. read and write a signal in a specific location in the template
3. observe that effect made with createEffect doesn't run, not even initially

Example code:

import { createEffect, createSignal } from "solid-js"
import html from "solid-js/html"
import { render } from "solid-js/web"

export class DrippyScene extends HTMLElement {
  connectedCallback() {
    console.log("connectedCallback")

    // This never logs:
    createEffect(() => console.log(" ####################### EFFECT!"))
  }
}

customElements.define("drippy-scene", DrippyScene)

const [isDesktop, setIsDesktop] = createSignal(false)

render(
  () => html`
    <drippy-scene></drippy-scene>

    ${() => {
      if (!isDesktop()) setIsDesktop(true)
      return ""
    }}

    <div></div>
  `,
  document.querySelector("#app")!,
)

/*

Things you can do to make the effect run:

- comment out the line with if (!isDesktop())

*/

Expected behavior

Expect effects to always run at least once initially.

Ways to make the effect run:

• comment out the line with if (!isDesktop)
• or delete the text content interpolation entirely

Screenshots or Videos

No response

Platform

• OS: macOS
• Browser: Chrome
• Version: 144

Additional context

Here are a few different ways to make it happen:

• https://playground.solidjs.com/anonymous/86d0ecb9-cda4-423a-89b3-cface3d5bea2
  • Ways to make the effect run:
    • comment out the line with if (!isDesktop())
    • or delete the ${} interpolation in the text content altogether
• https://playground.solidjs.com/anonymous/8188dbc6-9fac-4698-a5a9-0a6247a394f4
  • Ways to make the effect run:
    • delete the ${() => ""}
    • or delete the <bottom-sheet></bottom-sheet>
    • or comment out the line with if (!isDesktop())
• https://playground.solidjs.com/anonymous/71db6422-a87c-4bff-b324-57a0effed12a (JSX too)

[trusktr]

A workaround is to pass the function in as a component. Here are all the previous examples with the workaround applied:

• https://playground.solidjs.com/anonymous/aef771ef-6b1b-4a41-a0e9-b885bae017c7
• https://playground.solidjs.com/anonymous/df67174e-07c8-479e-8fc5-31d932cbb5b0
• https://playground.solidjs.com/anonymous/8f57bfeb-c798-436c-8c4a-876ad5e2e9ed
• https://playground.solidjs.com/anonymous/034aa201-3b52-456f-9cba-010fbe054af7

[trusktr]

The workaround is not as straight forward in some cases. For example, the following code is reactive (and an app works fine when the above issue is not happening):

return html`<div>
  ${() => showFoo() ? html`<span>foo</span>` : html`<span>bar</span>`}
</div>`

https://playground.solidjs.com/anonymous/6636ebf7-e520-4a65-92a2-aa6cb2fa8791

But when wrapping it as a component it is no longer reactive (obvious considering it is now treated as a component):

return html`<div>
  <${() => showFoo() ? html`<span>foo</span>` : html`<span>bar</span>`}></>
</div>`

https://playground.solidjs.com/anonymous/a3d3ced1-0c7f-4206-b16f-906d1dbba83b

The idea here is that with that conditional expression being a valid (maybe not idiomatic) way to write conditionals, it's just easier to use it than importing Show and using <${Show}>. When performance isn't an issue for the scenario, then why not.

The app I'm helping out with was fine for months before the issue cropped up, so we got away with this format for a while. Good news for the app is we have a <show-when> custom element that is just a wrapper over <${Show}> that we can migrate many of these simple expressions to to workaround.

Simple conditionals are still nice though, especially for things that don't change rapidly and performance isn't really much of a concern:

Before (terser, simpler):

return html`<div>
  ${() => showFoo() && html`<span>foo</span>`}
</div>`

After (longer, not as convenient):

return html`<div>
  <show-when condition=${() => showFoo()} content=${() => html`<span>foo</span>`}></show-when>
</div>`

[trusktr]

Here's another example from the current app I'm helping with:

	override template = () => html`
		<div class="brand-container">
			${() => {
				const brandParam = searchParams().get('brand')
				const space = spaces.find(space => space.collections.includes(brandParam || ''))

				if (!brandParam) return null

				if (!space) return null

				return html`
					<div class="header">
						<div class="brand-logo">
							<img src=${space.logo} alt=${space.name} />
						</div>
						<h1 class="main-title brand">${space.title}</h1>
						<p class="description brand">${space.description}</p>
					</div>
				`
			}}
		</div>

		<other-content></other-content
	`

This has worked fine (apart from finally encountering the above issue), because it is a reactive expression, which means that the React-like early returns actually work as expected.

Imo this is totally fine usage, especially for writing simpler terser code when it's not a performance-sensitive piece of code.

We've been using Custom Elements as our unit of cross-file component organization and re-use, and these partials are confined to a single files used in single Custom Element definitions, which I believe is a totally fine practice. Cross-file components are always custom elements, but when there's no need to re-use something cross-file, it's simple to keep things terse for local re-use.

To migrate this particular example to avoid using template functions via plain interpolation sites, I need to convert it to a component by getting rid of the early returns, importing createMemo for derived values, etc. Doable, but not necessarily nicer for file-local re-use or file-local co-located variable derivations (assuming there wouldn't be the above issue).

[trusktr]

Actually working around this problem is trickier than I thought.

We have no choice but to pass functions for reactive text interpolations. Simply the existence of something like the following can cause the above error,

${() => {
  const val = one() + two()
  return val
}}

and this is equivalent to the following

${() => one() + two()}

which is idiomatic and common for regular text node interpolations, at least with html.

So basically this problem can happen at any time with fairly basic code.

The only true workaround, in my case, is to hunt down and find custom element constructors and connectectedCallbacks that read and write to the same signal synchronously.

[trusktr]

In the @lume/element package I was able to work around this by having the @element decorator wrap user class connectedCallback with untrack.

import {Element, element} from '@lume/element'

@element // <-- the decorator that subclasses the user class calls untrack(() => super.connectedCallback())
class MyEl extends Element {
  // ...code as usual...
}

With vanilla custom elements the workaround, if not using a decorator on all classes, it to ensure untracking the bodies of all connectedCallbacks:

class MyEl extends HTMLElement {
  connectedCallback() {
    untrack(() => {
      //... code as usual...
      if (!someValue()) setSomeValue(true)
    })
  }
}

Example: https://playground.solidjs.com/anonymous/94fa8d3e-4ac2-4168-9d3e-32701db3bb99