Topics covered in this tutorial:
ScandiPWA Docker set-up comes with two options. You can either wither with or without front-end.
A front-end container completely replaces the front-end for the application. So, instead of the Magento server providing you with the front-end, the
webpack dev server does it.
You can check out one of our Docker set-up tutorials to find out more about the recommended aliases.
To start the development set-up use:
docker-compose -f docker-compose.yml -f docker-compose.local.yml -f docker-compose.ssl.yml -f docker-compose.frontend.yml up -d --remove-orphans
Or, if you have this alias set up
# docker-compose with front-endalias dcf="docker-compose -f docker-compose.yml -f docker-compose.local.yml -f docker-compose.ssl.yml -f docker-compose.frontend.yml"
dcf up -d --remove-orphans
M2 handles all requests
URL rewrites work
Dev server watches the files
In-memory caching - quick recompilation
To start, use an additional file
docker-compose-frontend.yml or the
/admin will be handled by Magento.
/products etc. will be handled by the
webpack dev server
webpack dev-server will be running in a container called
No customization abilities.
ScandiPWA supports color and content customization, however, it won’t function in development mode
No URL rewrites/redirects .
Magento router is not involved in the response generation, instead it is done by the
webpack dev server.
What are the pluses of this approach?
Dev server watches the files from your theme directory
app/design/frontend/Scandiweb/pwa. Recompiles after every change.
In-memory caching allows for quick recompilation of only the files which are changed or hot-reloading.
Every request is handled by Magento
Any change in the ScandiPWA folder will require for you to run the command
npm run build from its directory.
Any change requires full recompilement unlike in the development mode, where only the changed files are recompiled.
URL rewrites work
If you want to check out your customization, you need to switch into production mode and remove
-f docker-compose.frontend.yml from the stack
You can check out our docs for a step-by-step guide on how to correctly set-up.
If you don’t want to debug, change the
PROJECT-IMAGE = xdebug to
PROJECT-IMAGE = latest. Now, when force recreating with
dcf up -d --remove-orphans we see that the front-end container gets set up.
Use the alias
dcf logs -f frontend to see what the state of the application is.
If you see the following output, the front-end is ready. You can open a browser and go to
scandipwa.local to make sure that, indeed, the front-end is ready and will hot-reload.
ℹ ｢wdm｣: Compiled successfully
Open the folder
scandipwa-base/src/app/design/frontend/Scandiweb/pwa/src and create an
app folder in it.
You can check out the ScandiPWA VSCode extension to improve the speed of your workflow.
Assuming that you have the extension installed, search for
ScandiPWA: Extend source component and select
Breadcrumbs as a component to override. Press ok and then
Breadcrumbs.override.style.scss file, it will be full of warnings due to the fact that
stylelint is working.
Let’s check-out where the breadcrumbs are displayed on the web app. Go to your browser and type
scandipwa.local. Then go to “woman” > “dresses” for example, and right-click “Inspect element”.
You’ll see the element class
Breadcrumbs and all of its children who have
.Breadcrumbs-List styles. This is called BEM or Block Element Modifier and you can read more about it here.
For this example we’re interested in where the color of
Breadcrumbs is and upon further inspection we can see that it happens in the
Return back to the
Breadcrumbs.override.style.scss file and type the following.
Go back to your browser to check if its working. You should see a red breadcrumb container. This happens because the front-end container immediately compiles the styles and anything else in the ScandiPWA front-end app.