codyhouse / codyhouse-framework

A lightweight front-end framework for building accessible, bespoke interfaces.
https://codyhouse.co/
MIT License
1.16k stars 173 forks source link

New structure for imported components? #63

Closed sebastiano-guerriero closed 2 years ago

sebastiano-guerriero commented 4 years ago

Hi everyone!

We need your opinion on a new structure we're considering for the components πŸ™.

Currently, in a project based on CodyFrame, the SCSS and JS files of the components are imported in two separate folders:

codyhouse-framework/
└── main/
    β”œβ”€β”€ assets/
    β”‚   β”œβ”€β”€ css/
    β”‚   β”‚   β”œβ”€β”€ base/*
    β”‚   β”‚   β”œβ”€β”€ components/
    β”‚   β”‚   β”‚   β”œβ”€β”€ _1_accordion.scss
    β”‚   β”‚   β”‚   └── _1_tabs.scss
    β”‚   β”‚   │── custom-style/*
    β”‚   β”‚   β”œβ”€β”€ _base.scss
    β”‚   β”‚   β”œβ”€β”€ _custom-style.scss
    β”‚   β”‚   β”œβ”€β”€ style.css
    β”‚   β”‚   └── style.scss
    β”‚   └── js/
    β”‚       β”œβ”€β”€ components/
    β”‚       β”‚   β”œβ”€β”€ _1_accordion.js
    β”‚       β”‚   └── _1_tabs.js
    β”‚       └── util.js
    └── index.html

The Gulp/Webpack configuration files will then compile the SCSS/JS into the style.css/scripts.js files.

We're thinking about creating a single "components" folder to store all the components:

codyhouse-framework/
└── main/
    β”œβ”€β”€ assets/
    β”‚   β”œβ”€β”€ components/
    β”‚   β”‚   β”œβ”€β”€ _1_accordion/
    β”‚   β”‚   β”‚    β”œβ”€β”€ accordion.js
    β”‚   β”‚   β”‚    └── accordion.scss
    β”‚   β”‚   └── _1_tabs/
    β”‚   β”‚        β”œβ”€β”€ tabs.js
    β”‚   β”‚        └── tabs.scss
    β”‚   β”œβ”€β”€ css/
    β”‚   β”‚   β”œβ”€β”€ base/*
    β”‚   β”‚   │── custom-style/*
    β”‚   β”‚   β”œβ”€β”€ _base.scss
    β”‚   β”‚   β”œβ”€β”€ _custom-style.scss
    β”‚   β”‚   β”œβ”€β”€ style.css
    β”‚   β”‚   └── style.scss
    β”‚   └── js/
    β”‚       └── util.js
    └── index.html

Why? When working on a project with a high number of components, having the SCSS and JS of a component in different folders could slow down the process of customizing/debugging the component.

What will be affected? If this change becomes effective, we will update the Gulp configuration file of the framework. Also, we'll modify the way components are exported using the Export page.

What do you think?

zakaria-chahboun commented 4 years ago

The second structure is great! Another thing, You have to do a re-implementation for the js scripts, to work without Mount it on any of JavaScript frameworks (svelte/vue/react ..) like any other JavaScript libraries!

balasivagnanam commented 4 years ago

Sounds logical, but what about projects that are using current structure? Will there be some ways to easily migrate to new format?

sebastiano-guerriero commented 4 years ago

@balasivagnanam projects using the current structure could continue using it. In theory, the new (potential) structure should affect only the new projects. Creating a tool that changes the location of the files (e.g., move all the component files of the current project into new structure) could be too challenging because we can't predict the custom structures. We're open to suggestions, though!

oppenheimer- commented 3 years ago

In a current project I have organized my components similar to the proposed file structure. But i had to push it further, because i deal with php and twig files in the same directory as the component as well. I thought about having optional seperated style sheets not being included in the main css, too. This enables using certain components on a per page base reducing overhead for the site in general. But all this let me to the conclusion to have generalized filenames in named component folder. Like "_main.sass" to be included in the main style sheet or "style.sass" for singular use; same goes for js. While i see it would definately create even more breaking changes, i just wanted to showcase my approach to add some perspective.

vaelu commented 3 years ago

We have a custom gulpfile.js which basically does 2 tasks:

In my opinion, the approach of having the sass and js files of components in the same folder is not a bad idea. However, the increase of productivity is not that big (at least for us) since when you work with a code editor like VSCode, you can just hit Ctrl + P and enter the name of the component, then you have the file in 1 second.

sebastiano-guerriero commented 3 years ago

@oppenheimer- Thanks for sharing your approach!

@vaelu true, that's why we haven't updated the structure in the end. As you were suggesting, it won't make a real difference. Tnx for the feedback πŸ‘

yankeyhotel commented 3 years ago

I like the new proposed structure, it feels like it would be much easier to navigate all of the files.

starchild commented 2 years ago

I prefer the existing structure - the reason being is that we have many other js files in use in our framework and we use gulp to merge them altogether with the cody ones.

Due ot the nature of js, we have to name/order them to avoid conflicts. Moving to this new folder structure will make this increasingly more difficult.

leaving js and css is much better IMO

sebastiano-guerriero commented 2 years ago

We're keeping the same structure in v3. I'm closing this discussion for now because there are no changes planned on the structure for now. Thanks to everyone for sharing your feedback!