I see yeah, code re-use through functions is the way to go. What I'm curious about, but I think the answer is no, is if you removed dom-expressions and had only specific functions directly in solid-js and no moduleName option for the Babel preset for example, would it make any difference? Would it be effectively identical to what dom-expressions already requires anyway? Or is there something you would remove if it were solid-specific and not allowing anyone else to hook in?
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.
If the code is gzipped, it should make hardly any difference. But it still bloats the code so reading it takes more time, so I applaud your decision.
I see yeah, code re-use through functions is the way to go. What I'm curious about, but I think the answer is no, is if you removed dom-expressions and had only specific functions directly in solid-js and no
moduleNameoption for the Babel preset for example, would it make any difference? Would it be effectively identical to what dom-expressions already requires anyway? Or is there something you would remove if it were solid-specific and not allowing anyone else to hook in?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.