Some compiler options that I don't use. But almost nothing on the runtime side. The core file that I use to compile it to the specific libraries is tuned to Solid's API to the point that it basically just disappears in Solid's build step. That isn't true 100% for the others but I mean it's like an extra function wrapper etc..
Dom Expressions almost expects the runtime to be overridden for those custom cases like say MobX supporting class components. It provides a differenct createComponent function. I'd never do anything to compromise Solid's size or performance. The most awkward thing might be some redirection of shared Hydration state with the libraries being separate but I think I have that dialed pretty nice as well. Maybe the way I shadow imports. Like I expose them automatically through solid-js/web when they exist in solid-js but in the end bundled program again that all disappears.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some compiler options that I don't use. But almost nothing on the runtime side. The core file that I use to compile it to the specific libraries is tuned to Solid's API to the point that it basically just disappears in Solid's build step. That isn't true 100% for the others but I mean it's like an extra function wrapper etc..
Dom Expressions almost expects the runtime to be overridden for those custom cases like say MobX supporting class components. It provides a differenct
createComponentfunction. I'd never do anything to compromise Solid's size or performance. The most awkward thing might be some redirection of shared Hydration state with the libraries being separate but I think I have that dialed pretty nice as well. Maybe the way I shadow imports. Like I expose them automatically throughsolid-js/webwhen they exist insolid-jsbut in the end bundled program again that all disappears.