...

• The audit process starts when the user clicks on the "Audit Restaurants" button in the /restaurants page

• The user will be sent to a new route /audit-products (name to be defined/confirmed with UX team)

• On this new page, we'll show the new products table for the audit restaurants experience

  • If the user goes out to another page or cancels the operation, he’ll need to restart the audit process again

  • We want this experience for now to be close to what we already have on the /editor flow

• Besides the ability to filter what's been presented on the table, the user can also download products status (the filtered products to a CSV file)

To understand the complete flow check this Figma: pending info

Check the proposed solution to understand the navigation, technically speaking: https://rbictg.atlassian.net/wiki/spaces/IBC/pages/5243863171/DRAFT+-+Solution+Audit+unavailable+products+on+DOP#New-front-end-page-development

...

Today we already know that the application has performance problems to deal with big content on the table (high loadings, slowness, etc.). To deal with this problem, we have the following proposals:

1. To-do

2. To-do

✅ Proposed Solution

New front end page development

...

• Create a new component for the audit products table

  • This new component can be based on the current frontend/src/pages/products/products-content/ProductsContent.tsx implementation

  • Our new table will be similar to this one, but

    • We want a better experience, not a copy/paste

    • We’ll have new columns (besides the current ones in the products table)

      • Restaurant

      • Availability

      • Date

  • To filter the table we’ll need the following filters

    • Search products text field

    • Restaurant

    • Service mode

    • Type

    • Section

    • Availability

• Create a new store property to manage the related state

  • Motivation: isolate and separate responsibilities. Let’s the current products state untouched (the menu store).

  • The new “Download products Status” button lives in the application header. We’ll need to save in memory the products filtered result to be able to generate the CSV when clicking in the header button

export interface AuditProductsState {
  auditableProducts: Record<string, desiredFragmentHere>;
}

/**
 * Audit products redux store
 */
export const auditProducts = createModel<RootModel>()({
  state: {
    auditableProducts: false,
    filters: {
      // any desirable filter, if we want
    },
  } as AuditProductsState,

  reducers: {
    /**
     * Method to set the auditableProducts
     */
    setAuditableProducts(state, payload: desiredProductsInterface) {
      return { ...state, auditableProducts: payload };
    },

    // any other filter reducer if necessary
  },

  selectors: slice => ({
    auditableProducts() {
      return slice(state => state.auditableProducts);
    },
  }),
});

import { Models } from '@rematch/core';

// ...rest of the code
import { auditProducts } from './audit-products';

export interface RootModel extends Models<RootModel> {
  // ...rest of the code
  auditRestaurants: typeof auditProducts;
}

export const models: RootModel = {
  // ...rest of the code
  auditProducts,
};

Front end to-do: Do we need a pagination system? The solutions to deal with performance problems and queries will answer that.

...

Today the app depends on data from different places to have the products complete data (considering availability, etc). I'll let here just an example of how the data flow is working for the products page/editor flow → This is only intended for the discovery/draft phase. We can delete this text and the image below later.

...

To-do: proposals to solve this data composition/orchestration layer for the new page and products data

# 1 - To-do

📈 Metrics

...