Experiences from the first Shopware PWA project
Our first online store based on Shopware PWA is almost ready to be launched, so I want to share my experiences that I have gathered along the way. Maybe they will help one or the other when starting a new project with Shopware PWA.
At the beginning of a new project, the question arises whether to use the default theme or your own base theme (e.g. based on the default theme) as the basis for the project.
In advance: The theme can be changed at any time, so this is not a final decision. You can always start without a custom base theme. If you then realize at some point that a custom theme would be useful after all, you can usually simply transfer your changes already made to be in the theme.
Here are a few criteria that can be indications for one or the other variant.
- Store has only one language variant
- Store has multiple language variants, but with the same feature set (simple translation)
- Store has multiple "store views" with different feature sets
- possibly several similarly structured projects, which differ clearly from the default theme in several features.
A separate theme is therefore always worthwhile if deviations from the default theme affect several projects. These deviations can then be managed centrally once without having to maintain them individually in each project.
Currently, there are very regular updates, which you should also quickly integrate into your own project, so that the difference between your own status and the default theme does not become too large. This way, you not only get bug fixes and new features quickly, the change list also remains manageable. Normally, there is also a changelog for each release, which often contains update instructions for breaking changes or deprecations.
If you find a bug or a missing elementary feature, you should report it via Github Issue. If you feel able to do so, you should also fix the bug or implement the feature yourself and submit a pull request. The core team (in my own experience) looks at these promptly, provides feedback and/or merges them. This self-initiative is the fastest way to get a fix or feature into the next release of the default theme.
Also, I find that this way you can give back some of the value that the software offers you in a free to use software. 😉
Many initial questions are already explained in the documentation. It provides an overview of the setup, basic concepts and FAQs.
You can contact the core team directly and get answers to your questions via the official Slack channel. But the community is growing steadily, too, and like this you have the possibility to network with developers in the same situation. I personally am also very active there and try to help others as much as I can.
If you want to make adjustments to the logic in individual components of the default theme, from my experience you should use the Vue composition API in the overridden component. The reason is that you can keep the adjustments in the component itself minimal, because you can outsource the logic via a composition function in a separate file. In the so only minimally changed component you can integrate updates from the default theme much easier in the future, because the comparison of the default and the own component mainly shows only the changes from the update.
In some cases it can happen that the necessary adjustments in a component are so large that overwriting this component is more time-consuming than adding your own component. You should not be afraid to do this, because experience has shown that the integration of updates from the default theme is also much more difficult.
If only the styling of a component is to be adjusted, overwriting the component is not necessarily required. Many styles can be overwritten with the help of CSS variables, e.g. in
src/assets/scss/main.scss. Especially the often underlying Vue components from Storefront UI are to a very large extent customizable purely via CSS variables.