Computations created outside a `createRoot` or `render` will never be disposed
I am migrating my React application to Solid and I am encountering some problems.
When using this component that provides me with information about a phone's DDI, I get the error in image 1 and the component is this one:
And I am using this component here:
I tried changing the array to a function, like this:
But I still get errors, as shown in image 2.
5 Replies
Use
<For each={countryList}>{(county, index) => ...}</For>Here you are trying to create
components during module load time. That is a no-go in Solid because JSX creates its own "effect bubble" which has to be created under a reactive root which isn't created until here
for the components running under it.
So
countryList should be purely data and a component for the <img> should be factored out and only used inside another component running under render when actually needed with an item from countryList.
Also Solid doesn't use the key prop.
With For Solid would use the item object reference to key the created <option> element. This is why it is important to keep object references stable which means you are going to be using createStore and reconcile for data coming from the server a lot sooner than you may think.I understand that I'm already using createStore here. Would it be best to add this country list to the store, even though it's a static list? And could this be why I'm getting this error? "Error: Hydration Mismatch. Unable to find DOM nodes for hydration key: 0-2-0-0-2-0-0-0-1-0-0-1-0-0-0-0"
even though it's a static list?No, I was talking about data coming from the server where different objects in memory may represent the same entity. The primary issue is: that has got to go. Secondarily replace the
map in JSX with a For.
The hydration error could be an issue that isn't related to any of the code that you have shown so far.
Hydration errors tend to happen when something monkeys around with the DOM that Solid can't account for, in many cases it's UI libraries that modify the DOM independently, sometimes even the browser.
A typical starting point is to look at View Source (drop the contents into a Prettier window for ease of inspection) and see whether the hydration key exists in the SSR source.
If it does it's time to chase down what JavaScript is altering that part of the DOM during page load.
Sometimes if it you send HTML that isn't "well formed" the browser will helpfully correct it leading to a hydration errors.
So taking note of the differences between "view source" and the developer tools "Elements" view may provide a hint who is rearranging the DOM.Instead of flag being a JSX expression, you can make it a function that returns that e.g.
() => <img ... and then change where you have flag to flag() so that the elements are not created eagerly