empathyco / x Goto Github PK

Commerce Search & Discovery frontend web components

License: Apache License 2.0

JavaScript 0.99% TypeScript 63.93% HTML 5.17% Vue 24.10% SCSS 4.06% Gherkin 1.73% Shell 0.01% CSS 0.01%

javascript vue vuejs typescript search search-engine open-source frontend front-end elasticsearch

x's Introduction

Commerce Search & Discovery: Interface X

Whether you use Empathy Search API endpoints, Elasticsearch, Solr or other search APIs, bring your commerce search and discovery experience to life with Interface X, an irresistible, expressive, and joyful search UI. Interface X is used within some of the most beautiful commerce search experiences out there, e.g. Oysho.com, Carrefour.es, Bosch-Home.es, and Kroger.com.

Interface X is a library of standalone, configurable building blocks (available as Vue.js based X Components) that allow you to quickly construct the search UI for your shop. You can create a smooth, personalized search and discovery experience, while significantly minimizing development time.

Each component represents a graphical part of the UI, with its own unique view and behavior. They’ve been smartly designed to work together yet independently, so a single component adds real value to your UI by itself. The more components you add and combine, the more functionality you get. You can craft your own UI bundle with the right components for your shop. There are numerous components to choose from, and the catalog evolves quickly with new experiences.

See an overview of the Empathy Platform features supported by Interface X.

Highlights

Easy-to-add interface layer. Installing and setting up the interface is simple: just add a few lines of code.
Use it anywhere. A search interface layer that is easy to integrate into any website, with X Components ready to use in your Vue.js and React projects.
Interoperable. Interface X can adapt and work independently with any search service endpoints!
Fully customizable experience. Choose the configuration components, layouts, styles, and behaviors to craft exclusive search and discovery experiences.
Expressive design. Wrap the experience up in a neat, intuitive, and interactive UI design that fully matches your brand identity and your website’s look and feel.
Scalable solution. Extend the experience whenever you want with additional features and components.
Intuitive search. Interface X learns from shopper behavior and queries to understand shopper intent.

About the Interface X ecosystem

Interface X is formed by multiple packages. Watch this space as the project will be updated regularly.

While most of the packages are minor dependencies, there is a key package to bear in mind:

@empathyco/x-components - This is the core package of the project. These standalone and configurable building blocks allow you to quickly build the search UI for your shop. Create a smooth, personalized search and discovery experience, while significantly minimizing development time.

On top of the packages of this monorepo, there is another project using all the X-Components to build a search experience:

@empathyco/x-archetype - This project is Empathy’s vision of the ideal mix of X Components. A project showing the power of the X Components, ready to connect to any search API with customizable layout through design tokens. It is the perfect example to learn how to use the X Components to get you started. This package is now a project outside this monorepo.

Product documentation

Each component contains inline comments. Alternatively, you can read the product documentation on Empathy’s eDocs documentation portal.

Roadmap

We are working on many key features to consolidate Interface X, including these milestones:

Publish extensive documentation covering functional and technical aspects.
Support URL management to set X Components state based on URL parameters.
Create a tagging module to track session interactions without storing PII.
Create the x-adapter to connect to any Search API based on schemas
My History feature, Control your search history and have access to previous intentions.
Use accessibility eslint plugin to improve components a11y.
Next Queries Preview: A set of results that matches searches that other shoppers performed after the current to be show within the SERP. This helps the shopper to discover interesting products after the search action. This represents Empathy sciences for Inspiration and Cross-Selling.
Query Results Preview: Provides a list of results matching a query to be inserted before the shopper starts typing as inspiration, in the predictive layer for results matching the current query, or as inspiration in a no results scenario. If you are facing an Archetype type integration, this is how you set the query preview source of data.
Search box power-ups such as animated suggestions or forbidden character set to prevent code injection.
Create the x-bus, a library that provides an event bus to help with event orchestration.
XDS: Interface X Design System Builder is a Tailwind plugin thought to generate a new design system for every customer, for every search experience look&feel. XDS brings the concept of components to UI as X Components do with functional behavior.
Vectorized Recommendations: These recommendations are relevant product suggestions based on query semantic affinities. They usually show up as product carousels to amaze shoppers with product discovery inspirations.
Filtering Strategies: Added filtering capabilities to History Queries and Brand Recommendations
Experience Controls: Add capability of loading configurations from an external service
Vue 3 Migration.
Network Request failure transparency.
Project generator CLI.
Observability: Error capturing & monitoring.

