Replies: 2 comments 2 replies
-
|
Where is the "examples section" available now? Neither https://frontends.shopware.com/examples/ nor https://frontends.shopware.com/resources/examples/ works. Or is the "Building" page equivalent of "examples section"? Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
We moved it into building some time ago. https://frontends.shopware.com/getting-started/page-elements/examples/ |
Beta Was this translation helpful? Give feedback.
-
|
Can I use Shopware's API with pure JavaScript and no frontend framework to build a shop? Considering that there are hundreds of frontend frameworks out there and new ones are emerging every month, I wish Shopware had provided some tutorial/instructions or boilerplate for developers who wish to start building shops without Vue experience and using Shopware's API alone. This way instead of biasing toward a small portion of frontend developers who use Vue as their framework of choice, you were favouring all frontend developers out there. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @saeid-elio 👋 Thank you for your feedback. 🙌 We also try to make our packages and tools as platform-agnostic as possible. But honestly, the team has the most knowledge of Vue and Nuxt, and because of that, the demo-store template has the most features. We also have a React template; check it out here. Is that maybe already helping you to get started? All the best, |
Beta Was this translation helpful? Give feedback.
-
Shopware Frontends is built with the intention of providing a common, low-level API that provides
that can be used to build custom eCommerce projects with Shopware's APIs based on Vue.js.
We believe this is the right approach provides the right degree of flexibility for custom projects. Still, we provide a boilerplate implementation that can be seen as a "demo" for Shopware Frontends. But for now it really is not more than that - it lacks many important features, such as:
Our current idea is to leave it like that, because adding new, more complex features to the demo store also means we have to spend more time to maintain it. We feel that kind of work is not what we should be spending a lot of effort on. This leads to the argument of extensibility. In custom projects, there's always a decision to use third party code or to build something custom - for example
For many of these "features" it makes sense to provide a common ground. But it is difficult to define where this "common ground" starts when our public API is just the set of composables. There is no direct extension surface provided by the composables - as opposed to our default Shopware storefront where developers can build fully integrated plugins that extend everything from business logic through templates.
Having such an extension surface will drastically increase the complexity of the entire framework AND project development. Hence, we think we should follow a different approach than the default Shopware storefront. Instead, we want to publish new features in the examples section of our documentation and enhance them with guides / descriptions. That way we can provide a new feature as a cookbook / guide with instructions on how to integrate it, but without hard-coding any dependencies / extensions points into any custom project. It comes at the price of not being plug-and-play - but then again - this is the whole idea of Shopware Frontends in the first place. Prioritising a lean, dedicated project over a bulky all-in-one suite.
For the demo store it will mean we won't create an extension layer/override mechanism/slots on top of the components - but we will leave it as lean and easy to comprehend as it is and focus on providing qualitative guides/examples for complex features rather than fully-integrated plugins.
Please join the discussion by sharing your thoughts, experiences.
Beta Was this translation helpful? Give feedback.
All reactions