Interfaces are a large part of data-access architecture. They are the glue that makes sure that all parts of data-access are using the same data schema.
Within the interface we have the option to use an optional or real value. The question is, do we want to turn the interface into a real representation of the data or do we want to leave it loose and set values as required?
When you have your entire interface as a compulsory object, it forces the mock to conform to this shape. This is useful for, for example, when you want to test all services within a graphQL application, it will complain that fragments do not match, your mock data tests will have already caught it.
Solution to the Above Dillema
In Typescript there is the option to use:
Partial will treat an interface that will require every data type, as if all values are optional.
Where We Might Want a Partial
So that being said, within our data-access architecture we have:
Our actual services, facades, and state can take full interface without an issue. They are retrieving data from the back end. In addition, in our mocks.ts file, we want to include the interface fully, to make sure that all potential data is included in mock. The mock for the most part is going to be used across the spec for services and effects.
Word to the Wise
Ideally interfaces should be a direct one to one correlation between GraphQL queries within app. If any of these items are used, it should be updated, and appropriately updated in the interface. It makes considerable sense to create a tool around this.
Subscribe to the Razroo Angular Newsletter!
Razroo takes pride in it's Angular newsletter, and we really pour heart and soul into it. Pass along your e-mail to recieve it in the mail. Our commitment, is to keep you up to date with the latest in Angular, so you don't have to.