JumboCode / TUTV

JumboCode project for TUTV, currently led by Frank Ma. Led by Deepanshu Utkarsh 2019 - 2020.
4 stars 0 forks source link

Components #25

Closed isabellau closed 4 years ago

isabellau commented 5 years ago

Components dashboard layout files

duci9y commented 5 years ago

@isabellau and @erenaci, it looks like some of the checks failed. Try to fix them on your own first and commit updates to the same branch. Let me know how it goes/if you need help!

erenaci commented 5 years ago

What's the reason that the components are stored in such a deeply nested file structure? For example, why is the Icon inside PageContainer/TotalContainer/MainContent/Dashboard instead of just in the components folder?

Because this is how the website is structured, as seen on Equipment dashboard component breakdown issue #22.

controversial commented 5 years ago

Traditionally in web component frameworks like React, you want components to be reusable throughout the app. This means that if down the road, some other part of the TUTV app calls for an Icon, you should be able to use the Icon component you've already created to fill this purpose, rather than creating a new identical (or nearly identical) component for each part of the app where icons are required. For this reason, it's something of an anti-pattern in React to put components in separate silos like this, as the React authors designed components specifically as a mechanism for flexible re-use.

Even though the current app diagram in #22 shows components in a nested configuration, it's traditional to put all of the source folders for components' code at the very base level of the components folder, rather than nested up like this. A flat structure encourages reuse, for example if it becomes useful to display a calendar elsewhere later.

For any react app, I'd definitely encourage something close to a flat folder structure, besides in specific cases where a component is very clearly and explicitly designed to not be reusable.

Note that even if component code files are stored in a flat structure like I'm suggesting, the components themselves will still be nested in actual use; that is, it's possible to write code like this:

<Sidebar>
  <Calendar/>
</Sidebar>

even if the source files for Sidebar and Calendar are stored like this:

📂 components
|  📁 Sidebar
|  📁 Calendar

A flat folder structure doesn't sacrifice the semantic and organizational advantages of nesting.