Strange re-render behavior when using <Switch> as a Route's root element

[nathanbabcock]

Start with this:

import { Router, Routes, Route } from '@solidjs/router'
import { Component, createSignal, Match, Switch } from 'solid-js'

const App: Component = () => {
  return (
    <Router>
      <Routes>
        <Route path="/" element={Page} />
      </Routes>
    </Router>
  )
}

const Page = () => {
  console.log('Component initialized')
  const [screen, setScreen] = createSignal<'a' | 'b' | 'c'>('a')
  return (
    <Switch>
      <Match when={screen() === 'a'}>
        <button onClick={() => setScreen('b')}>Go to B</button>
      </Match>
      <Match when={screen() === 'b'}>
        <button onClick={() => setScreen('c')}>Go to C</button>
      </Match>
      <Match when={screen() === 'c'}>
        <button onClick={() => setScreen('a')}>Go to A</button>
      </Match>
    </Switch>
  )
}

export default App

The expected behavior is that you click the button to cycle between screens A, B, and C.

But that isn't what happens. Instead, every time you click the button, the entire Page component re-runs. You can see the console.log appear multiple times in the console. In fact, you can never get to screens B or C since the createSignal also reinitializes. My intuition would be that since the Switch is a child underneath Page, that Page should render only once, regardless of how its children behave.

Could someone explain the rendering logic that causes this? It seems to happen with the other conditional rendering components as well, such as Show. BTW, it can be fixed by wrapping the Switch in a div, or any other "real" JSX component.

Or if it's a bug, I'll create an issue for it. But I am assuming that it's an implementation detail of Solid Router.

[nathanbabcock]

Just noticed one more thing. It seems to also be affected by the shorthand way I defined the route. Changing from this:

<Route path="/" element={Page} />

to this:

<Route path="/" element={<Page />} />

Also seems to fix it. Is the first version (passing a Component rather than a JSX element) a pattern that I should avoid? Both versions satisfy the signature of the element prop, and the first version seems to work in other contexts.

[ryansolid]

Yeah if you want to pass a component use component. Technically a prop-less component satisfies a returned accessor which is why it doesn't complain.

[nathanbabcock]

Ahh @ryansolid thanks for shedding some light on this. I didn't notice the component prop as well, that one works correctly for this.

a prop-less component satisfies a returned accessor

When you say "satisfies a returned accessor" -- does that mean it's treating it like a Signal, and calling Page() to get the "value" out of it? It's the automatic prop unboxing thing Solid does with Signals passed as props?

[pinko64]

I also had to do some excess troubleshooting a while ago.

I had something like this:

  <Route
          path="*"
          element={() => {
            const [chat, setChat] = createSignal(false);

            onMount(() => {
              console.log("Chat mounted");
            });

            createEffect(() => {
              console.log(chat());
              if (!chat()) {
                setChat(true);
              }
            });

            return (
              <>
                <Show when={chat()} fallback={<h1>Nope</h1>}>
                  <div>
                    <h1>Darn</h1>
                  </div>
                </Show>
              </>
            );
          }}
        />

Or just return (<>{chat() ? <div>....</div> : <p>Nope<p/></>})

And so we had a recursion loop. Re-running the function every time the state changed..

If the fragments (<>...</>) were replaced with divs or something else it would not re-run the function.

But indeed switching from element prop to component prop seems to fix it also.