Remove KclProvider, replace its listener pattern with Preact Signals

[franknoirot]

Building upon #9058 (and #9056 by extension), towards #8880. We had this KclContextProvider component that gets around the difficulties with subscribing to updates to class properties by:

1. Establishing a React Context provider
2. Establishing React useStates which receive their initial values from the kclManager class instance's property values
3. Using a useEffect to wire up a series of "set" listener callbacks within kclManager that are fired within the setters for each of those properties, which then sets the React state proxies in KclContextProvider, which consumers of the context can subscribe to reactively.

So if we install @preact/signals-core and its corresponding bundler plugin for React we can get this sort of thing for far fewer lines of code. If you all like this I would like to propose it as a pattern we adopt, where state is kept outside of React in these classes and objects that interact, but React can subscribe to the "public" API of those state objects by wrapping them in Preact Signals.

Users should experience no difference with this refactor.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
modeling-app	Ready	Preview	Comment	Nov 29, 2025 6:00am

[andrewvarga]

Why is code a new parameter here instead of using kclManager.codeSignal.value?
Is it because it doesn't always use that but a new / modified code which is not yet in kclManager? If that's the case it's not a problem that the ast and variables are still being picked up from kclManager in this function?

[andrewvarga]

I've never used preact signals before but they seem very handy.
I agree that if we move more of our state to signals it can simplify accessing that state, and make the state less tightly coupled to React as well.
Maybe even move some state out of xstate to signals.

Do you see any downsides to using them so far?