search

rsm-hcd / AndcultureCode.JavaScript.React.Components

Common atomically designed react components used at andculture
6 stars 8 forks source link

All files related to a component should be contained in a folder with that component's name #86

Open alexgetty opened 3 years ago

alexgetty commented 3 years ago

While many components are organized this way, the notable exception is the forms folder. A button component has its own folder, yet almost a dozen components share the forms folder. By giving each component its own named folder, it eases organization, maintainability, and portability since components are self-contained and isolated from each other.

I think there could be some exceptions to this rule. Perhaps if two or more components are very similar to each other, use the same base styles, and were only kept separate to avoid bloated prop objects or over-abstraction, then they could share a folder. An example of this might be the input components (text-input, password-input, etc).

On the other hand, if we did keep this as a strict rule and forced somewhat similar - but still distinct - components to have separate folders, then we could abstract out their shared visual styles into mixins which could then be reused in other situations as well.

brandongregoryscott commented 3 years ago

Personally, I'm all on board with components having their own folder as a strict rule. Especially given that we are holding storybook files, test files, and now stylesheets next to the component, the folders will fill up quickly.

alexgetty commented 3 years ago

@brandongregoryscott Yeah I think it sets the best precedent for keeping things organized in the future. The fewer questions we have to ask ourselves for every future component, the more likely things will stay organized and well maintained.

alexgetty commented 3 years ago

I have a branch queued up with these changes, but it is dependent on some other things happening first:

  1. PR #48 needs to be approved and merged

  2. 84 has all changes waiting in a branch created from #48. I'm waiting for that PR to go through before creating a PR for this one.

  3. The changes for this issue were made in a branch off of the completed work for #84, so once that PR is created and approved, I can create a PR for these changes.

This is a bit convoluted, I know, but all of these things are interrelated changes that can't be made in isolation without more manual rework later, so Phil and I thought this would be the best way to handle it.