Have you already started working with SAP Spartacus? In this article, I’d like to share with you examples of the common mistakes that you should avoid and how Divante can help you validate your code with auditing it.
Avoid these things while working with SAP Spartacus
Copying Spartacus source code
Most eCommerce developers might have experience in working with SAP Commerce Accelerators and they might want to use it while working with Spartacus. Although this knowledge is valuable and helps in most situations, it might lead to a big problem.
It might be tempting to copy Spartacus’ source code and modify it to your needs, as was the case with Accelerators. Although such an approach would work, it would break Spartacus’ upgradability. Instead, you should use Spartacus as libraries and change its behavior using another means (e.g. dependency injection, component mapping, outlets).
I wrote a little about this in my previous posts with intro to Spartacus PWA and features of Spartacus.
DO THIS
NOT THAT
Extensive outlets usage
Using outlets is one means to customize Spartacus. It’s quick and easy but it has a long list of drawbacks at the same time. The list includes:
- Outlets are not editable via the CMS
- They may cause performance issues
- They may lead to dirty code
- Might be difficult to maintain and error-prone
I’m not saying that you shall not use outlets at all. They are in Spartacus for a reason. Just think about their limitations and consider other solutions like component mapping.
Using the wrong recipe module
Spartacus provides so-called recipe modules. B2cStorefrontModule is currently the most popular. It provides a base implementation for a B2C store and most examples that can be found on the internet use it. It is a perfect fit if you’re planning to implement a simple store and you can re-use most of the built-in functionality. However, if you plan to make some deeper customizations, you should consider using another module like StorefrontModule or even StorefrontFoundationModule. Choosing an appropriate recipe module can result in performance improvements, more control over the codebase, and a cleaner code.
Forgetting about SSR
When you start developing your front end, it is easy not to take Server Side Rendering into account. The problem is that if you want to turn SSR on later in the development, it turns out that it doesn’t work well. The reason is that we might have developed components that break SSR. After doing so, it is difficult to find which they are. I suggest looking at the Server Side Rendering Coding Guidelines and at least mark parts of code that might affect SSR.
Reinventing the wheel
Before you start implementing a feature, it is worth checking whether Spartacus supports it out of the box or it has it on its roadmap. The less code you maintain by yourself the better. Documentation has some gaps and not everything is documented but, fortunately, there’s a Spartacus community slack channel where you can ask questions. Alternatively, you can contact us directly and schedule a consultation.
Is that all you should be careful about in Spartacus development?
No, these are only a few examples of some generic mistakes. Some more specific ones might appear in particular solutions. If you want to avoid them, head to the next section of this article.
How to support your SAP Spartacus project?
Spartacus Code Audit and Upskilling
Divante can audit your storefront solution and give you recommendations on how to improve it. Afterward, we can prepare an upskilling workshop based on our findings (obviously, this is an online workshop right now). Take a look at our sample code audit report:
General Recommendations
This section describes some general recommendations that could be applied globally in the project.
Project structure
Most of the project is well structured. It’s well modularized. However, the wishlist module could be modularized even more. Modularization makes project maintenance easier and can improve performance when lazy loading is enabled.
Recommendations:
- [Medium Impact] Split the wishlist module into smaller submodules.
Reference:
- https://cgcsoftware.co.uk/2019/03/shared-module-vs-module-per-component/
- https://stackoverflow.com/questions/46434830/should-i-create-a-module-per-component-in-angular-4-app/49902078#49902078
Outlets usage
MyProfile feature is implemented using outlets. It seems that cmsComponent mapping would be a better choice here.
Outlets are good for replacing existing components that appear on many pages. Component mapping is better to replace more specific components.
In the current setting, ProfileDetailsOverviewComponent (for example) is loaded on every page but not every page has an AccountDetailsOverviewComponent outlet. This slows down the initial page load as the component gets initialized at that time.
Recommendations:
- [High Impact] Use mapping instead of outlets for the given components:
- ProfileDetailsOverviewComponent
- ProfileConsentsComponent
- ProfileHistoryComponent
Reference:
- https://sap.github.io/cloud-commerce-spartacus-storefront-docs/customizing-cms-components/
- https://sap.github.io/cloud-commerce-spartacus-storefront-docs/creating-pages-and-components/
- https://sap.github.io/cloud-commerce-spartacus-storefront-docs/page-layout/
B2cStorefrontModule usage
B2cStorefrontModule is a starter storefront for B2C implementations. It could be customized easily using configuration and outlets. However, when a project grows and is highly customized, it might be more efficient to use StorefrontModule instead. This way we can have finely grained imports of Spartacus parts.
Recommendations:
- [High Impact] Consider whether it’s beneficial to migrate from B2cStorefront to StorefrontModule.
Reference:
In our code audits, we focus on different areas like code quality, performance, security, UI/UX, and SEO so that you get a comprehensive overview of your whole eCommerce solution. Besides that, we can take a look at the future plans of your solution and align them with the Spartacus Roadmap.
I think that pointing out mistakes without giving advice has limited value. That’s why we propose an upskilling workshop which aims to future-proof the development team.
The cost and the timeframe of the audit depend on the scale of the solution, so please contact us directly if you want to discuss the details.
Have questions? Feel free to ask in the comments or contact us.
from Divante.com Blog https://ift.tt/2zBZIuC via IFTTT
No comments:
Post a Comment