Great overview of atomic design. I've gone through many iterations of component organisation (as I'm sure we all have) and although the names of the folders are often different, when I take a step back i almost always realise I've just reimplemented atomic design lol.
I've started doing all my external calls at the pages level, so at the organism level you may understand the application, but you don't tightly couple to the underlying technologies. Then when I need to work out where a fetch or a mutation is taking place, I know it's at the pages level.
That's a very nice solution to organising external data gathering! I'm curious to know how you show this coupling of data inside your code. I am currently working on a project where your described solution seems to be the only one, and because I am a person who emphasises context above all, I want to see how you retain this while separating part of the logic tied to the context.
I'm not sure I follow exactly your question "how you show this coupling of data inside your code". Are you asking about the relationship between the Page and the Organism?
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.
Great overview of atomic design. I've gone through many iterations of component organisation (as I'm sure we all have) and although the names of the folders are often different, when I take a step back i almost always realise I've just reimplemented atomic design lol.
I've started doing all my external calls at the pages level, so at the organism level you may understand the application, but you don't tightly couple to the underlying technologies. Then when I need to work out where a fetch or a mutation is taking place, I know it's at the pages level.
That's a very nice solution to organising external data gathering! I'm curious to know how you show this coupling of data inside your code. I am currently working on a project where your described solution seems to be the only one, and because I am a person who emphasises context above all, I want to see how you retain this while separating part of the logic tied to the context.
Thanks :)
I'm not sure I follow exactly your question "how you show this coupling of data inside your code". Are you asking about the relationship between the Page and the Organism?
Yes, that's what I meant. I just read my comment again and I could have definitely worded it better and more succinct. 😅
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! 😊