3

I have a molecule that uses the state to control the visibility of another UI element using the store.

Is it suitable to use the store from any where when applying Atomic Design or should there be one place/layer where all these components are placed?

Majed Badawi
  • 27,616
  • 4
  • 25
  • 48
  • 1
    the problem with having all the components placed at once place is , if component x wants some data then component y might also will re-render since they all are in one parent component . Instead it is better to scope the piece of state with the component which needs it . – Shyam Jun 02 '21 at 10:33
  • @Shyam thanks for commenting, my point is that following the best practices of atomic design, should store be accessed from any where (molecules, pages...) or should I group such components in a specific layer/category? – Majed Badawi Jun 02 '21 at 10:47
  • 2
    It's a good question that I struggle with too. I try to separate UI from logic, but sometimes there is a tiny UI element that needs to be connected to the larger app like a dropdown that loads its options from redux. – Linda Paiste Jun 02 '21 at 18:39
  • @LindaPaiste have you found a good practice for placing such components or they can be placed everywhere? – Majed Badawi Jun 02 '21 at 20:51
  • @MajedBadawi I end up placing them with other basic UI elements (atoms) but I don't know if that's "right". From a functionality perspective they are depending on outside contexts which I don't like. From a UI design perspective they are still tiny building blocks. – Linda Paiste Jun 02 '21 at 21:47

1 Answers1

1

I have faced the same problem few times during different projects and I've got some insights that might be useful for using atomic design and redux together.

Atomic design is very useful when you already know the whole screen design upfront. When you already know the layout or the UI screen prototype you can easily start using the atomic design based on the mockup provided. Then you can create the atomic design folders to put your components inside of it:

atoms <= molecules <= organisms <= templates <= pages

When using Atomic Design you should try to keep all intelligence (Shared States and Functions) in the parent components. This way you will not need to use a lot of redux, because you can pass the states and functions using props through all children until reaching the atoms.

The problem with Atomic Design is that when you don't have a clear picture of how the items are nested one inside another, you probably will have to change the design in the future, and therefore will have to untie the "Tree" of components you have created before.

Using Redux will give you more flexibility when making those changes in the future, because you will not need to keep the code very well nested and tied.

My recommendation is that you should keep a balance between both methods (the "tree" shape of the atomic design and the flexibility of redux) if you are working on new projects where there should have a lot of layout changes.

So after validating the MVP or the product with the client, you will have the UX confirmation to then start re-thinking in a full refactoring possibility, towards the full Atomic Design ("Tree shape design") approach.

Summarizing: There is no perfect architecture in this case because you will need to analyze the complex surroundings of the project also: If it is a MVP validation or an enterprise refactoring.

If you choose to use too much redux, you loose the beauty of the well organized and tied code. If you choose to use too much atomic design you loose freedom to make quick changes.

Other than that, try to keep atoms only with styling states inside of it. And then go drilling props down from pages to children components. Keep the parents "smart components" and children "dumb components".

And always evaluate the need for using redux. However if time is against you (as it probably will be) and if the project is in validation stage, use more redux too.

Ricardo N
  • 11
  • 1