File & folder structure of our apps

[Mohammer5]

Right now, every app we have does things slightly differently, even when using the new app platform. I'd like to talk about whether we should aim for consistency in that regard as well and what we think works best for us.

I think what I like the best right now is having a very flat structure and use the duck approach on everything. I'll use the current state of the refactor of the sms-configuration app as an example:

I'm using views for the routes, these are more or less just controller-like components that just compose the different modules in the src directory into a working view as well as the view's meta data like route-path and label for sidebars, menus etc.

Everything else is a duck-module and contains components, functions and an index.js.

From time to time there's an issue with circular dependencies when using the index.js approach, which can be solved by importing directly what the files need and optionally split a file into multiple files when necessary (mostly happens when having two selectors.js importing each other)

[varl]

The code organization hierarchy that works for a 1K LoC application may not scale to a 10K LoC application, which in turn may not scale to a 100K LoC application.

Note that the LoC numbers are not meant to be exact, they are to illustrate that there is not one way to organize code logically for applications of all sizes.

That said, it would be to ours and everyone else's benefit that we have project templates, that we recommend and use, for at least small/medium/large webapps.

They would aid when guiding new developers into our ecosystem, during dev academies, and for our own sake when cross-pollinating.

I would like it if, if we do decide on some ideal structure(s), if we could enforce them automatically. Having a ton of conventions that you need to remember is not that nice in my opinion. Plus there's an opportunity for standards to drift and slip if it's not enforced.

[Mohammer5]

Yeah, maybe it's better to not have a convention, because it'll be hard to follow, especially as every app will have its own exceptions.

Maybe we could collect / decide on a set of rules that we would like to see, but don't enforce, and then write a guide / tutorial for how we think dhis2 apps should be composed architecturally.