-
-
Save CharlieGreenman/35407e07bdf8771289e0e9469705aecc to your computer and use it in GitHub Desktop.
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:
- 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.
+state
is going to be contained within the feature. So for the above data-access architecture, let's say for theuser
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.
@adgoncal per conversation, I agree with you and we will do something like: