Feature Request: re-organise front-end structure

[AlainJanssens]

Some time ago I was experimenting with mean.js (for those who are not from this world :-), a node.js solution in combination with mongodb and angularjs).

I must say that I liked the setup of there project a lot. Especially on front-end side. They work with modules, and this makes (from my point of view) bigger projects easier to manage and the standard framework easier to update.

I would like to open the discussion on two levels:

1. Would it be an added value to use modules on the client side?
2. Would it maybe be even an option to use modules on the server side (aka maven modules). I know this is already discussed in the past, but sometimes you need to open an old discusion again and re-evaluate it :-).

To understand the new proposal of the folder structure, please read:

• http://meanjs.org/docs.html#folder-structure (‘public’ part. In JHipster it could be src/main/webapp)
• http://meanjs.org/docs.html#angularjs-modules

As an extra have a look also to there AngularJS Menus Service…(http://meanjs.org/docs.html#menus)

Thanks for your opinion.

Kind regards

[dancancro]

Here's my collection of alternative ways of doing AngularJS. It includes a section where you can see side by side comparisons of the different folder structures and different approaches to modules.

http://www.dancancro.com/comparison-of-angularjs-application-starters/

[AlainJanssens]

Hey Dan,

Thanks for your reply.

It is not my idea to go into discussion what is the best framework for the moment on the market. JHipster is fine for me, and I just want to help to make it even better. ;).

I just want to hear what other users think about changing the front-end to a module based front-end.

If other users share the same idea as me, I will spend some time to implement it. If not, they will probably bring good reasons why not and maybe I will learn something new :)

[magaton]

I would also like to show interest in this subject. I really like JHipster, but sometimes i find it hard to explain to the management that the project based on it, can scale. It is questionable if the current front-end folder/file structure supports that. That's why it would be nice to hear the views if MEAN way is better than Yeoman's or maybe even angular-app. I agree with @AlainJanssens, it is not about the framework, JHipster is simply great.

[jmirc]

AngularJs is not our strength so I really appreciate your feedbacks. When we started JHipster, we decided to use AngularJS because it is an easy framework for Java developer and I think it is a good framework too. I am sure we (as a community) can improve this part. I will take time to read the links.

[AlainJanssens]

Thanks @jmirc to take this into account.

If this change is approved, I can make some time free to help with this.

[jdubois]

Same opinion as @jmirc ! I am clearly more a Spring guy than an AngularJS guy : I am pretty confident about our back-end stuff, for the front-end any improvement would be welcome. Thanks also @dancancro : I might start to understand better what you are doing in the comparison chart :-) This looks like a pretty big change, maybe this could be the start of our 2.0 version? I will also read the documents in the next few days.

[QuentinAmbard]

I like the idea to have multiple modules, one for each feature, where each module can define its own route & dependencies (see http://entwicklertagebuch.com/blog/2013/10/how-to-structure-large-angularjs-applications/ ) But maybe it's just too complicated for small/medium projects.

(you can also check this community guide : https://github.com/mgechev/angularjs-style-guide)

[jdubois]

I had a quick view, and you all need to have a look at the "entity" sub-generator. This is probably the cause of much misunderstanding between us.

Here is the current idea:

• All "basic" stuff is done in the global controllers.js, app.js, etc in the src/main/webapp/scripts folder -> this is why people think we have a "monolithic" structure. In fact, this is just because I don't want tons of files for the "basic" stuff, in order not to confuse users for when they use the entity sub-generator
• The entity sub-generator allows to create modules per feature (= per CRUD in reality). If you create an "Article" entity, you will get a src/main/webapp/scripts/article module, with its own router, controller and service. So all entities should have their own module.

I'm not saying those modules are perfect (I'm sure we can make them better), but at least we already have modules.

Can you all give me your feedback on this?

[dancancro]

I've been having trouble defining exactly how modularity varies between approaches. I think most agree that a modular app shouldn't have a single 'controllers' directory, for example, that contains all the controller files for all the features and a similar single views directory, etc. It should be the other way around. But beyond that I haven't read a lot of discussion about what modular means.

So as a first crack at it, I just started researching how much the module-specific and core code was separated, by asking these questions:

Are all the controllers, directives, unit tests, templates and css for a module located in a directory named after the module? Is there exactly one front-end directory for a module and exactly one back-end directory for a module? Is there any core code in an app-specific directory? Is there any app-specific code in a core directory? Is the structure of the core code the same as that of the app-specific code? Is core code broken into modules? Is there a central catalog of modules, like npm or bower or homebrew or yeoman maintain? Is there a mechanism to let you add or remove modules with a single command?

A lot of them don't seem to do this, but I kinda think it makes sense to have a "core" module directory that is a sibling of each feature module directory, all of which are within a parent "modules" directory which is a sibling of directories for parts of the app that are not module-specific.

@jdubois - some feedback ...

I like how extensive the entity subgenerator is. I didn't count them all, but I think jhipster probably generates more lines of code (461) with its entity scaffolding than any of the others. I think that attests to its quality but it might have to do with J2EE being super verbose. The other ones I looked at don't use it.

I don't like the use of "scripts" as a directory name in this situation. I think it's redundant (not D.R.Y.) because the contained files have endings that tell you they contain javascript code (or coffee or whatever). To be honest, the same could be said of the "java" directory, but I know that practice is pretty deeply rooted. The one project I saw whose "scripts" directory didn't bug me used it to hold shell scripts that were run to set things up, but not the actual application machinery. Since I'm already whining about this stuff, I guess I don't like "webapp" either unless there's another sort of "app" to deal with. Would a "nativedesktopapp" directory or "embeddeddevicedriverapp" go here? The whole thing is a web app, both the front of it and the back of it, so having a "webapp" directory seems odd. Other projects use "public" and "app" which bug me too. So please don't think I'm just picking on jhipster.

I'm not sure I understand your comment about confusing users. Could you elaborate?

[AlainJanssens]

@jdubois

Currently there is already a kind of modules as you said. But I think it should go further. I want to put views, specific css and images also in the modules (logical modules). I would also like to split-up all controllers. For the moment there are about 15! controllers in one file. I think it is easier to read and maintain if they are in separated files. Grunt is there to combine all these files and do that job for us...

@dancancro

Here are some answers to your questions how I would like to see it ;)

