Nx: Provide a way to speicify ngrx folder instead of '+state'

[debuggerpk]

I am not really sure if I should file this a feature request or not. Being mostly a python shop, we are set in our ways of naming folder structures, which usually begins with '_', so our OCD is preventing us from using this awesome package.

Does it make sense?

[bniedermeyer]

I've actually been confused with that naming convention too. I haven't seen it used in other projects or tutorials using ngrx. Is there a reason to use it other than making directories with state logic super visible?

[tomwanzek]

Having noticed the naming convention as well, it felt a little like a peculiar throwback to the early days of Angular 2x. Back in the old days 😄 , there was a proposed style guide convention to use the +-prefix in folder names which contained lazy-loaded modules.

I'd be interested in knowing the rationale in the case of nx.

As a matter of principle beyond just Angular, IMHO embedding "semantics" using certain characters into folder names tends to be not very future proof and is tedious to fix at a later stage. The rare exception would be where the guts of a language compiler (unfortunately) rely on such conventions.

So having more background on the + would be great.

[vsavkin]

• I think it's a good idea to have a convention for naming state management dirs, so you can look at any module and immediately see where state management code is.
• Since most tools sort files lexicographically, using a special symbol "highlights" that folder.
• "_" is often associated with privacy, so we decided not to use it. We picked + because the angular community already used it to highlight a folder before.

[vsavkin]

We can make it customizable, but everything that is customizable can break (e.g., the src folder in the standard cli project is customizable, but some built-in functionality only worked when it was set to 'src').

[vsavkin]

I guess there are two questions here:

• what should be the default
• should it be customizable

we should talk about those separately

[sean-perkins]

With Ngrx4 allowing for lazy-loaded effects, I would advocate if any naming schema is going to be used, to share the + operator already used by many (including myself) for lazy-loaded modules.

With respect to ngrx implementations, I've used Nx to segment that logic into it's own lib, so I don't see the use-case behind needing to organize it's folder to stand-out. I would merely have it as a "core" lib that I can easily access through it's scoped package.

[axtho]

I second what @sean-perkins said. In my case I created a core lib with shared services and the entire ngrx logic in it. They are organized according to the lazy-loaded module names. Currently I have 5 to 6 such modules, and already it would be rough to slap all the ngrx boilerplate (5-6 ts files per module) into one giant folder.

Ideally I would also want to import ... from '@myfirm/mycore/module1'.

[luchillo17]

Conventions are good, but allowing for customization is a must, in my company's case we deal with Ngrx folder structure by features, which means we have a core lib, and inside 1 folder by feat, like user, post...

In current state i'm forced to change the folder name and also all the paths that make use of such folder each time i generate a feat, not that big of a deal, but it consumes time, even more if it's a new project and i need to create many features.

[vsavkin]

It sounds reasonable. Let's make it customizable.