signals: Using signals package with react router results in a wierd jsx error

@lennerd the fix may be to go back to injecting updaters into components via react internals rather than wrapping all components. I’ve been using and testing a local version of that approach this week, and it’s working in dev and prod builds using React Router 6.4.

couldn’t find a workaround for this error so I had to use the @preact/signals-core package with this custom hook

export function useSignalValue<T>(signal: Signal<T>) {
  const [value, setValue] = useState<T>(() => signal.peek());
  useEffect(() => signal.subscribe(setValue), [signal]);
  return value;
}

that allowed me to update the signals from anywhere and then where I use that hook react will rerender because of the local state update

it is not the best/optimal solution but hopefully, this issue with react-router could be fixed

@developit do you have any plan to publish your local work/fix?

I’ve been using this “lite” version of the React adapter in the meantime, which doesn’t include the Signals optimizations, but works with all React libraries and versions: https://gist.github.com/developit/f957536487a84dee334cfeb53748f865

@lennerd as a fix for the lazy-loading issue, you can add a static import for @preact/signals-react to your root component (<App />).

Previously I can put signal(0) in a utils file and call it everywhere I want but now with the ‘lite’ version. We can only use it as hooks which need to be in a React component instead a util fn. Am I understanding that correctly? Or how do we pass useSignal between components without prop drillings

+1 for fix on this! ❤️

@developit Any updates to fix the issue?

Am able to solve the issue by rolling back the router version to 6.0.0

Problem is the proxy around every React element type (the actual components) to enable rerending when signals change. So the proxy around the Route component breaks the element.type === Route check inside react-router. @developit Interested in how you plan to fix this. Strict equality check will always fail here, no?