Replies: 1 comment 1 reply
-
I think so. I've seen some close source projects do similar things. One was using Context and Components to render to a single canvas. It will probably require a bit of a deeper understanding of the reactivity. Most of the conventions were setup with DOM in tow. A purely reactive component tree with with no intermediate DOM elements by it's nature is less isolated since you aren't binding to specific DOM elements but instead feeding into effects that render to the canvas. It is a bit lower level. But in general in terms of independent updates it makes a lot of sense. I don't see any glaring issues. Solid aggressively caches fragment partials (they are just arrays) which are what you'd be using a lot of with nested Components I imagine, if you were trying to create hierarchy. I know @trusktr has enjoyed using Solid with WebGL although he is wrapping it with a Web Component layer with lume(https://github.com/lume/lume). |
Beta Was this translation helpful? Give feedback.
-
I love reactive and declarative programming style. I had been looking for a canvas (webgl) renderer for React and found some libraries. But they are all limited on performance because of the way React work (causing too many pointless rerenders )
As far as I know, Solid doesn't have that issue. Is it a good idea if I implement a canvas, webgl renderer for Solid and enjoy the reactive/component based programming experience with only a very small amount of abstraction cost?
Beta Was this translation helpful? Give feedback.
All reactions