Prestashop: [SF Migration] Summary of needed tech improvements for rework of Product Page

[matks]

We're going to rework the Product Page in PS 1.7.8 .

Here is the list of technical issues we need to explore to find a suitable solution able to handle properly the usecase.

Frontend components

1. Image dropzone

On 1st tab, there is a complex and powerful image manager component able to upload, edit and delete images and associated data.

Goal: build a stand-alone, configurable and maintainable JS component able to do all these actions
Actions are

• Add/upload image
• Delete image
• List uploaded images (includes drag-and-drop to choose order)
• Togglable edit panel on selected image

2. Combinations listing and actions (single action, bulk actions)

On "Combinations tab" there is a listing of all combinations for a given product. Today this listing is displayed whole even if it contains thousand of items. Moreover multiple actions are available on the listing items, some targeting a single row and some having bulk behavior.

Goal: build a stand-alone, configurable and maintainable JS component able to handle this listing.
It must provide

• paginations display (being able to query API endpoints to be given "next page" results)
• search feature (API endpoint being queried)
• checkboxes to be used for bulk actions

3.Combinations Generator

There is a component where you select a configuration and it generates combinations for the listing.

Goal: build a stand-alone, configurable and maintainable JS component able to handle this feature.

4.Data synchronization and prices computation in the browser

Some data is duplicated, sometimes directly (same data on 2 tabs), sometimes indirectly on the page (same data but displayed differently on 2 tabs).
So when data 1 is updated, related data 2 must be updated accordingly. Currently there are some issues linked to that.

For example if you modify VAT included price, the VAT excluded must be updated too.

Goal: build a pluggable system that we can use to link fields and be able to describe the relationships between them.
Also need to use a dedicated mathematical JS library to make sure price computations are accurate.

5. Category linking widget

On 1st tab you can link a product to multiple categories and there is a category tree to choose the target categories. It probably breaks when there are too many categories.

Goal: check current categories widget and see how it can scale when given thousand of categories input data.

https://github.com/PrestaShop/PrestaShop/issues/19281

6. Options tab multiple dynamic listings

On last "Options" tab there are multiple tabs that have dynamic content:

• add, list and edit custom fields
• add, list and edit attached files
• suppliers listing (multi-level listing)

Goal: although these are supposed to be simple, it would be nice to have a reusable component for each of them. Or at least shared functions, maybe embedded in different components (so a AjaxListing.js util file for example being used in CustomFieldsListing.js and SuppliersFieldListing.js).

Testing ?

I expect us to iterate over these items multiple times. Having JS tests would be nice to be able to upgrade them without breaking existing behaviors.

[matks]

Let's not forget multistore behavior and RTL behavior 😄

[mickaelandrieu]

Hello,

please let's not add react as we already have Vue, this will make PrestaShop harder to be mastered for no reason.

Lets stick with Vue,

thanks

[NeOMakinG]

React ? Where did you see that ? Can't find it anywhere @mickaelandrieu

[matks]

React ? Where did you see that ? Can't find it anywhere @mickaelandrieu

In my initial post (I edited it since then) I said

Product page must have a rigorous and exhaustive handling of all data displayed and managed to address "synchronization of data around the whole page" issue (=> use of Vue.js ? React.js ?)

I mentioned both examples but obviously we wll stick to Vue.js . I just wanted to list multiple possibilities.

[NeOMakinG]

Ok thanks :)

[zuk3975]

So do we use vue.js for all of these?
If yes, then I suppose we need to decide the architecture for vue?
There already exists new-theme/vue dir which also has components, but we will need the whole product page on vue, so would it follow similar principle new-theme/vue/pages/product ?

[zuk3975]

For the image dropzone.

• I've tried to create dropzone component using vue #18689 (It also contains image crud endpoints which still needs some tweaking but are almost done).
  
  
  
  • Checked @tomas862 pr that uses Dropzone component #15227.
  
  

So far, I think its better to stay with @tomas862 example instead of Vue, because

1. its easier to follow our javascript "conventions" for migrated pages
2. its easier to reuse existing html components (by passing it as template rendered in twig)
3. It seems better to avoid introducing different frameworks in a single page.

_Some things to consider if we use dropzone:_
Docs https://www.dropzonejs.com

1.Image Upload - when using multiple images, the server side endpoint should still be made for single image (should be refactored instead of bulk in #18689) and return image id or image settings in response. The upload should be processed by chunks (sending multiple requests). chunks are supported by Dropzone.

1. Image template and settings - we will need to modify component image template using Dropzone events (check docs previewTemplate and events), so it would add data attribute with image-id or image settings values. So if response returns image settings, we can show the settings form onclick without separate request (which would be better IMO, especially cuz there is just couple values), else we will need another endpoint for each image settings.
   2.1. Image settings translatable input- It should be possible to use FormType (as usual) for product image settings which could contain TranslatableInput, so that we can have a handler for our form in server side. We could try rendering our form in twig as a template and fill its values with image settings in js (similar as we did in order page).

So far these were the main struggles, but it sounds doable with the dropzone component (more convenient than using vue.js at the moment).