About directory structure scalability

[diegohaz]

About directory structure scalability

[diegohaz]

Hi, @mrtnbroder. Thank you for the words.

The components directory is scalable for sure. Actually, Atomic Design itself is scalable. From Pattern Lab, which this boilerplate is based on:

Pattern Lab is designed to be flexible with regards to naming and structure. There's really no One Right Way to do this, and we think that's just fine. Name things as you please, and we'll leave the hair-splitting out of things.

For example, I've added a themes folder to the structure. In this great article, @yejodido introduces ecosystems and environments.

That said, you could add a modals folder to the structure. But I think your suggestion is better, I would name it contents though. I'm doing something similar on Icon.

This is something worth discussing and it would be nice if other people could add their thoughts. In the end, though, you should do what better addresses your use case.

cc/ @bradfrost

[jlmitch5]

It seems to me like the <Modal /> component should probably not be concerned with the content inside of it...it should just be concerned with things like opening/closing and the consistent interface elements that all modals share (the close button in the top right corner, the background overlay behind the modal, etc.)

This makes me think that it might it could be a good case for a template? with a definition that looks something like:

const Modal = ({ children }) => (
  <div style={overlay}>
    <div style={modal}>
      <div style={modaBody}>
        {children}
      </div>
    </div>
  </div>
)

There is a possible issue here though. Modals are more complicated than just rendering a dom string. They require internal state ("is the modal open or closed"), and also may need to interact with the larger environment ("open a modal if the API returns an error", "all modals need to be closed if the user's login session has timed out").

Curious what y'all think about this idea.

[diegohaz]

It seems to me like the component should probably not be concerned with the content inside of it

I agree. What I did was creating a Modal molecule and some more specific modal organisms like ConfirmModal and LoginModal.

"open a modal if the API returns an error", "all modals need to be closed if the user's login session has timed out

To achieve that, we need to make the modal(s) state global. I wrote a implementation of this on the redux branch inspired by this answer from @gaearon on SO.

Basically, we have a modal store, the components and the respective containers to connect them to the store.

The usage would be something like this:

<Button onClick={() => props.dispatch(modalShow('confirm'))}>
  Delete
</Button>
<ConfirmModal name="confirm" onConfirm={() => props.dispatch(somethingDelete())}>
  Are you sure?
</ConfirmModal>

An example is the UserButton component and the UserButton container that opens the LoginModal.