Conversation
szczepaniak-michal
left a comment
szczepaniak-michal
left a comment
There was a problem hiding this comment.
Are you sure that you want to commit .DS_Store files? Seems as if they are some macOS files that should not be here
_pages/dev/best-practises/extending-best-practices/extending-best-practices.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Michal Szczepaniak <97286147+szczepaniak-michal@users.noreply.github.com>
…est-practices.md Co-authored-by: Michal Szczepaniak <97286147+szczepaniak-michal@users.noreply.github.com>
Co-authored-by: Michal Szczepaniak <97286147+szczepaniak-michal@users.noreply.github.com>
| }) | ||
| export class CustomCartTotalsComponent extends CartTotalsComponent implements OnInit { | ||
|
|
||
| constructor( |
There was a problem hiding this comment.
If we're not changing the dependencies of the component, we can omit constructor overriding because it would be inherited. Omitting the constructor, in this case, has the benefit that after the Spartacus version upgrade we don't need to do any modifications to our custom code.
At the same time it would be valuable to add an additional example where we do need to add an additional dependency to our component.
There was a problem hiding this comment.
This is to be mentioned somewhere else but I always suggest to add a custom prefix to all the elements. Here it is easy to mistake custom CartTotalsModule with the core one.
There was a problem hiding this comment.
This is to be mentioned somewhere else but I always suggest to add a custom prefix to all the elements. Here it is easy to mistake custom CartTotalsModule with the core one.
There was a problem hiding this comment.
I think that customI18nConfig is more readable
There was a problem hiding this comment.
For some reason "our Storefront Module" sounds strange to me. Maybe because you're writing this as a core team member and in this case, "our" may refer to the core code ;).
I would write either:
- your Storefront Module, or
- our custom Storefront Module
There was a problem hiding this comment.
I don't know if you want to add this but I personally don't recommend using breakpoints in the layout config, because it affects performance and causes flickering in SSR. Responsiveness should be achieved via CSS whenever it's possible.
|
|
||
| ### Extending pageMetaResolvers and normalizers | ||
|
|
||
| Extending Page Meta Resolvers or Normalizer looks the same as with adapters, the only difference is providing them. |
There was a problem hiding this comment.
I think it would be worthwhile to mention why we need to add it as multi-provider and how resolvers are being selected (getScore() method) - this is usually difficult to understand for the newcomers.
There was a problem hiding this comment.
I guess this will undergo proofreading but using "will" sounds bad to me here. It sounds like you don't suggest/recommend something yet. I think it should be:
- "we suggest"
- "we recommend"
There was a problem hiding this comment.
I'm not sure whether cms components should go into a shared folder. They are usually feature specific and they are used only once in the source code - in the mapping configuration. In my opinion putting them into shared folder might result in accidentally importing the mapping multiple times.
There was a problem hiding this comment.
@mateuszo It is only for shared elements. So if somebody has for example cms-component which is used under the cart, it will be under the cart feature module folder. But if it is banner-component we can put it in shared/cms-components/banner...
Sounds better for you?
…s into feature/best-practices
3 participants
close #1454