Change folder structure?

[copygirl]

Currently, our layout looks like this:

I feel like it would make sense to update this. I'm suggesting something like the following:

- src
`|-- main
 | `|-- index.js
 |  |-- MainCtrl.js
 |  |-- root.html
 |  '   ...
 |-- style
 | `|-- core.scss
 |  |-- profile.scss
 |  '   ...
 |-- routes
 | `|-- index.js
 |  |-- login
 |  | `|-- index.js
 |  |  |-- loginPage.html
 |  |  |-- loginPageCtrl.js
 |  |  '-- loginPageDirective.js
 |  |-- logout
 |  |-- signup
 |  |-- profile
 |  ' ...
 '-- yunity
   |-- components
   | `|-- index.js
   |  |-- yMessage
   |  | `|-- index.js
   |  |  |-- yMessage.html
   |  |  |-- yMessageCreate.html
   |  |  |-- yMessageCtrl.js
   |  |  '-- yMessageDirective.js
   |  '-- yWall
   |    ` ...
   |-- directives
   | `|-- index.js
   |  |-- loggedIn
   |  | `|-- index.js
   |  |  |-- loggedInCtrl.js
   |  |  |-- showLoggedInDirective.js
   |  |  '-- hideLoggedInDirective.js
   '-- services
     `|-- index.js
      |-- yAPI
      |-- yConversation
      ' ...

The index.js files in in routes, components, directives and services could be used to register things instead of having to update the main application index.js every time?

[nicksellen]

yunity.yMap, yunity.yConversation etc are not services, they are modules. Which can contain services, directives, config, etc... yunity is the core module (perhaps it should be named as such, yunity.core.

Whether to put directives/services in top level folders or within modules is a question is application size. Once there are a certain number of directives or services it will get tangled, hence the modules. See https://scotch.io/tutorials/angularjs-best-practices-directory-structure and https://github.com/mgechev/angularjs-style-guide#directory-structure for more thoughts about it (I read these before deciding on the module-based structure). For example, when the wall part needs a few directives and a few services, they are all inside a wall module, rather than spread over top-level directives and services folders (where they are also mixed with unrelated things).

I think the current components directory is a bit weird, they are mostly page-level directives to be used directly in routes. We don't use angularjs components.

Style files should go alongside their code too, rather than all in core as it is right now.

We have funny duplicated module names too like yunity.chat and yunity.yChat, but if the page-level directives are in the relevant modules then this would be resolved.

Where to register the routes can go two ways:

1. centrally register them (our current style)
2. register them in each module

I favour the central registration approach, so the urls can be defined consistently in one place (and it's the current structure). I'm not sure which approach your suggestion was for.

The index.js files in in routes, components, directives and services could be used to register things instead of having to update the main application index.js every time?

If they were in modules, then registering them in their local module would be enough, and the main app module (yunity.core) would not need to be touched.

So, I would suggest:

• we refine the module structure (so each module has clear places for style, directives, and services)
• rename the core module from yunity to yunity.core to make clear it's a module
• move everything into relevant modules
• remove any mention of components (the page directives to be used in routes should be named clearly, most of them already are though, e.g. createItemPage)

Something like:

.
├── yunity.core
│   ├── directives
│   ├── pages
│   ├── services
│   └── style.scss
└── yunity.yAPI
    ├── directives
    ├── pages
    ├── services
    └── style.scss

[copygirl]

Right. I do not have enough of an understanding yet to understand where the difference is between modules and services. Did you deliberately include "directives"; "pages" etc in yunity.yAPI? Because to me it seemed to just be a service. Also, currently all the page directives (and even the message and wall components I created) are wrapped in a module.

I think regardless of whether we're using Angular components it should be fine to call our reusable directives (currently yMessage and yWall) "components". Shying away from the term because it now has another meaning seems a bit silly. But then again I'm not sure what "component" meant in terms of Angular before components were introduced as a feature.

[nicksellen]

the difference is between modules and services

Everything in angular is in a module. Small apps just put everything in one module. Bigger ones split it out into multiple ones. Also, external angularjs libaries are defined as a module that you can depend on.

An application is defined as:

angular.module('myapp', ['foo', 'bar]);

foo and bar are modules, that myapp depends on. They can declare services, directives, hook into config stuff, anything the app can do. You can use anything defined by the module inside the app.

It's a way to group related functionality together. You could then test it independently too. And it should make sense on it's own.

Services are defined within a particular module, and make some functionality available to a controller via dependency injection so that it can be reused across multiple controllers.

Did you deliberately include "directives"; "pages" etc in yunity.yAPI

Ah, no sorry that was an error, that module wouldn't need pages/directives. Just services.

it should be fine to call our reusable directives (currently yMessage and yWall) "components". Shying away from the term because it now has another meaning seems a bit silly. But then again I'm not sure what "component" meant in terms of Angular before components were introduced as a feature.

The problem is it doesn't mean anything and never did! They are directives. Why add an extra term?

[copygirl]

The problem is it doesn't mean anything and never did! They are directives. Why add an extra term?

They are parts of the page that are actually visible and interactable. Unlike for example showLoggedInDirective, which only provides some minor functionality.