Frontend development in Sylius (non-JS)

[vvasiloi]

A discussion complementary to #13510.
Please read the issue for details.

[Prometee]

Main complain would be to have more atomic sylius_ui events inside each Sylius template to allow plugins developers to have more easy way to add new contents. This can avoid many diff migration process I guess.

[Roshyo]

One of the main issues I've seen is regarding folder structure.

Sylius' way it to put inside templates/bundles/xxxBundle/ every overridden template. And inside templates/xxx any custom-made template. (see screen)

But that way means that any FE dev that needs to work on the project needs to be fully aware of what template is Sylius (or Plugin) made, and what template is home made. Even after figuring this out, it means also having to switch between 2 folders to gather all the templates when working.

An alternative approach would be to use this kind of architecture:

Where every template is placed inside the bundle folder. So if one wants to add a new template to the checkout page, they will need to put it inside bundles/SyliusShopBundle/Checkout/xxx.html.twig

That way, there is only one folder to browse when working, which makes it easier for FE team.

But it has one downside of mixing up templates, making the migration process harder.

[mbabker]

Sylius' way it to put inside templates/bundles/xxxBundle/ every overridden template. And inside templates/xxx any custom-made template. (see screen)

That's the Symfony convention for overriding templates from bundles, Sylius just adopted it (and uses it in the theme bundle as well).

