...

• 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 to represent the new audit page (suggestion: AuditRestaurantProducts)

  • We need to include the common structure for pages following the current pattern

  • Create a new component to show the header with the new button “Download products status”

    • We’ll need to get here any state related data to download the products status

    • We’ll use the PageHeader as main container (ex: PaymentMethodsHeader)

  • Create a new component to show the footer (suggestion: AuditProductsFooter)

    • On this footer, we’ll only have the cancel button that will send the user back to the /restaurants page

  • Adjust the EditorBar component to show the new “Audit Restaurants” button

    • This button will only be shown if we’re on the /restaurants page, groups tab, and select at least one group there

...

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 querie section will answer that.

• Note: If yes, as a suggestion, we can consider using the Material UI pagination component because it is very flexible and we can customize the visuals if we want (the app appears to lack a pagination component for the tables). This library is already in use in other applications, like admin-app, so it’s approved for use.

Solutions to deal with performance problems and queries

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 solution 1

📈 Metrics

...