• Are all the controllers, directives, unit tests, templates and css for a module located in a directory named after the module? Yes, they should all have a separated folder. Even views and images related to that module should be separated.
• Is there exactly one front-end directory for a module and exactly one back-end directory for a module?No. It is not my idea to split the back-end also in modules. I even think that it is not a good idea to split front- and back-end in the same modules. The logical split could be different.
• Is there any core code in an app-specific directory? Normally not. I hope the answer on the next question will make it more clear :-)
• Is there any app-specific code in a core directory? This is possible. You can create for example a menu-service that you write by yourself. It would come into this folder: core/services/menuservice.js. So it is in the core module, but when updating JHipster to a newer version, this file will not be touched.
• Is the structure of the core code the same as that of the app-specific code? Yes. All the modules would have the same structure. But not all modules will use all the folders! If your app-specific folder doesn't need specific css, the folder should not be there.
• Is core code broken into modules? This I would also like to do. Code related to the user could also be split. So I would create a module 'user' and put there all code that is related to a user, like sign-in, sign-up, authentication, change password,....
• Is there a central catalog of modules, like npm or bower or homebrew or yeoman maintain? Nobody could stop you to create a yeoman generator that creates a complete module :-). But I don't think this is the idea of community to create complete modules.
• Is there a mechanism to let you add or remove modules with a single command? There is now a generator to create an entity. I would keep the same approach, and maybe create some extra generators that create only a module, view or service ?!?

I hope this helped ;)

[jdubois]

Dear all, I am linking this to #640 as for me this mainly concerns the entity sub-generator. Of course the main generator could have some modules, for example for the "user", but this is less an issue for me. With the entity sub-generator, we could generator a module per new entity, for example: "yo jhipster:entity Product" would create a "product" module. To be more specific about what we will generate:

• For the backend I'm happy with what we have, and this is a part I know quite well. I do not want to generate modules on that part, maybe just add the option to have a specific package like in #615 which looks like a good idea, and is optional anyway.
• For the frontend, this is where we have the biggest challenge. Besides, it's the part I know less. From a theorical point of view (no code yet), what would be your "ideal" front end module? @dancancro and @AlainJanssens as look to know this very well? Or do you have a sample project?

[dancancro]

Whoever wrote this is better at it than I am, and they work for Google so their opinions matter more than mine. I care more about agreement than anything and chances are better of people agreeing on these guidelines than anything else. So if I had to give you an answer now, I'd give that one. I think it would be nicer of them to make a survey like this and be able to measure preferences instead of just going off the 31 comments to the blog post.

[AlainJanssens]

Hi, I have created a meanJS project with there standard structure. Have a look in the 'public' folder. This is what I mean about the structure I like. (https://github.com/AlainJanssens/meanjsStructure). I will try to do the same for a standard JHipster project and post this also.

@dancancro I'm also not an expert in AngularJS, and I'm definitely not better than the Google guy's. But sometimes I just don't follow there conclusions. And lucky for us there are more persons that don't follow the idea's of 'experts'. Rod Johnson also didn't follow the standard way of thinking :)

That said ;)

The recommended way of working is almost the same as what I proposed. Google calls the modules, sections. I just want to add a structure to those sections because I think it feels better when you put all the views, services, css-files, ... together in there own directory.

I will try ASAP to just create a basic project on github with a structure as I propose.

[jdubois]

@AlainJanssens you can also have a look at https://github.com/DaftMonk/generator-angular-fullstack they are supposed to be good

I understand better what you want to achieve, and I agree it looks better than the current structure.

[gunnarahlberg]

+1 for the angular-fullstack layout. To keep the MVVM files together is in my very humble opinion superior.

For me, it's more common to ponder the details of a feature, e.g. "how is authorization implemented" and then look at both the route, view, template, model and whatever there is in one directory. It is more seldom that I want to know "let's have a look at the controllers" and go to a "controllers" directory or the templates and go to a "templates" directory.

[jancel]

I may be a little late to the pool here, but I recently split out the front end entirely, using cg-angular, based on @dancancro's link above. This generator is just a front end generator that modularizes the approach to structuring Angular. It also uses UI-Router. I have also been turned onto "Opinionated Javascript" for the MVVM.

[jmirc]

Hi Jeff, it is not too late. I just started working on. Could you please share your work?

[manishgoyaler]

Hi @jmirc , I started using ihipster for my project and it make my life very easy. When we create entity if we only generate unit test case for server side. Is there is any change when you refactor please generate unit test case for client also.

[jmirc]

Did you check the karma unit test?

[manishgoyaler]

Yes i have created around 10 entity , and not a single client side test case generated for java script. But all rest unit test case are generated.

[jdubois]

I'm closing this as part of our 2.0.0 milestone, this is globally done