@ryansolid
It looks that SolidJS was intended to work with React. Will it work well with other lib/frameworks?
For other libs, it seems that SFCs are effective for leaf components, that don't need to send (state) change events to parents.
An additional issue with SFCs that bundle CSS, is that CSS is global in nature. Vue accommodates locally scoped CSS, but it is not as nice as plain/global CSS work with. I'd not thought through, this impact in React. If not clear, one component may have a different definition of blue compared to another, for example. For that matter, I hope your SFCs use pseudo-namespacing for your JS, as well.
Ideally, there should be an interface standard for SFCs, as per GraphQL. However, GraphQL has no need for state/event changes.
SolidJS is a different UI Framework that while it looks similar to React uses granular reactivity instead of VDOM to handle DOM updates. It's a competitor the libraries mentioned rather than something like a state management tool. It's more similar to taking Vue's composition API and building a full render library from it, (although it predates it by several years). React introducing tuple returns with hooks solved a longstanding API issue I was having so I adopted it. But Solid being based completely on those primitives independent of the Component system has unlimited composability, which I was trying to highlight at the end of the document.
CSS is sort of neither here or there IMHO. The bundler can handle that with CSS Modules or PostCSS, or CSS in JS solutions work as well. You can apply most CSS solutions outside of the framework or not and leave them global regardless of the your choice of framework.
The key take away from my perspective is about the rigidity of most SFC formats compared to a library like React, and even more so compared to a library like Solid. I'm advocating for patterns that organize code to match developer cognitive limits with the ability to extract portions easily as requirements grow. It's a more organic way of looking at component boundaries than firmly placing them for mechanical reasons for change management like React or syntactical limitations due to their respective SFC formats.
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.
@ryansolid It looks that SolidJS was intended to work with React. Will it work well with other lib/frameworks?
For other libs, it seems that SFCs are effective for leaf components, that don't need to send (state) change events to parents.
An additional issue with SFCs that bundle CSS, is that CSS is global in nature. Vue accommodates locally scoped CSS, but it is not as nice as plain/global CSS work with. I'd not thought through, this impact in React. If not clear, one component may have a different definition of
bluecompared to another, for example. For that matter, I hope your SFCs use pseudo-namespacing for your JS, as well.Ideally, there should be an interface standard for SFCs, as per GraphQL. However, GraphQL has no need for state/event changes.
SolidJS is a different UI Framework that while it looks similar to React uses granular reactivity instead of VDOM to handle DOM updates. It's a competitor the libraries mentioned rather than something like a state management tool. It's more similar to taking Vue's composition API and building a full render library from it, (although it predates it by several years). React introducing tuple returns with hooks solved a longstanding API issue I was having so I adopted it. But Solid being based completely on those primitives independent of the Component system has unlimited composability, which I was trying to highlight at the end of the document.
CSS is sort of neither here or there IMHO. The bundler can handle that with CSS Modules or PostCSS, or CSS in JS solutions work as well. You can apply most CSS solutions outside of the framework or not and leave them global regardless of the your choice of framework.
The key take away from my perspective is about the rigidity of most SFC formats compared to a library like React, and even more so compared to a library like Solid. I'm advocating for patterns that organize code to match developer cognitive limits with the ability to extract portions easily as requirements grow. It's a more organic way of looking at component boundaries than firmly placing them for mechanical reasons for change management like React or syntactical limitations due to their respective SFC formats.