Skip to content

Instantly share code, notes, and snippets.

@CharlieGreenman
Last active November 16, 2018 16:51
Show Gist options
  • Save CharlieGreenman/35407e07bdf8771289e0e9469705aecc to your computer and use it in GitHub Desktop.
Save CharlieGreenman/35407e07bdf8771289e0e9469705aecc to your computer and use it in GitHub Desktop.
Data access
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
@CharlieGreenman
Copy link
Author

CharlieGreenman commented Oct 24, 2018

@adgoncal would you be comfortable with something like:

data-access
├── src/
│   └── lib/
│   │   ├── data-access.module.ts
│   │   ├── data-access.module.spec.ts
│   │   └──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
│   │   │   │   ├── grid-form.interfaces.ts
│   │   │   │   ├── grid-form.mocks.ts
│   │   │   │   ├── data-access-grid-form.module.spec.ts
│   │   │   │   └── data-access-grid-form.module.ts
│   │   ├── karma.conf.js
│   │   ├── tsconfig.lib.json
│   │   ├── tsconfig.spec.json
│   │   └── tslint.json
│   │   │   ├── index.ts
│   │   │   └── test.ts
│   ├── index.ts
│   └── test.ts
├── karma.conf.js
├── tsconfig.lib.json
├── tsconfig.spec.json
└── tslint.json

@CharlieGreenman
Copy link
Author

@adgoncal per conversation, I agree with you and we will do something like:

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

@CharlieGreenman
Copy link
Author

CharlieGreenman commented Nov 8, 2018

@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.

  1. +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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment