From a project-organization standpoint, I maintain context via naming convention. If I have a page & organism that are tightly related like a "User Profile" page that displays the content via a "User Content" organism, I'll try to keep the file naming related across the respective /pages and /organisms (and other) folders, like /pages/user-profile-page.js and /organisms/user-profile-content.js
That keeps the relationship still observable/discoverable while the logic & data can still be somewhat separated so that the page only fetches/processes initial data, then passes whatever is needed to the organism via props (or stores data in global state).
Then the organism is only dependent on the props it receives or the global state it is connected to. From there, the organism handles any further feature/function if necessary pending user input or interaction, updates state as required.
Gotcha! This is my general approach;
From a project-organization standpoint, I maintain context via naming convention. If I have a page & organism that are tightly related like a "User Profile" page that displays the content via a "User Content" organism, I'll try to keep the file naming related across the respective
/pagesand/organisms(and other) folders, like/pages/user-profile-page.jsand/organisms/user-profile-content.jsThat keeps the relationship still observable/discoverable while the logic & data can still be somewhat separated so that the page only fetches/processes initial data, then passes whatever is needed to the organism via props (or stores data in global state).
Then the organism is only dependent on the props it receives or the global state it is connected to. From there, the organism handles any further feature/function if necessary pending user input or interaction, updates state as required.
Thank you very much for the explanation! This will surely help me out when applying atomic design to my projects! 😊