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.
3 Replies
Brendonovich
Brendonovich17mo ago
I'm curious why you'd need multiple storybook configs? We use a monorepo and have 1 storybook app that can integrate all our web ui across our component library and shared interface. https://github.com/spacedriveapp/spacedrive/blob/main/apps/storybook/.storybook/main.ts Moving the onSubmit handler outside of the component sounds fine though, just seems weird to be exporting entire pages as components
fukasaku
fukasakuOP17mo ago
I am using storybook and monorepo for the first time, damn i didn't know that it is possible to share storybook. Thanks, i will redo my architecture.
Brendonovich
Brendonovich17mo ago
Ah nice haha
Want results from more Discord servers?
Add your server