How to install

This project is a monorepo that is handled by Lerna & pnpm & Nx. To prepare your development environment, proceed as follows:

Install pnpm
Fork the X repository and then clone it to your local environment: git clone https://github.com/empathyco/x.git.
Install the dependencies in the root folder: pnpm install --frozen-lockfile. This links all the projects.

Have a look to this article to see why we moved to a mono repo and how we did it. Take into account that the article talks about the previous version of this monorepo managed by Lerna & npm.

How to implement Interface X

Once you have installed the project, follow the step-by-step guide - How to build your search UI.

Watch Ivan Tajes’ explanation on how to build a search experience using the X Components.

How to contribute

We are building the Interface X ecosystem. If you are interested in helping us out and being part of the future of search experiences, please check our contributing guidelines.

Core Team

Iván Tajes	Javier Iglesias	Jose Antonio Cabañeros	Luís Martínez	Beltrán García
Gerardo Vázquez	Guillermo Cacheda	Mavi Fernández	Diego Pascual	Manuel Navarro
Abraham Pérez	Anna Condal	Álvaro Díaz	Laura Martínez

Contributors

License

Apache 2.0

x's People

Contributors

Stargazers

Watchers

Forkers

lmenezes javiig herrardo ritikbhandari tiborux wannieman98 jtomasdias00 guilleigmu ajperezbau w6e alvaro-formoso-kr yokishava abbijamal diegopf cachedacodes annacv tajespasarela albertjcuac

x's Issues

[FEATURE]: Add guide for setting up developing environment

How can the project be improved?

If we want any developer to be able to contribute to the project we need to have a clear guide on how to do this setup. These are some of the topics that I think can be valuable for new developers.

How does the mono-repo work
Dependencies needed in terms of external tools (XCode devtools in macOS, python, Visual studio in Windows...)
How to install the dependencies
How to run the dev server
How to launch tests

How can this be solved?

No response

Proposed solution

No response

Customizations supported

No response

Additional information

No response

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: As a user, I want results to show another image on hover

How can the project be improved?

The BaseResultImage component is able to show an image, but is not ready to show another on hover.

We would like to provide the possibility to show another image on result image hover.

How can this be solved?

Scenario
Given a shopper who is seeing a result
when the user hovers the result image
then the image is animated to show an alternative image
when the user stops hovering over the image
then the original image is shown

Proposed solution

We can create a computed property images that is calculated with the Result images filtered to exclude the images present in failedImages.

Then we can modify getImageSrc in this way:

get imageSrc(): string {
      return !this.hasEnteredView ?
        ''
        : this.hover && this.images.length > 1
          ? this.images[1]
          : this.images[0];
    }

And activate hover property when the user hovers the image.

Customizations supported

Provide a way no enable&disable the hover behavior, maybe with a prop flipImageOnHover (or other name), for example
Animation required
Try to use composition

Additional information

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: tagging support on banners

How can the project be improved?

