Dynamic Frontend Strategies for Yves?

victor.vanherpt

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 ( https://docs.spryker.com/docs/dg/dev/frontend-development/202311.0/yves/atomic-frontend/atomic-frontend.html#components

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!

fsmeier

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

Andriy Netseplyayev

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 ;-) ):

• For quicker web pages, sometimes Yves gets slowed down by session locks when handling multiple requests, as Florian correctly pointed. Why locks are needed - you can find more information here. To mitigate this, use 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.
• Considering Glue alongside Yves is smart for future changes, like moving to an API-first approach. Since Glue is headless (works without a traditional web interface and cookies) and doesn't use the same session storage, you'll need to tweak how things like the shopping cart work. Think about using a permanent storage solution and making sure users can be recognized in both Yves and Glue systems (token vs. cookie). For the start, it's simpler to focus on functionalities that are customer-agnostic.
• Keep in mind that using many small components in your design (atomic design) might slow things down because of the time it takes to render everything together (twig). If speed is very important, try simplifying pages with too many parts.

For the dynamic parts like selecting product variants without reloading the page, here are my thoughts:

• Your idea of loading all variant data upfront and updating the page with JavaScript sounds good. It can make the page feel faster and more responsive.
• Using Glue to fetch product details when needed is also a great approach, especially if you haven't used Glue much before. It could be a good start.
• For the add-to-cart and variant selection without reloading the page, consider which approach fits better with how you plan to use Yves and Glue together.

I hope these suggestions help. It's great to see such innovative thinking from your team!

Kind regards,

Andriy

victor.vanherpt

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 😅