Atomic design didn't work for me actually when using it with React. It makes finding the components harder than just using a flat, or feature-based structure. Let me give an example:
We have a Button component. It's a dumb component doing nothing, so we probably put this into Atoms. Now, I want to have an IconButton, which uses Button, so we'll put it to Molecules. Next, let's say we have a SubscriptionButton, which opens a newsletter subscription modal - this is a lot of logic, so we'll put it to Organisms. Now, it was not obvious for me or my co-workers (and especially newcomers) where should we look for the specific component. It very quickly became a mess.
IMO a lot clearer is a structure based on features. Basing on the earlier example, Button and IconButtons would be just Components (where all reusable, dumb components land), and SubscriptionButton would be somewhere in a Subscriptions folder, along with things like SubscriptionModal, SubscriptionModalCloseButton etc.
Hi Jakub,
thank you for your comment: I really appreciate it!
I'm not saying that the Atomic Design is the panacea to all evils (it has some limits of course). What I wrote is that it can help you to think in reusable components way.
Let's say we have a `SubscriptionButton`, which opens a newsletter
subscription modal - this is a lot of logic, so we'll put it to Organisms.
I think this approach is not correct: the SubscriptionButton shouldn't have any kind of logic, but it should have a trigger prop to be used for launching events (in your case opening a Modal).
The SubscriptionModal should be a different component and, using React, the best scenario could be something like:
<SubscriptionModal><!-- A subscription form--></SubscriptionModal>
I would put the logic part in the component which wrap both SubscriptionButton and SubscriptionModal.
I agree! I think that I didn't use a proper example for this 😄 I used Atomic Design in a project a few years ago and I forgot already about the specific cases where we struggled with using it.
I don't say it's a bad pattern, it just didn't work for me for some reason 😄
Oh, forgot to mention: your article is great!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Atomic design didn't work for me actually when using it with React. It makes finding the components harder than just using a flat, or feature-based structure. Let me give an example:
We have a
Button
component. It's a dumb component doing nothing, so we probably put this into Atoms. Now, I want to have anIconButton
, which usesButton
, so we'll put it to Molecules. Next, let's say we have aSubscriptionButton
, which opens a newsletter subscription modal - this is a lot of logic, so we'll put it to Organisms. Now, it was not obvious for me or my co-workers (and especially newcomers) where should we look for the specific component. It very quickly became a mess.IMO a lot clearer is a structure based on features. Basing on the earlier example,
Button
andIconButtons
would be just Components (where all reusable, dumb components land), andSubscriptionButton
would be somewhere in aSubscriptions
folder, along with things likeSubscriptionModal
,SubscriptionModalCloseButton
etc.Hi Jakub,
thank you for your comment: I really appreciate it!
I'm not saying that the Atomic Design is the panacea to all evils (it has some limits of course). What I wrote is that it can help you to think in reusable components way.
I think this approach is not correct: the
SubscriptionButton
shouldn't have any kind of logic, but it should have atrigger
prop to be used for launching events (in your case opening a Modal).The
SubscriptionModal
should be a different component and, using React, the best scenario could be something like:I would put the logic part in the component which wrap both
SubscriptionButton
andSubscriptionModal
.What do you think? 🙂
I agree! I think that I didn't use a proper example for this 😄 I used Atomic Design in a project a few years ago and I forgot already about the specific cases where we struggled with using it.
I don't say it's a bad pattern, it just didn't work for me for some reason 😄
Oh, forgot to mention: your article is great!