Have you checked out React Nil yet? Any ideas for what you can build with it?
@kayis's posts on "Fullstack Frontend" fresh on my mind, my thoughts immediately start expanding on what I've already been doing to target multiple frontend platforms with shared codebase (React Native + React Native Web + Electron) for the last few years, in this case envisioning a subsection of shared (non-UI) React components that can also be used to lay out corresponding API endpoints, simplifying the API design process. I'm already sharing some backend logic between Node and Electron, so this just takes it a step further.
Top comments (12)
π€ for me, its use cases are very limited. Whatβs so special about react components/component-tree without vdom? Maybe I am just blinded by the ignorance and donβt see this? Please show some legitimate use case of react-nil
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 π
One use-case I could see myself using is it in browser extension background scripts.
I'd hate to write setIntervals to get latest data in background script and caching is a pain. If I use react-nil, I guess can use data fetching hooks like swr, react-query and push data to popups and tabs etc. Also if I ever have graphql api, react hooks are far easier to pull data from GraphQL API instead of sending post requests or graphql-request.
Very cool use case!
I recently made a way to make Discord bots with it! github.com/alii/discord-jsx
Sweet! Very nice.
Bump cuz React server components.