List of React APIs that are possibly not convertible/compatible to SolidJS

[lxsmnsyc]

Here are the list of features from React that may not be possible to be converted into SolidJS code and their possible workarounds

react

• cloneElement - Probably Element.cloneNode, but this highly depends on the usage and only works for DOM nodes not components.
• createFactory
• isValidElement - the lack of VDOM makes this impossible, however, instanceof Element can be a valid workaround in some cases.
• createRef - we can probably create a library shim such that this one exists and still returns the object, but we can convert those ref property usages into a callback assignment e.g. (el) => ref.current = el.
• forwardRef - Can be removed or provide a library shim, which ever works.
• memo - There's already a memo function in SolidJS but it behaves differently. We can remove this during compilation since it is totally unnecessary.
• useReducer - provide a library shim
• useRef - we can remove this and change VariableDeclaration, but that also requires current property accesses.
• useLayoutEffect - I'm not sure if createRenderEffect can replace this.
• useImperativeHandle - library shim
• useCallback - can be removed
• useDebugValue - statement can be removed.
• useDeferredValue - Now this one is highly different from createDeferred. We'll probably need Ryan's consultation.
• Mutable Sources - library shim
• useInsertionEffect - I'm not sure what this is, but I believe it is discussed in the <style> guide for React in the working group
• useSyncExternalStore - library shim
• Fragment - library shim, but I think I've suggested Ryan to add this one into the SolidJS core.

react-dom

• findDOMNode
• unmountComponentAtNode - This one's impossible.
• flushSync - not sure what this is for, probably for flushing updates.
• unstable_renderSubtreeIntoContainer - I think this one was used in React Server Components, but given we don't have VDOM, this one's impossible.
• unstable_scheduleHydration
• unstable_flushControlled

[tomByrer]

Quite the list!

cloneElement Why not? To me it is just composing.

Fragment Do not need more bloat in core; codemod could take care of the fraction of folks who use <React.Fragment>/<Fragment> instead of <> (which I think is more common?)

[lxsmnsyc]

cloneElement Why not? To me it is just composing.

Some tricks involves injecting props and stuff, but that doesn't really apply to Solid because it has no VDOM.

Fragment Do not need more bloat in core; codemod could take care of the fraction of folks who use <React.Fragment>/<Fragment> instead of <> (which I think is more common?)

Apart from explicitly using the component (which is quite uncommon, but occuring nonetheless), is passing it as-is. For example:

<Box as={Fragment} />

[edemaine]

FWIW, I use React.Fragment a lot in order to specify a key. Solid doesn't normally need a key, so I haven't needed it in Solid, but I'm not sure whether removing keys will be possible via codemod...