The issue with trying to put all overrides into one folder (be it a bundle folder like templates/bundles/SyliusShopBundle or some convention-based path like templates/overrides is you then have to mess with the Twig filesystem loader to look in that one path for every template and you then have to make sure that every template path for every installed bundle is globally unique (as in you couldn't have two bundles with an Admin/Product/show.html.twig template, how would the system know what is the right bundle to override in this case?).

[Roshyo]

The idea is not to change the path of templates or anything like that. But to have all Shop related templates inside bundles/SyliusShopBundle and all Admin related templates inside bundles/SyliusAdminBundle
And for home-made templates, the idea to treat them as Sylius native ones. So if you create a Admin/Brand/show.html.twig you'll call it include '@SyliusAdmin/Brand/show.html.twig and place it in bundles/SyliusAdminBundle/Brand/show.html.twig

[mbabker]

Bundles can't put templates in other bundle paths without manipulating the Twig filesystem loader in a compiler pass (Symfony only supports the template override path in the root application, it doesn't support bundles overriding bundle templates), and that is going to break the convention used by Symfony applications in general (which makes their templating documentation essentially useless in the context of Sylius). And again, you'd run into issues if different bundles have templates with the same name.

Both SyliusShopBundle and BitBagSyliusElasticsearchPlugin provide what would be a @SyliusShop/Product/index.html.twig template with your suggestion. Which one should be resolved if both bundles are publishing templates to the @SyliusShop Twig namespace? What happens if you install a third bundle which provides that template? I think trying to publish every template into a @SyliusAdmin or @SyliusShop Twig namespace would just create more problems than it fixes.

[Roshyo]

This idea is not regarding where plugins should put their templates. That does not change. Here it is only regarding final projects. Actual shops that will be running.

[mbabker]

If plugins aren’t all publishing their templates to the same @SyliusShop Twig namespace, then this can’t work. The entire reason the override feature works now is because TwigBundle prepends the override path to every Twig namespace it registers. If Sylius did something where it forced the @SyliusShop Twig namespace to be checked first for every template in every namespace, you still run into the issue of then requiring every template in every plugin to have a unique name otherwise you would not be able to distinguish a Product/index.html.twig template from one of any of the Twig namespace paths.

[4c0n]

My biggest issue is the use of Semantic-UI. It's really not great.
Also having 2 different build systems (gulp or webpack encore) is not great. Although I believe there are plans to drop gulp.

[4c0n]

That's probably where I went wrong, not using the drop-in replacement version. It was like 2 years ago or something, but ended up using the Bootstrap theme instead as it was easier. My original plan was to help evolve/mature the bootstrap theme far enough that we could use it as a replacement for Semantic-UI, but it would cause a lot of BC issues, especially for all the plugins out there.

[vvasiloi]

It's not a bad idea. I also used the Bootstrap Theme a few times and was a smooth DX.

[mbabker]

The sooner Gulp is dropped from Sylius core and all of the template repos, the better. The default Gulp build in the plugin skeleton is actually broken.

IMO, Semantic-UI is fine for the admin UI. But, I think you'd have to move a lot of stuff out of SyliusUiBundle to keep using it for the admin theme, otherwise, the admin design decisions will always leak outside of the admin UI. Since Pagerfanta is my "product" right now, I'll point out that one of those pain points is with the @SyliusUi/Macro/pagination.html.twig template and its "simple" pagination macro. With how templates are loaded, you can't override this macro only for the frontend UI, so any changes here would impact anything using the UiBundle's layouts, meaning the only practical option to change the pagination display for the frontend is to override the @SyliusShop/Product/Index/_main.html.twig template and not use the macro (which, you are most likely overriding this template anyway if you aren't using Semantic-UI for the frontend, but the fact you can't reuse the pagination helper would be a pain point).

And, even if there are plans for the main Sylius distro to go headless, I do think a lot of consumers would appreciate SyliusShopBundle continuing to exist in some form. I know for my company's Sylius builds, the shop bundle is more than capable of handling their needs and we might have serious pushback if we had to rebuild their frontends with a different set of tooling if the "fully featured" frontend were to stop being supported.

[vvasiloi]

AFAIK there are no plans to discontinue the shop UI.
If anything, this whole discussion aims to make customizing it and developing new UIs easier.

[mbabker]

I've seen a lot of chatter about moving toward headless, so I didn't know if dropping ShopBundle was also being considered. As long as it'll continue to exist (even with the headless plans), then that's good news to me.

[4c0n]

For the e-mails it would be great to have inky support: https://get.foundation/emails/docs/inky.html

[loevgaard]

Great!

[4c0n]

Yeah it's easier to do with Symfony Mailer though, so would definitely make sense to have that sorted first, Inky can be part of the tooling for sure: https://symfony.com/doc/current/mailer.html#inky-email-templating-language

[Roshyo]

My opinion here is that since emails are not a e-commerce top priority, we should just propose the Symfony mailer implementation, and then make sure we allow everyone to use w/e they want.

Some users won't even use native Sylius emails, some will prefer mjml, some inky, and even some other custom-made solution.

[vvasiloi]

I think that transactional email are very important in e-commerce and we should not neglect this aspect.
If we don't provide a built-in solution, then we need strong integration options, cookbooks / guides, etc.

[4c0n]

I totally agree that the e-mails are quite important! The first thing you want to do after seeing the text only e-mails that are sent from Sylius Standard is to customize them, but right now there is no nice way to do that. Inky is somewhat endorsed by Symfony (hence the mention in the Symfony docs and the package by Fabien Potencier), so it would make a lot of sense to have it available in Sylius IMO and by default make them look a bit more impressive.

[4c0n]

I kind of feel that the templates shouldn't be part of the bundles at all. They're really only used in a Sylius Standard based setup, so why not just have them be part of that? Or are people actually using the bundles and the templates separately?
If templates need to be added for plugins for example, it could be done using Flex.

[vvasiloi]

I know there is a dedicated template for form themes in both Admin and Shop, that extend the one from UI.
So you can override it only for Admin or Shop, but there are probably some exceptions from this rule.
Would be great if you could point out these cases.

[4c0n]

It's been a long time, but if I recall correctly the grid filters are an example of that:
https://github.com/Sylius/Sylius/blob/master/src/Sylius/Bundle/UiBundle/Resources/views/Grid/Filter/money.html.twig

[mbabker]

I kind of feel that the templates shouldn't be part of the bundles at all. They're really only used in a Sylius Standard based setup, so why not just have them be part of that?

That really only works well if Sylius stops providing any UI out-of-the-box of any kind (public-facing frontend or staff-use admin). I would expect that a fresh install of Sylius using the standard template would still have a functional admin UI, so the admin templates definitely should live alongside the AdminBundle.

Like I suggested in another comment, I think the ShopBundle should still exist in some form, even if it's not part of the out-of-the-box install (or even a first-party bundle). I do think a lot of consumers would appreciate having some kind of ready-to-go frontend package somewhere (and there could be options for this, and not all of them have to be first-party solutions; i.e. there could be the traditional ShopBundle or point folks toward https://github.com/BitBagCommerce/SyliusVueStorefrontPlugin for a Vue Storefront integration), and I think those integrations would work better if they are maintained solutions and not recipes that get applied to an application one time.

[4c0n]

It would still provide that. However in the form of either a theme or based on the standard implementation.
I don't see the problem with a decoupled frontend at all. If anything it would be an improvement and save a lot of issues with overriding/customizing.

[vvasiloi]

That looks similar to what I described in this comment.

[4c0n]

In order to avoid having to write controller actions for every little bit of data that might be needed inside the event templates a long time ago I wrote this expression language support thing for the event system:

#11591

If anyone is interested I could revive it, otherwise let's close it. :)

[vvasiloi]

I have mixed feelings about that one.

[vvasiloi]

An idea I had for some time is to have a template skeleton without any UI frameworks.
Just like there is a skeleton for plugin, there should be one for themes.
It should have Twig templates with HTML, some essential CSS/JS and build process with Webpack and Encore.
It could incorporate some best practices, latest industry standards. accessibility, SEO, etc.
The goal is to have a clean starting point for theme and custom UI development.
We can then make a pluggable default theme out of the current shop UI.

[loevgaard]

I am very happy that this discussion is even happening - that not everybody is so focused on that headless thing :D

I like the idea of completely separating admin and shop. For me, obviously, I would love the admin to look more like 2022, but certainly not something I would prioritize. I would 100 times more enjoy if the frontend looked more like 2022 :D I am more or less on the same page as Victor regarding an 'template skeleton' or something, but I would instead vote for choosing a framework, i.e. Tailwind.

But again, big thanks for even having this discussion ❤️

[vvasiloi]

Tailwind... Yikes!

See meme

Memes aside, if it's preprocessed in a way that doesn't leak all those utility classes to HTML then I don't mind using Tailwind.

[loevgaard]

I love tailwind so far :D And the whole idea is to have those classes directly in the HTML ;D

[4c0n]

Since Sylius is going the API platform route, it would make sense to me base the admin on the admin that is included with API Platform.
It is based on React Admin. I know this discussion says "non-js", however I guess progressive web apps are kind of the way forward. It's really not that scary and provides a lot of cool stuff, like automatic updates using Mercure etc..

[vvasiloi]

That looks cool! Great idea!

[rimas-kudelis]

hopefully there will be an option to develop an alternative admin sooner

I would think that's what the Admin part of the new API is for, would you not?

[4c0n]

Not necessarily, it can also be used for integrations with for example a PIM system.

[rimas-kudelis]

Of course not necessarily, but I mean it does (or rather will, when all functionality is covered) give you an option to develop alternative admin interfaces.

[4c0n]

Ok sure you can do that, but I kind of meant in the context of a standard admin developed/supported by the Sylius team instead of third party.

[dbalabka]

Based on my experience, the current state of Sylius the frontend development isn't satisfactory. It misses the possibility of performing simple dynamic behavior of UI. Still, building a storefront for headless e-commerce using Next/Nuxt.JS requires significant effort, especially when SEO is a requirement.

Recently, Sensio Labs started the Symfony UX initiative, which provides a very basic javascript ecosystem. Symfony Turbo is the backbone of this idea, providing the speed of SPA w/o the need to write JS. However, it might be extended with Stimulus to create more complicated UX experiences.

It looks like a very logical enhancement for the existing templating/theming approach without the need to abandon Twig.

[wadjeroudi]

Agree on that approach same goes for the admin, should be based on symfony turbo. for example grids could be autoreloaded when an order is updated.

[ikakarov]

I work on a big project using Sylius.
Every customer who uses the administration is unhappy because it is too basic and poor.
For example, we need three basic features that are present in every administration:

1. We need a media browser - that is very important when we have tons of records.
2. Dynamic grids - something like datagrid - that is crucial when you need to change or view large datasets.
3. Modal editing - something like Sonata modal edit - for example, I need to add a new tag to a product. I open the product, search for the tag, but for the creation step, I need to go to another page.

If I have some free time, I am considering starting the Symfony LAST* stack to create a simple frontend theme.
*Symfony LAST stack is:
Live Components
Asset Mapper
StimulusJS
Turbo

I believe that the poor frontend is one of the main reasons why this platform does not become one of the most widely used.