Leveraging Stateless Components in a Monorepo for Server Interactions
I'm currently working with an NX monorepo that includes a shared UI library. This library incorporates Storybook and other necessary components. The structure of my project currently requires me to amalgamate small UI components into an application page component located within apps/, such as UserMenuPage.tsx. This process, however, feels redundant as it necessitates the configuration of Storybook for each app.
As a remedy, I'm contemplating the idea of converting my pages into stateless or dumb components. Under this architecture, these components would not engage directly with the server. Rather, they would serve to extract data which would then be dispatched to the server via a handler function, housed in App.tsx, specific to each application. Essentially, App.tsx would return <UserMenuPage.tsx onSubmit={handleSubmit}/>, where handleSubmit is the function within App.tsx that takes charge of dispatching data to the server.
I'm interested in garnering the community's perspective on this approach. Is it advisable and efficient? Are there superior strategies to architect this setup, or potential drawbacks that I should be aware of in my proposed structure? Any insights or alternative propositions would be greatly appreciated....
Can I still get features like SSR/ISR with this infrastructure?
Hi everyone, I need to understand a bit about SSR/ISR with this infrastructure I have built.
I was first wanting to understand security implications to scaling multiple apps for my frontend, serving the HTML/JS to the users, while they consume my master backend, with all of the business logic...
Feedback for my infrastructure needed!
I'm trying to understand best practices for creating one infrastructure for my startup. Would like some feedback!
I want to have one single backend for all my business logic and have the possibility to have multiple frontends for different apps like so:...
