-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow for custom types and interfaces #1217
Comments
Moving this back as it's not required before launch. Customers can create custom types by extending the default types. interface CustomProduct extends Product {
magic?: string;
}
@Injectable()
export class CustomProductService extends ProductService {
get(productCode: string): Observable<CustomProduct> {
const product: CustomProduct = { code: productCode, magic: 'Tobi 😉'};
return of(product);
}
} |
During the work on product scopes, @dunqan has done some more work around this topic. Unfortunately ng-packagr doesn't export the symbols in the root. If it would (something we'll investigate going forward), we could do the following: declare module '@spartacus/core' {
interface Product {
magic?: string;
}
} Alternatively, or on top of this, we can alter our core layer, with generics, so that customers can invoke a service with custom type, i.e.: constructor(protected currentProductService: CurrentProductService<MyProductType>) {} The latter might give additional benefits, but will effect the entire core model. |
We continue this work in #7940 |
Type safety is currently being hardcoded in the code base. This makes it impossible for customers to interact with custom types.
While this isn't an issue for the final production build, customers will have a hard time to extend
The following 2 examples illustrate the problem in our code base:
The facade layer contains a direct reference to the OCC models. Customers who have extended the product model, will not get any type safety for these new interfaces.
The component use the facade layer to get entities from the backend, and have added the typesafe models to the observed stream data. This is convenient both for the view logic as well as for business logic. Customers who extend this cannot benefit from custom types.
In order to provide for custom type safety, we should do the following:
Customers can then introduce custom interfaces which extend the default interfaces provided by Spartacus. This requires a path configuration, so that the typescript compiler knows where to load default and customer interfaces from.
An additional desired side effect of this approach is that we can update the typing library with each backend release. Having a specific version dependency will work towards a model where the dependency setup will dictate the backend version we're using.
The text was updated successfully, but these errors were encountered: