The storefront to be proud of.
Currently, the only installation option available is git clone, which should only be used for contribution. Once the application is complete, the single-command-bootstrapper will be deployed.
Contribution setup (you can also use fork instead of original repository):
# clone the repository
git clone git@github.com:scandipwa/shopware-pwa.git
cd shopware-pwa
# install dependencies
yarn
cd packages/blank-theme
# run Next project
yarn dev
This project is a modular storefront for Shopware 6, built with native API.
It is an "abstract" blank theme built using Next and React. It contains no styling code, and all functionality is splitted into small modules, each encapsulating a single entity or entity-relation.
This product is not monolythic, it is modular. It means more flexibility, as module (it's functionality) can be disabled or swapped at any given moment.
This project currently implements functionality of following enitities in following modules:
Entity name | Location |
---|---|
SEO-URL | packages/seo-url |
CMS | packages/cms |
Category | packages/category |
Product | packages/product |
Landing | packages/landing |
Most modules contain the following folder structure:
api
- the folder to contain requests and typingscontext
- the folder to contain Context and Context Providerscomponent
- the folder to contain layouts and templatesplugin
- the folder to contain functionality integration
It's important to understand following concepts before starting the development:
-
A theme – the collection of extensions styled to have a different appearance. Themeing is done by shadowing files.
-
An extension – a standalone module, that implements an entity. It contains functioanlity and integration. But modules should not countain styles.
-
A plugin – is a code located in
plugin
folder. That code is injected into the application, and intercepts some function, method or property call. The plugins are always bound to some namespace.
In general, data-flow is as simple as:
- URL is passed to SEO-URL module to determine the URL type.
- For current URL entity type, the specific entity layout and context is rendered.
For CMS, we render sections
, blocks
and slots
one in another, thus achieving the rendered CMS tree.
We lookup the implementation for each entity type in CmsContentFactory
properties. Plugins from other modules inject these values in, to provide support for different CMS modules.
For products, we have multiple contexts: FilteringContext
and ProductListContext
.
-
FilteringContext
is used to synchronize the filtering options with URL. -
ProductListContext
is used to synchronize the product and aggregations data with the application.