Refactor Suggestion: Improve Readability and Maintainability of meshGenerationScript.js

[ferrari212]

I was inspecting the code as part of my self-learning and found the way FEAScript handles mesh generation in meshGenerationScript.js a bit problematic, making the code hard to read and extend. I can summarize the concerns into two main issues:

1. Misuse of class convention:
   The meshGeneration class appears to be structured more like a function than a proper class. It seems the class construct is used mainly to allow attribute sharing across different methods. The core logic resides in the generateMesh method, which could easily be a standalone function based on the current design. Furthermore, the use of a non-capitalized class name deviates from JavaScript conventions for class naming. Although technically allowed, this reinforces the impression that meshGeneration was originally intended as a function:

   FEAScript-core/src/mesh/meshGenerationScript.js

   Line 17 in 767da8a

   export class meshGeneration {

2. Deep if-else chains:
   The script contains more than three levels of nested if-else statements, making the logic difficult to follow. This complexity results from handling multiple conditions in a single method—for example, whether the mesh is "1D" or "2D", whether it is pre-parsed in GMSH format or not, and whether elements are linear or quadratic. This design will become even harder to manage if the mesh needs to support 3D elements or other formats such as VTK in the future. Moreover, this leads to a very large generateMesh function that violates the Single Responsibility Principle.

---

Proposal:
I suggest refactoring this logic by adhering to standard JavaScript class conventions. This includes using proper class inheritance—defining a base class with shared functionality and then extending it for specific cases such as 1D or 2D mesh types. This structure would make the modules more self-contained, reduce if-else complexity, and prevent code duplication in line with the DRY principle.

This refactor should not alter the behavior or output of the code from the user’s perspective. However, I believe it will significantly improve maintainability and make it easier to accommodate future extensions, such as the one discussed in issue #24.

---

Further question: Usage of loaders and separation between mesh parsing and data structures

I believe a more scalable approach for supporting different mesh formats would be to adopt a "loader" architecture. A good reference is how three.js handles multiple file formats—such as STL, GLTF, and VTK—through dedicated loaders. For instance, their VTK loader example demonstrates this pattern well. You can also explore the source code for the loader here:
https://github.com/mrdoob/three.js/blob/250c5f6d93b946f18103feb5a8b3dce70d1f4acd/examples/jsm/loaders/VTKLoader.js

Would such a modular approach be a good fit for the long-term architecture of FEAScript? It could promote better separation between the parsing logic and the internal mesh data structures. I’d love to hear your thoughts on this direction, @nikoscham.

[ferrari212]

Pull request related to this issue: #28

Examples tested locally without issues. No Loader was created. Further work can even reduce the if-else chain.

[nikoscham]

Nice work @ferrari212! I would like to thank for your effort and support in this project. Υour suggestions greatly improve the maintainability of the code (you are right that the meshGeneration class was initially designed as a function). I have also merged your suggestions to the Front Propagation Solver (https://github.com/FEAScript/FEAScript-core/tree/feature/frontPropagationScript) that I am currently developing (hopefully will be finished soon). The non-capitalized class names are in my to-do list. Thanks for pointing out.

Further question: Usage of loaders and separation between mesh parsing and data structures

I’ll need to take a deeper look into three.js, as it seems like a promising paradigm that could help us build more efficient software as the project scales. I agree in principle that separation is important for better code organization and management. In this direction, the Gmsh mesh reader has already been moved to a separate file in the readers folder (https://github.com/FEAScript/FEAScript-core/blob/main/src/readers/gmshReaderScript.js). Do you also propose creating a separate file for each mesh type for the internal mesh data structures?

[nikoscham]

The pull request #28 has been included in the latest stable release (https://github.com/FEAScript/FEAScript-core/releases/tag/0.1.2). Thanks again @ferrari212. FEAScript is growing, however, there’s still a lot of work to be done in code optimization and maintainability.

[ferrari212]

Hi @nikoscham, thanks for the recognition.

Regarding your question on creating a separate file for each mesh: I don’t have a strong opinion, but I generally find that keeping different classes in separate files improves maintainability by making it easier for developers to identify each class as a module.

I have done a quick look under OpenFoam source code to see how they handle this situation. It appears that OpenFoam segregated the mesh classes even further by separating not on the dimensional level, but on the components level like edges and meshes.

Given OpenFoam adoption and your recognition of their code standard, I’m inclined to recommend file separation.