Introduction to the Stack
A quick overview of the technologies of Scandi
Last updated
Was this helpful?
A quick overview of the technologies of Scandi
Last updated
Was this helpful?
ScandiPWA front-end stack basically consists of 4 technologies:
– a JavaScript library for building user interfaces
– a global state container and manager
ScandiPWA override mechanism
ScandiPWA plugin mechanism
Technologies 1) and 2) are well established in the front-end world, while the 3) and 4) require more attention and explanation.
Let's first consider how the normal React + Redux application looks like:
Well, simple! We have one global Redux store, which React Components talk to, and receive updates from. What's the problem? Well, in theory, there is none! If we had to write an application for a single-use – that's would be the way we do it!
But we have a problem. ScandiPWA is meant to be used as a base for other projects, it is almost never used without a modification. So, if we consider the above application, what problem would we face?
Well, for every project, we would have to maintain a copy of an entire application! Why is that a problem? Well, changes might be located in many different files, making it hard to trace changed files. As a consequence: developers might struggle during an update or while locating a file. With 800+ files in the project, going through each and every might be quite a struggle.
So, what might be a solution to this problem? Well, to make the application contain just the changed files. This is where the "override mechanism" comes into play!
To make the application contain just the changed files, ScandiPWA introduced the override (aka. shadowing, fallback) mechanism. It works in a very simple way:
Here is how our new application looks like now (red highlights application file overrides):
The application data-flow is unchanged, and React components and the Redux Store store is now coming from two sources: ScandiPWA and your custom application.
To learn more about how to override, please follow the link below:
Is our application perfect now? Well, yes! At least for 95% of Magento 2 features – that's should be enough! But what if we need additional functionality, that did not came out-of-the-box? How do we add it to our application? What if we need this functionality in different combinations on many different projects?
Manual import and use of packages might cause many problems. Feature implementations might require changes to many different places across the application, tracing this code back after the integration might become very challenging. And what if our feature requires a change inside one of our NPM packages? Well, we have no other option, but to copy the package to our project and modify it.
So, what might be a solution to this problem? We need a tool that allows to:
Build standalone NPM packages
Contain the integration logic within a distributed package
This is where the "plugin mechanism" comes into play!
To make the NPM packages contain integration logic, ScandiPWA introduced the plugin mechanism (aka. extension mechanism). It works a follows:
Here is how our new application looks like now (blue highlights application plugins):
This is how our application looks in the end. Notice, every layer is encapsulated:
Plugins are contained in their own packages, there is no need to import them manually. The code does not get mixed with newly added features.
Overrides are contained in their own package and contain project-specific changes. They make it easy to customize the presentation layer without modifying the source code.
To learn more about how to create application plugins, please follow the link below:
Well, Magento 2 has , but how to deal with such issues in our React + Redux world? Well, there are NPM packages, you might say. Well, NPM packages solve the issue of distributing and encapsulating the logic of a feature in one place. But what about their integration? Every time we want to use one, we need to manually import it into our code.
