A story of Spartacus implementation by a former core team member.
SAP Spartacus was first released in May 2019. From the very early stages of the product, Divante was working side by side with SAP to deliver an upgradeable, customizable, and extendable Angular eCommerce app. The goal was to replace SAP Accelerators, the previous, older frontend solution.
I joined the Spartacus project as one of the initial team members and acted as team leader for almost three years. I helped to build the app, and I’ve now moved to Divante’s implementation team.
Recently, I managed to finish one of the implementation projects. I want to share my experience with anyone interested in either building their eCommerce app with Spartacus or joining Divante as an Angular developer.
Please note that if you’ve never seen Spartacus, it’s an open-source eCommerce application written in the newest Angular. It’s constantly being upgraded, and the current version is Angular 10.
To begin with, Spartacus needs a fresh Angular application. So, it’s nothing fancy here. All you have to do is follow `ng cli` instructions and you have the basics ready.
The next step is to set up Spartacus. You have at least two options for that. The first one, for people who like adventure, you manually add everything according to the documentation. The second, and probably the preferred option, is to use Spartacus’ schematics. What it does is install the libraries, prepare the files and basic structure, and adjust the freshly installed Angular application. With schematics, you can easily set up Spartacus within minutes. From this point, you have the Spartacus application ready and working with many out-of-the-box features.
My personal take on that solution is that installing Spartacus and setting everything up is a real pleasure. There’s nothing complex about it. You simply follow a couple of instructions from both `ng cli` and the Spartacus docs, and you’re ready to go with your implementation. On top of that, the core team spent a lot of time making sure that the schematics help you run the app as fast as possible.
This is probably the part most readers are waiting for. There’s a lot to talk about here, but I just want to mention the most important parts.
Playing with the application logic
The project I was involved in didn’t require me to change the default Spartacus’ behavior that much. Nevertheless, I did make some changes to it. Spartacus’ core members worked hard to make the developers’ lives easier. Any form of extending or changing the default behavior is really easy and, what’s more important, logical. Extensibility was the key while developing Spartacus, because the majority of its users want to change its default behavior and make it as similar as possible to their old eCommerce or implement new designs and ideas.
One of the examples is changing the default behavior of the product details page (PDP). The customer I worked with had a lot of custom attributes set in the backend, most of which weren’t handled out of the box by Spartacus.
Extending Spartacus’ product interface:
The default product interface was not enough in this case, because the backend was sending a lot of additional product properties. The first step was to extend the interface. Any property coming from the CMS data, can be placed here, for the future usage.
When the new interface was created, we could use it in our codebase. In our case, we used `CurrentProductService` to fetch the product. The standard PDP will not show any additional properties, so we had to show them in our custom `ProductSummaryComponent`.
Using the newly created interface and fetching product:
A more elegant way of handling types and type extensions is type augmentation, you can find more info in the documentation.
Another example of an interesting Spartacus extension is something that I wasn’t working on and is not related with my project but is worth mentioning. Routing is not localized out of the box – so if you have a route, it will not be translated when you choose another language, for example `/en/USD/product` will not become `/pl/USD/produkt`. Divante’s Spartacus implementation team managed to make it happen. The changes that were made and a working demo are available here.
Changing CSS styles
As you may imagine, CSS styles is the first layer of Spartacus that needs changing when it comes to creating your own heavily customized application. One could even argue that if you change only the CSS part, e.g., you change the colors, you can treat your eCommerce app as ready. However, that’s not the case for the majority of Spartacus users.
Spartacus uses SCSS, so all you need to know is how this specific CSS preprocessor works. Alternatively, you can replace the whole CSS layer with your own solution. Yeah, Spartacus is super extensible.
Under the hood, Spartacus uses Bootstrap, so this requires additional knowledge if you’d like to extend the styles layer even more.
Example of changing Bootstrap’s media query breakpoints:
In this specific example, you might also want to change the breakpoints in the `LayoutConfig` file, so your data is identical across the app.
Many developers will think if their knowledge is enough to start with Spartacus. For the frontend part, basic Angular knowledge should be enough. Understanding how the most important parts work, where to look for specific files, or even how to create new services, is something you must know. In terms of backend knowledge, it isn’t necessarily needed when working with Spartacus, but it can give you a nice advantage. Sometimes as a frontend developer, you’ll need to talk with the backend guys, so you can understand some concepts and ideas. Especially when it comes to the CMS data sent by the backend.
Before you start implementing Spartacus, you should read the docs, so you understand what services and other Angular entities are available and what methods they have. The naming convention for them is logical, and so, if you’re looking for a service that can possibly help you with the currently visited product, you should look for CurrentProductService.
My tip for every developer that will be using Spartacus is to have it’s repo opened in the background. That way, you can easily find everything you need as well as some implementation details that will come in handy.
Even though every implementation project will be different, we can surely find some similarities. So, for each implementation, you’ll have the preparation part, where you have to set the environment up, install all dependencies, figure the folder structure out, etc. The majority of this step is automated, so you don’t have to worry about it that much. Then, you move to the actual creative part where you change the default looks and functionalities to your own needs.
Working with Spartacus is interesting and challenging. You can even learn some Angular “magic tricks” from the core codebase because the quality of it is excellent. Even some of the core team members, who had a couple of years of Angular experience before joining the team, could learn something!
If you have any questions, you can join Spartacus’ public Slack, and ask your questions there. The whole core team is waiting to help you. Also, the community of the developers itself is answering the questions. Alternatively, you can reach out to someone from Divante for a Spartacus training session.