Currently we work with a 'mostly vanilla' b2b setup, where Yves is rendering static content.
We have a requirement to reduce the number of page loads in certain situations, having a more dynamic experience. We have some ideas, but I was wondering if the Herd had some suggestions, known-to-work patterns or just some experience in this area.
For example, we are about to implement variant selection without page loads:
→ Product data (images, description, price…) must be reloaded with updated info.
→ Variant selectors need to trigger page loads
→ Add to cart needs to be aware of the current selection
As of now, Yves does a page load and every component will have the proper state loaded.
I was trying to get inspiration on the documentation, and according to it, a components does not have parts that are executed in other components, nor it executes parts of code for them (
Does anyone have a strategy in mind? We'd rather not reinvent the wheel, here are the current ideas by our team:
→ Load all variant data into an array, set tags in html to find data to update, trigger those updates on variant selectors (handling dependencies as well, i.e. when a product has 2 super attributes).
→ Similar approach as before, but do a glue/glue-storefront api (would be the first usage of glue in our project) to load product data on demand
→ Instead of working with product data, use pre-rendered twig blocks, and replace them via js events.
Also, we are wondering wether putting all work in the pdp component, or work or way down, making each component 'listen' for certain events.
I was impressed by composable frontend and oryx demos on Excite, but I can't find any documentation on 'iterative' implementation strategies (i.e. start using oryx for the pdp components).
Any ideas and suggestions are much welcome!
Heyhey @victor.vanherpt ,
very interesting question and I think nobody can give you the "it-resolves-all" answer here. Also it strongly depends on where the overall experience should lead to and what for resources you have.
So Yves is not known for being very reactive and having a fancy fast UI/UX. Nowadays the main reason for choosing Yves is the way faster go-to-market.
A very strong bottleneck with doing async-stuff directly within Yves-endpoints is the default Symfony session behaviour which locks the session when the php-script starts (somewhere early) and closes it at the end. Which means: You do two background async loading of boxes which will likely trigger every now and then session-lock-exceptions. @Andriy Netseplyayev Do you know if this problem was somewhere solved?
So a more stable way would be imo to make these async calls via Glue Storefront API. The challenge here is the initial cost for setting it up the first time. Also you have to create a mechanism to properly auth and re-auth in the background.
For having a nice reactive UI/UX I would start the migration to a single-page-application (in an ideal world).
So depending on the mid/long-term strategy you could choose a frontend-framework (maybe even Oryx Framework) you want to create your SPA with and start with small components within Yves (so having a hybrid first). If Yves is there to stay in your project I would use as least as possible additional frontend-frameworks to not increase loading time too much.
These were at least my thoughts on this :)
All the best,
Florian
Thanks, Victor and team, for the great ideas and hard work. I appreciate it a lot!
For now I'd like to focus on your current stack, leaving the long-term choice of choosing the frontend technology for you (or another post ;-) ):
session_write_close()
in parts of your code that don't need to change user session info. This helps speed things up by allowing other requests to proceed without waiting. For the dynamic parts like selecting product variants without reloading the page, here are my thoughts:
I hope these suggestions help. It's great to see such innovative thinking from your team!
Kind regards,
Andriy
Thanks @fsmeier , @Andriy Netseplyayev!
Certainly Yves feels a bit limited currently, the glue storefront api feels the right way to go, as you mention, maybe a good excuse to get the glue endpoints setup in our project :)
We'll see what we come up with 😅