What happens in an SPA? The view layer reacts to data sources, inputs, interactions. Frontend routing loads new screens/components.
What happens in a typical API server? Predefined routes listen for and respond to calls (even when parameters, etc. are part of the call).
With React Nil, the latter can be mapped out in the same declarative way (with almost identical syntax and even 1:1 mapped non-presentational components) as the frontend.
What I envision is similar in concept to GraphQL, but without an additional JSON-like syntax on both ends of the stack. Depending on your repo structure and use of wrappers, you could even have a shared component folder for both front and back.
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.
What happens in an SPA? The view layer reacts to data sources, inputs, interactions. Frontend routing loads new screens/components.
What happens in a typical API server? Predefined routes listen for and respond to calls (even when parameters, etc. are part of the call).
With React Nil, the latter can be mapped out in the same declarative way (with almost identical syntax and even 1:1 mapped non-presentational components) as the frontend.
What I envision is similar in concept to GraphQL, but without an additional JSON-like syntax on both ends of the stack. Depending on your repo structure and use of wrappers, you could even have a shared component folder for both front and back.
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 😉