Data access

gistfile1.txt

grid-form
├── src
│   └── lib
│   │   ├── services
│   │   │   ├── grid-form.service.ts
│   │   │   └── grid-form.service.spec.ts
│   │   ├── graphql
│   │   │   ├── grid-form.fragments.ts
│   │   │   ├── grid-form.queries.ts
│   │   │   └── grid-form.mutations.ts
│   │   ├── +state
│   │   │   ├── grid-form.actions.ts
│   │   │   ├── grid-form.effects.spec.ts
│   │   │   ├── grid-form.effects.ts
│   │   │   ├── grid-form.facade.ts
│   │   │   ├── grid-form.init.ts
│   │   │   ├── grid-form.reducer.spec.ts
│   │   │   └── grid-form.reducer.ts
│   │   ├── grid-form.interfaces.ts
│   │   ├── grid-form.mocks.ts
│   │   ├── data-access-grid-form.module.spec.ts
│   │   └── data-access-grid-form.module.ts
│   ├── index.ts
│   └── test.ts
├── karma.conf.js
├── tsconfig.lib.json
├── tsconfig.spec.json
└── tslint.json

@adgoncal @swseverance As a final agreement, we have agreed to the following for what we are calling data-access architecture:

data-graphql
├── src/
│   └── lib/  
│   │   ├── fragments/
│   │   │   └── *.fragment.ts
│   │   ├── queries/
│   │   │   └── *.query.ts
│   │   └── mutations/
│   │   │   └── *.mutation.ts
│   └── index.ts
data-models
├── src/
│   └── lib/  
│   │   ├── *.interfaces.ts
│   │   └── *.mocks.ts
│   └── index.ts
data-services
├── src/
│   └── lib/
│   │   ├── *.service.ts
│   │   └── *.service.spec.ts
│   └── index.ts
├── karma.conf.js
├── tsconfig.lib.json
├── tsconfig.spec.json
└── tslint.json

Notes:

1. Per @adgoncal's recommendation, there will be no module for services and instead we will use providedIn within our @Injectable operator. e.g.

@Injectable({
  providedIn: 'root'
})

Url: https://medium.com/@tomastrajan/total-guide-to-angular-6-dependency-injection-providedin-vs-providers-85b7a347b59f
2. The idea behind tightly coupling all folder inside of the same feature before, was so our data did not get our of sync. By having an interface in the root, and having all folders related to data-access in the sub-directory, it enforced them all using the same interface.
The issue with this, is that it potentially causes circular dependencies, in particular for services. In addition, it was awkward to keep state in data-access, when really it is feature specific.

Now are using different folders and the issue of interfaces being out of sync might be an issue. However, there is a convention to keep in mind to help data keep in sync. This convention simply states, that all files using user.interface.ts file, will have the same pre-fix. That is:

- user.component.ts
- user.component.spec.ts
- user.fragment.ts
- user.mutation.ts
- user.fragment.ts
- user.service.spec.ts
- user.service.ts
- user.actions.ts
- user.effects.spec.ts
- user.effects.ts
- user.init.ts
- user.reducer.spec.ts
- user.reducer.ts

The interface inside of data-models, is the one that should be used for all the above files. Of course, some files such as the user.component.ts file might use multiple interfaces. That is completely ok, and is to be expected.

3. +state is going to be contained within the feature. So for the above data-access architecture, let's say for the user feature, the following folder/file structure is to be expected:

user
├── src/
│   └── lib/  
│   │   ├── user/
│   │   │   ├── user.component.html
│   │   │   ├── user.component.scss
│   │   │   ├── user.component.spec.ts
│   │   │   └── user.component.ts
│   │   ├── +state/
│   │   │   ├── user.action.ts
│   │   │   ├── user.adapter.ts
│   │   │   ├── user.effects.spec.ts
│   │   │   ├── user.effects.ts
│   │   │   ├── user.facade.spec.ts
│   │   │   ├── user.reducer.ts
│   │   │   ├── user.selectors.ts
│   │   ├── px-user.module.spec.ts
│   │   └── px-user.module.ts
│   ├── index.ts
│   └── test.ts
├── karma.conf.js
├── tsconfig.lib.json
├── tsconfig.spec.json
└── tslint.json
]

This feature is expected to use the respective data-access files.