How React Nil could help achieve that? I mean I don't see the usage of state + render-cycle methods on the backend. Custom JSX parser/handler to make some kind backend components seems to have some meaning, but React as backend library or whatever? Maybe I am missing something obvious here? what you're proposing is something out of my imagination. And then you go further and say this idea is somehow similar to GraphQL š¤Æ. I have to see to believe š
Think of it as a "component query language," if you will. Obviously the underlying backend listener syntax will be different syntactically than the frontend request, but that's miniscule and the structure of wrapper components can be a literal 1:1 mapping in terms of routing/(synced) state/etc.
Sorry, I'm even more confused. And you didn't explain anything to me. What React has to do with making queries? And what means miniscule to you? Completely different architecture? What exactly you want to wrap in a React component on the backend side? Excuse me, if I sound like some dummy š
You can already already make queries (fetch, Axios, SWR, React Query, GraphQL, etc.) from React (DOM or Native). Since React Nil allows you to run non-GUI components on the backend (or frontend I guess, but what's the point?), it can essentially follow the frontend routing to offer the appropriate expected data through an abstraction. Kind of an extension of "write once, run anywhere."
Until I have time to flesh out what I envision into my own preliminary library (and since I just started working on a new product idea and a new podcast that inspired it, that may be a while), I'm really not sure how else to explain it, unfortunately. It's such a new library that there aren't any applicable examples in the wild yet AFAIK, but the README hints at the same potential.
How React Nil could help achieve that? I mean I don't see the usage of state + render-cycle methods on the backend. Custom JSX parser/handler to make some kind backend components seems to have some meaning, but React as backend library or whatever? Maybe I am missing something obvious here? what you're proposing is something out of my imagination. And then you go further and say this idea is somehow similar to GraphQL š¤Æ. I have to see to believe š
Think of it as a "component query language," if you will. Obviously the underlying backend listener syntax will be different syntactically than the frontend request, but that's miniscule and the structure of wrapper components can be a literal 1:1 mapping in terms of routing/(synced) state/etc.
Sorry, I'm even more confused. And you didn't explain anything to me. What React has to do with making queries? And what means miniscule to you? Completely different architecture? What exactly you want to wrap in a React component on the backend side? Excuse me, if I sound like some dummy š
You can already already make queries (fetch, Axios, SWR, React Query, GraphQL, etc.) from React (DOM or Native). Since React Nil allows you to run non-GUI components on the backend (or frontend I guess, but what's the point?), it can essentially follow the frontend routing to offer the appropriate expected data through an abstraction. Kind of an extension of "write once, run anywhere."
Until I have time to flesh out what I envision into my own preliminary library (and since I just started working on a new product idea and a new podcast that inspired it, that may be a while), I'm really not sure how else to explain it, unfortunately. It's such a new library that there aren't any applicable examples in the wild yet AFAIK, but the README hints at the same potential.
After all, you intrigued me. I hope something will come out of this. So Iām waiting for your React library for backend & frontend š