At motive, we want to track clicks on banners. We want to take advantage of the logic already implemented on the x-component side so during the development of this feature we find out that the Banner model accept a tagging structure, but it is not working (there's not a request performed when clicking a banner).

How can this be solved?

As far as we looked into it, we found that there's no wiring connection between the banner click event and the tagging config of each banner.

We were able to found a solution on our side, overriding the tagging wiring config and performing the tagging request on our own.

However, we think that this behaviour may fit on product side, so we will be able to decide wether if we want tagging on banners related to the tagging config of each banner.

Proposed solution

Create a wire in which we can perform a tagging request IF there's a tagging config on the banner clicked.
The event emited to x when clicking a banner is UserClickedABanner.

Customizations supported

No response

Additional information

Our own solution:

export const taggingOptions: XModulesOptions['tagging'] = {
  wiring: {
    ...
    UserClickedABanner: {
      trackBannerWire: filter(
        namespacedWireDispatch('tagging')(
          'track',
          ({ eventPayload: { tagging }, metadata: { location } }) => {
            const taggingInfo: TaggingRequest = tagging['click'];
            taggingInfo.params.location = location as string;
            return taggingInfo;
          }
        ),
        ({ eventPayload: { tagging } }) => !!tagging?.['click']
      )
    }
  }
};

and our banner object mapped has something like:

({
    ...
    tagging: {
      click: {
        url: `URL OF TAGGING SERVICE FOR A BANNER CLICK`,
        params: { ... }
      }
    }
 })

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: Rename search-types folder as x-types

How can the project be improved?

Most of the Interface X packages are named with the pattern x-package

The x-types package folder, instead, is named as search-types

How can this be solved?

Renaming the folder search-types to x-types and watching any needed collateral change.

Proposed solution

No response

Customizations supported

No response

Additional information

No response

Code of Conduct

I agree to follow this project's Code of Conduct.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

chore(deps): update all non-major dependencies (@badeball/cypress-cucumber-preprocessor, @cypress/vue2, @microsoft/api-documenter, @microsoft/api-extractor, @types/glob, @types/jest, @types/node, @types/testing-library__jest-dom, @vitejs/plugin-vue2, @vue/devtools-api, @vue/eslint-config-prettier, @vue/eslint-config-typescript, @vue/vue2-jest, @vueuse/core, autoprefixer, concurrently, cypress, esbuild, glob, jest, jest-scss-transform, lerna, postcss, postcss-dir-pseudo-class, postcss-import, rollup, rxjs, sass, start-server-and-test, tailwindcss, ts-jest, ts-node, tslib, typescript, vite, vite-plugin-vue-inspector, vite-plugin-vue2, vue, vue-docgen-cli, vue-property-decorator, vue-template-compiler)
fix(deps): update linters (@typescript-eslint/eslint-plugin, @typescript-eslint/parser, eslint, eslint-config-prettier, eslint-import-resolver-typescript, eslint-plugin-cypress, eslint-plugin-import, eslint-plugin-jest, eslint-plugin-jsdoc, eslint-plugin-react, eslint-plugin-vuejs-accessibility, prettier)
chore(deps): update dependency @types/testing-library__jest-dom to v6
chore(deps): update peter-evans/create-pull-request action to v6
fix(deps): update dependency @vue/eslint-config-typescript to v13
fix(deps): update linters (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser, eslint-config-prettier, eslint-plugin-jsdoc, eslint-plugin-prettier, eslint-plugin-vue, prettier)
Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

Detected dependencies

github-actions

.github/actions/install/action.yml

actions/setup-node v4

pnpm/action-setup v2

cypress-io/github-action v5

.github/actions/release-alpha/action.yml

.github/actions/run-e2e-tests/action.yml

cypress-io/github-action v5

cypress-io/github-action v5

cypress-io/github-action v5

.github/workflows/build.yml

actions/checkout v4

.github/workflows/codeql-analysis.yml

actions/checkout v4

github/codeql-action v3

github/codeql-action v3

.github/workflows/combine-prs.yml

actions/github-script v7

.github/workflows/edocs-dynamic-sync.yml

actions/checkout v4

nelonoel/branch-name v1.0.1

.github/workflows/edocs-preview.yaml

.github/workflows/prepare-release.yml

actions/checkout v4

pnpm/action-setup v2

peter-evans/create-pull-request v5

.github/workflows/publish-release.yml

actions/checkout v4

pnpm/action-setup v2

.github/workflows/release-alpha.yml

actions/checkout v4

pnpm/action-setup v2

npm

package.json

colors 1.4.0

conventional-changelog-conventionalcommits ~5.0.0

cross-env ~7.0.3

eslint ~8.33.0

husky ~8.0.3

lerna ~6.6.0

lint-staged ~13.3.0

prettier ~2.8.3

node >=18

npm >=9

packages/deep-merge/package.json

@empathyco/x-utils ^1.0.3-alpha.1

tslib ~2.6.0

@types/jest ~27.5.0

jest ~27.5.0

rimraf ~3.0.2

ts-jest ~27.1.0

ts-node ~10.9.1

typescript ~4.9.4

node >=18

packages/eslint-plugin-x/package.json

@typescript-eslint/eslint-plugin ~5.49.0

@typescript-eslint/parser ~5.49.0

@vue/eslint-config-prettier ^7.0.0

@vue/eslint-config-typescript ~11.0.0

eslint-config-prettier ^8.5.0

eslint-import-resolver-typescript ~3.5.2

eslint-plugin-cypress ~2.12.1

eslint-plugin-import ~2.27.5

eslint-plugin-jest ~27.2.0

eslint-plugin-jsdoc ~39.6.4

eslint-plugin-prettier ^4.2.1

eslint-plugin-tsdoc ~0.2.17

eslint-plugin-vue ~8.7.1

eslint-plugin-vuejs-accessibility ~2.0.0

eslint ~8.32.0

prettier ~2.8.3

eslint ~8.32.0

prettier ^2.0.5

node >=18

packages/jest-utils/package.json

@types/jest ~27.5.0

jest ~27.5.0

ts-jest ~27.1.0

typescript ~4.9.4

node >=18

packages/logger/package.json

tslib ~2.6.0

@types/jest ~27.5.0

jest ~27.5.0

ts-jest ~27.1.0

typescript ~4.9.4

node >=18

packages/react-wrapper/package.json

tslib ~2.6.0

@types/jest ~27.5.0

cypress ~13.6.0

eslint-plugin-react ~7.32.1

jest ~27.5.0

start-server-and-test ~2.0.0

ts-jest ~27.1.0

typescript ~4.9.4

vite ~4.5.0

vue ~2.7.14

vue ^2.6.0

node >=18

packages/storage-service/package.json

@empathyco/x-logger ^1.2.0-alpha.11

tslib ~2.6.0

@types/jest ~27.5.0

jest ~27.5.0

ts-jest ~27.1.0

typescript ~4.9.4

node >=18

packages/x-adapter-platform/package.json

@empathyco/x-adapter ^8.0.3-alpha.1

@empathyco/x-types ^10.1.0-alpha.2

@empathyco/x-utils ^1.0.3-alpha.1

tslib ~2.6.0

@microsoft/api-documenter ~7.23.0

@microsoft/api-extractor ~7.39.0

@types/jest ~27.5.0

concurrently ~8.2.0

jest ~27.5.0

rimraf ~3.0.2

ts-jest ~27.1.0

typescript ~4.9.4

node >=18

packages/x-adapter/package.json

@empathyco/x-deep-merge ^2.0.3-alpha.1

@empathyco/x-utils ^1.0.3-alpha.1

tslib ~2.6.0

@types/jest ~27.5.0

concurrently ~8.2.0

jest ~27.5.0

rimraf ~3.0.2

ts-jest ~27.1.0

typescript ~4.9.4

node >=18

packages/x-archetype-utils/package.json

@empathyco/x-deep-merge ^2.0.3-alpha.1

tslib ~2.6.0

vue-i18n ~8.28.2

@types/jest ~27.5.0

@types/node ~18.19.0

@vue/test-utils ~1.0.3

jest ~27.5.0

rimraf ~3.0.2

rollup ~4.9.1

rollup-plugin-copy ~3.5.0

rollup-plugin-delete ~2.0.0

rollup-plugin-typescript2 ~0.36.0

ts-jest ~27.1.0

typescript ~4.9.4

vue ~2.7.14

vue ^2.7.0

vue-i18n ^8.0.0

node >=18

packages/x-bus/package.json

@empathyco/x-priority-queue ^1.0.3-alpha.1

@empathyco/x-utils ^1.0.3-alpha.1

rxjs ~7.8.0

tslib ~2.6.0

@types/jest ~27.5.0

concurrently ~8.2.0

jest ~27.5.0

rimraf ~3.0.2

ts-jest ~27.1.0

typescript ~4.9.4

node >=18

packages/x-components/package.json

@empathyco/x-adapter ^8.0.3-alpha.1

@empathyco/x-adapter-platform ^1.1.0-alpha.1

@empathyco/x-bus ^1.0.3-alpha.1

@empathyco/x-deep-merge ^2.0.3-alpha.1

@empathyco/x-logger ^1.2.0-alpha.11

@empathyco/x-storage-service ^2.0.3-alpha.0

@empathyco/x-types ^10.1.0-alpha.2

@empathyco/x-utils ^1.0.3-alpha.1

@vue/devtools-api ~6.5.0

@vueuse/core ~10.7.1

js-md5 ^0.8.3

rxjs ~7.8.0

tslib ~2.6.0

vue-class-component ~7.2.6

vue-global-events ~1.2.1

vue-property-decorator ~8.5.0

vue-runtime-helpers ~1.1.2

@badeball/cypress-cucumber-preprocessor ~20.0.0

@bahmutov/cypress-esbuild-preprocessor ~2.2.0

@cypress/vue2 ~2.0.1

@empathyco/x-tailwindcss ^1.2.0-alpha.2

@microsoft/api-documenter ~7.23.0

@microsoft/api-extractor ~7.39.0

@rollup/plugin-commonjs ~25.0.7

@testing-library/jest-dom ~5.17.0

@types/autoprefixer ~10.2.0

@types/glob ^8.0.1

@types/jest ~27.5.0

@types/node ~18.19.0

@types/testing-library__jest-dom ~5.14.5

@vitejs/plugin-vue2 ^2.2.0

@vue/test-utils ~1.0.3

@vue/vue2-jest ~27.0.0-alpha.3

autoprefixer ~10.4.4

convert-source-map ~2.0.0

cypress ~13.6.0

esbuild 0.20.0

glob ~10.3.0

jest ~27.5.0

jest-scss-transform ~1.0.1

postcss ~8.4.12

postcss-dir-pseudo-class ~7.0.0

postcss-logical ~4.0.2

rimraf ~3.0.2

rollup ~4.9.1

rollup-plugin-copy ~3.5.0

rollup-plugin-delete ~2.0.0

rollup-plugin-styles ~4.0.0

rollup-plugin-typescript2 ~0.36.0

rollup-plugin-vue ~5.1.9

sass ~1.70.0

start-server-and-test ~2.0.0

tailwindcss ~3.4.0

ts-jest ~27.1.0

ts-node ~10.9.1

typescript ~4.9.4

vite ^4.5.0

vite-plugin-vue-inspector ^4.0.0

vue ~2.7.14

vue-docgen-cli ~4.67.0

vue-router ~3.6.5

vue-template-compiler ~2.7.14

vuex ~3.6.2

vue ~2.7.0

vuex ^3.0.0

node >=18

packages/x-priority-queue/package.json

@empathyco/x-utils ^1.0.3-alpha.1

tslib ~2.6.0

@types/jest ~27.5.0

concurrently ~8.2.0

jest ~27.5.0

rimraf ~3.0.2

ts-jest ~27.1.0

typescript ~4.9.4

node >=18

packages/x-svg-converter/package.json

@types/jest ~27.5.0

@types/node ~18.19.0

jest ~27.5.0

rimraf ~3.0.2

ts-jest ~27.1.0

typescript ~4.9.4

node >=18

packages/x-tailwindcss/package.json

@empathyco/x-deep-merge ^2.0.3-alpha.1

@empathyco/x-utils ^1.0.3-alpha.1

tslib ~2.6.0

@rollup/plugin-commonjs ~25.0.7

autoprefixer ~10.4.4

postcss ~8.4.12

postcss-import ~16.0.0

rimraf ~3.0.2

rollup ~4.9.1

rollup-plugin-typescript2 ~0.36.0

rollup-plugin-vue ~5.1.9

tailwindcss ~3.4.0

typescript ~4.9.4

vite ~4.5.0

vite-plugin-vue2 ~2.0.2

vue ~2.7.14

vue-class-component ~7.2.6

vue-property-decorator ~8.5.0

vue-template-compiler ~2.7.14

vue ^2.7.0

vue-class-component ^7.1.0

vue-property-decorator ^8.3.0

node >=18

packages/x-translations/package.json

@empathyco/x-deep-merge ^2.0.3-alpha.1

@types/jest ~27.5.0

@types/node ~18.19.0

jest ~27.5.0

ts-jest ~27.1.0

typescript ~4.9.4

node >=18

packages/x-types/package.json

@empathyco/x-adapter ^8.0.3-alpha.1

@empathyco/x-utils ^1.0.3-alpha.1

tslib ~2.6.0

@empathyco/x-jest-utils ^1.4.0-alpha.11

@microsoft/api-documenter ~7.23.0

@microsoft/api-extractor ~7.39.0

@types/jest ~27.5.0

jest ~27.5.0

rollup ~4.9.1

rollup-plugin-delete ~2.0.0

rollup-plugin-typescript2 ~0.36.0

typescript ~4.9.4

node >=18

packages/x-utils/package.json

@empathyco/x-storage-service ^2.0.3-alpha.0

tslib ~2.6.0

@types/jest ~27.5.0

jest ~27.5.0

rimraf ~3.0.2

ts-jest ~27.1.0

typescript ~4.9.4

node >=18

Check this box to trigger a request for Renovate to run again on this repository

[BUG]: Project does not compile in windows systems

Environment affected

Windows OS

Description

X-Components build is generating import statements in style related files that contain paths with backslashes. This causes that paths that contain strings such as\src are really importing from \ rc (note the \s is transformed into an space).

Current behavior and expected result

X-Components should compile on windows

Steps to reproduce

Try to compile the prooject on a windows machine.

Package affected

@empathyco/x-components

Supporting information

No response

Code of Conduct

I agree to follow this project's Code of Conduct

[FEATURE]: Enable / Disable History Queries

How can the project be improved?

As a part of the Privacy Controls / My History feature, we will need to provide a way to enable/disable the History Queries. By default, the History Queries are enabled because all the Empathy customers have this feature enabled.

This is not to create the Switch Button. Only the methods and wiring to accomplish the task, and then we can place two buttons to dispatch the Events to enable/disable.

How can this be solved?

When the shopper disables the history queries:

Removes all the History Queries from Local Storage
Updates the History Queries state in Local Storage

When the shopper enables

Updates the History Queries state in Local Storage

Proposed solution

Wiring

UserClickedHistoryQueriesSwitch -> toggleHistoryQueries
HistoryQueriesEnabled -> saveIsEnabledToLocalStorage
HistoryQueriesDisabled -> clearHistoryQueries, saveIsEnabledToLocalStorage

State

isEnabled: boolean (add to Alias API)

Emitters

isEnabled:

When true → HistoryQueriesEnabled
When false → HistoryQueriesDisabled

Customizations supported

No response

Additional information

This is not to create the Switch Button. Only the methods and wiring to accomplish the task, and then we can place two buttons to dispatch the Events to enable/disable.

Code of Conduct

I agree to follow this project's Code of Conduct.

[FIX]: Rename event to be a typed XEvent

How can the project be improved?

Change name of Event that is not a X Event to use the proper one.

How can this be solved?

In empathize.vue

@Prop({
      default: () => [
        'UserClosedEmpathize',
        'UserSelectedASuggestion',
        'UserPressedEnter',
        'UserBlurredSearchBox'
      ]
    })
    protected eventsToCloseEmpathize!: XEvent[];

we need to change UserPressedEnter to UserPressedEnterKey and type the prop default value properly.

Proposed solution

No response

Customizations supported

No response

Additional information

No response

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: Clarify support of external dependencies (Python, XCode devtools, Windows Visual Studio...)

How can the project be improved?

Apparently for installing the project we need to have some external dependencies installed, such as python, XCode devtools, or Visual Studio in Windows systems. This is not specified anywhere and we don't know were this requirements come from.

Investigate why we need this dependencies, and list them.
For each one of them, Can it be removed? Otherwise, justify why it is needed.

This issue is just to track this decisions. Separate tasks will be created in case the project needs to be modified.

How can this be solved?

No response

Proposed solution

No response

Customizations supported

No response

Additional information

No response

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: As a user, I want the MyHistory component to show history queries grouped by date(day)

How can the project be improved?

The goal is to provide the same functionality in Interface X Web that we showed on Linkedin Live for Interface X Android.

To achieve this goal we need to provide MyHistory component of a way to group the History Queries in a chronological order grouped by day to meet the design requirements. Note that the task is not to apply this design, but get the My History ready to show the history queries grouped and apply designs in the future.

How can this be solved?

No response

Proposed solution

Create a computed that returns the new history queries grouped by date
Create new type to store the data
Change the component to print the new history queries grouped.

Customizations supported

Should we take into account the locale to format the timestamp? Yes, use the lang from the snippet for the locale

Additional information

Should we create a prop or something to show or not the time/date? or we should add it always?

Code of Conduct

I agree to follow this project's Code of Conduct.

[BUG]: Remove pnpm explicit version when pnpm bug is solved

Environment affected

CI/CD

Description

This bug pnpm/pnpm#6991 forced us to select the 8.6.0 version of pnpm in the GitHub Actions in this PR: #1268

We should remove the explicit version and go back to version 8 when the bug is solved.

Current behavior and expected result

CICD is not failing at install step

Steps to reproduce

Try to pass CICD pipeline in Github

Package affected

All of them

Supporting information

No response

Code of Conduct

I agree to follow this project's Code of Conduct

[FEATURE]: Add support to React.context to the ReactWrapper

How can the project be improved?

The React Wrapper library allows wrapping a Vue component inside a React Component. These React components are ready to work with props, events, slots, scoped slots... but no context.

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

In a typical React application, data is passed top-down (parent to child) via props, but such usage can be cumbersome for certain types of props that are required by many components within an application. Context provides a way to share values like these between components without having to explicitly pass a prop through every level of the tree.

React.context documentation

Simple example of use

How can this be solved?

No response

Proposed solution

No response

Customizations supported

No response

Additional information

No response

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: Avoid forbidden characters in the search box

How can the project be improved?

Avoid forbidden characters in the search box in order to prevent security issues such as XSS through code injection

How can this be solved?

Given a shopper typing in the search-box component
when the shopper types forbidden characters like < or >
then the search box prevents the acceptance of this characters
and nothing changes in the search box.

Proposed solution

Add a config to the SearchBox module to pass the characters to be forbidden.

Customizations supported

No response

Additional information

This is the location of the search-box module

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: Create new Highlight component to highlight part of a string

How can the project be improved?

Create a new Highlight component to be in charge of highlighting the part of a suggestions that matches the current query in the search box.

How can this be solved?

The code is already written, but as part of other components.

Proposed solution

Extract the highlight logic from the BaseSuggestion component into a new <Highlight :value="stringToHighlight" highlight="highlight" /> component. The name of the prop is just a suggestion, you can look for a better name.

This component can then be used only in components that should support highlighting, like QuerySuggestion or HistoryQuery. But not by default in NextQuery or PopularSearch.

Customizations supported

No response

Additional information

No response

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: My History dates locale should rely on uiLang

How can the project be improved?

Some commits ago, the uiLang parameter was added to the SnippetConfig.

This was made because now, the requests to the APIs rely in lang parameter, and if exist the lang shown by the UI components rely in the new uiLang parameter, so the components can have different locale for requests and UI using both parameters.

How can this be solved?

Change the MyHistory component to show dates based in uiLang instead of lang as locale.

Proposed solution

No response

Customizations supported

No response

Additional information

Make the first character of the date always uppercase to show

Miércoles, 19 de octubre de 2022

instead of

miércoles, 19 de octubre de 2022

In English the first is uppercase, but just because names of days and months are uppercase in English and toLocaleDateString is setting that in the right way. But in Spanish, or other languages, even if the name of the day is correctly written in lowercase, we would like to start the sentence in uppercase.

Code of Conduct

I agree to follow this project's Code of Conduct.

query to get all elements

what should I specify in the query to get all elements without filters?

[FEATURE]: support max-len in Vue components

How can the project be improved?

In the Playboard team, we use the eslint-plugin-x and during development, we found out that eslint with its max-len rule and prettier didn't work together. The main problem is there are some cases that prettier doesn't want to transform the code even when the code's length surpasses the limit.

Some cases:

Strings length (e.g: long imports paths, long attribute names in vue files, long describe() titles, long URL ). Further info
Template Literals when there are some expressions inside prettier doesn't do a wrap transformation itself. It is a known discussion topic of the prettier formatter.

imports { foo } from 'very-long-long-long-long-long-long-long-long-long-import-path'; // ERROR: eslint max-len

const x = `${msgs?.explanation1}<br>${msgs?.explanation2}<ul><li>"${promotions[0].title}" with queries: ${promotions[0].keywords[0]}</li></ul>`// ERROR: eslint max-len

describe('very-long-long-long-long-long-long-long-long-long-long-title')// ERROR: eslint max-len

CSS long lines. There are some cases in that you can not add a line break.

@include example( 'very-long-long-long-long-long-long-long-long-long-long-class');

long attributes in Vue components. There are some cases that you can not add a line break in an attribute.

<div  class="example-component example-component--expanded">

<path
   d="M11 .5c-1.7.2-3.4.9-4.7 2-1.1.9-2 2-2.5 3.2-1.2 2.4-1.2 5.1-.1 7.7 1.1 2.6 2.8 5 5.3 7.5 1.2 1.2 2.8 2.7 3 2.7 0 0
/>"

How can this be solved?

Make the linter ignore strings
Make the linter ignore template literals
Make the linter ignore long CSS lines inside Vue
Make the linter ignore Vue components' attributes

Proposed solution

In Play team core repository we defined a configuration in .eslintrc.js which solved these issues.

We ignored all the strings with the ignoreStrings flag.
We ignored all the template literals with the ignoreTemplateLiterals flag.
We also ignored all the URLs, because there were some big urls in the play-core repository.
We also ignore attribute length in Vue components with the ignoreHTMLAttributeValues flag.

Customizations supported

I would suggest using our approach or something along those lines in eslint-plugin-x so everyone could have a general config that solves these issues.

Suggestions:

Do an override in .vue files, which disabled the original max/len but used the extended one vue/max-len

{
      files: ['*.vue'],
      rules: {
        'max-len': 'off',
        'vue/max-len': [
          'error',
          {
           ignoreStrings: true,
           ignoreTemplateLiterals: true,
            ignoreUrls: true,
            ignoreHTMLAttributeValues: true
          }
        ]
      }

Change config for max-len

{
  rules: {
      'max-len': ['error', {
                         ignoreStrings: true,
                         ignoreTemplateLiterals: true,
                         ignoreUrls: true      
                         }],
  }
}

Additional information

Previously prettier would have formatted this with one class per line. like so:

 <div class="example-component
                        example-component--expanded
                         example-component--collapsed"
  >

But it is no longer an option since [email protected].

Further info:

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: Create Full History Queries Component

How can the project be improved?

Currently Interface X offers a HistoryQueries component which is a list of previous searches. This list gets the data from a getter that filters the list of queries by the current query, the one that the shopper has typed in the search box.

In order to provide a new full history queries view, in a new panel/modal where the shopper can access not the last ones inside the predictive layer, but to all the queries stored in the device in a new panel/modal, we need a new component that doesn't filter the current queries.

How can this be solved?

Creating a new component. This could be made in the same HistoryQueries component, but, the two components will differ in the Future as the Full History will have some grouping and features not necessary in the current component.

Proposed solution

Create a new component in the history-queries modules named full-history-queries.vue/raw-history-queries or something similar. Or change the old one to be filtered-history-queries and this new one history-queries.

This component will be a copy of the actual history-queries.vue component, but we have to change the source from where it takes the data from a getter to get it from the state.

/**
 * The list of history queries.
 *
 * @internal
 */
 @State('historyQueries', 'historyQueries')
 public historyQueries!: HistoryQueryModel[];

Add testing

Customizations supported

The customization will be addressed in future tasks.

Additional information

No response

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: As a shopper, I want the search box to have an animated placeholder

How can the project be improved?

To have an animated placeholder showing different messages to inspire the shopper to type different types of queries.

AnimatedPlaceholder.mov

Even though in the video only one part of the string is animated, the idea is to animate the whole string to make things easier. So find won't be in a fixed position and will move with the rest of the string.

How can this be solved?

Hover scenario

Given a shopper who is going to type in the search box
when the user hovers the search box
then the placeholder is animated showing different messages
when the user clicks on the search box and the input get focused
then the placeholder disappears to start typing.

Normal scenario

Given a shopper who is going to type in the search box
then the placeholder is animated showing different messages
when the user clicks on the search box and the input get focused
then the placeholder disappears to start typing.

Proposed solution

An idea could be to create a SearchInputPlaceholder component that can coexist with the SearchInput component.

Customizations supported

The text of the messages have to be configurable
The number of different texts is configurable
The animation can happen on hover
The animation can happen before the hover

Additional information

This is the module where this task has to be done: https://github.com/empathyco/x/tree/main/packages/x-components/src/x-modules/search-box

SearcInput documentation

Have a look at the Contributing Guidelines ;)

Code of Conduct

I agree to follow this project's Code of Conduct.

[FEATURE]: As a shop manager, I'd like to promote my products using product labels

How can the project be improved?

Motive currently processes their "Out of stock" label with logic on the front-end side, and uses just a <span> element.

To offer more possibilities of label customization in the future, we'd like to change it so that backend indexes products with their respective labels, and frontend receives those labels and chooses how to display them given their information. This allows us to display labels for information the search layer doesn't receive, like the actual stock amount (we just get 0 or 1) or the shop's custom attributes.

How can this be solved?

Inside of the product object received in the search response, we'll get something like this (key names not final):

"product_labels":[
   {
   		"id":"out_of_stock",
   		"text":"Out of stock until december"
   },
   {
   		"id":"on_sale",
   		"text":"Sale!!!"
   },
]

Front will then show the first of the given labels in the top-right corner, styled by CSS (for now).

Proposed solution

We believe a new Component can be added that receives all customization information (described below) and changes its style to match.

This new label Component's position inside the Product Card will be the responsibility of ___.

Customizations supported

These are all possible future improvements and customizations, that we may or may not get to do.

We'd like to add to the label information, to inform the display of it in the frontend:

Label font color
Label background color
Label position: Top-right, Top-left, Bottom-right, Bottom-left, Bottom

A label showing the sale % is also wanted, where the user can input text and some of it will be replaced by the item sale percentage. For example, Now {discount_percent}% off! would become "Now 50% off!". This could also extend to Now {discount_amount}€ off! would become "Now 2.50€ off!"

Also seen in other shops, some labels may have a tooltip on hover. In Motive there are no plans to implement this.

Additional information

Figma (may not be reachable without an Empathy.co account).

Current implementation.

Feature requests received by Motive customers (may not be reachable without an Empathy.co account).

Code of Conduct

I agree to follow this project's Code of Conduct.