Closed sebastiano-guerriero closed 2 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!
Sounds logical, but what about projects that are using current structure? Will there be some ways to easily migrate to new format?
@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!
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.
We have a custom gulpfile.js which basically does 2 tasks:
dev task
deploy task
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.
@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 π
I like the new proposed structure, it feels like it would be much easier to navigate all of the files.
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
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!
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:
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:
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?