feat(headless): TriggerRedirection #875

nbuissoncoveo · 2021-06-09T16:58:00Z

https://coveord.atlassian.net/browse/KIT-548

Just a draft to make sure I'm on the right track

https://coveord.atlassian.net/browse/KIT-548

nbuissoncoveo · 2021-06-09T16:59:52Z

packages/headless/src/features/redirection/redirection-slice.ts

+        const redirectTriggers: Trigger[] = action.payload.response.triggers.filter(
+          (trigger) => isTriggerRedirect(trigger)
+        );
+        state.redirectTo = (redirectTriggers[0] as TriggerRedirect).content;


I wasn't sure how to handle the fact that response.triggers is an array of Trigger objects and that there might be multiple TriggerRedirect objects in the array.

It's good to filter, be careful thought, because not all responses contain triggers, even less redirect triggers

nbuissoncoveo · 2021-06-09T17:02:11Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+}
+
+const optionsSchema = new Schema({
+  function: new Function(),


I have a compilation error on this line that I don't understand: Type 'Function' is missing the following properties from type 'SchemaValue<unknown>': validate, default, required

We don't have anything in Bueno I think, it only needs to be defined, perhaps this would work, it would have to be tested

Suggested change

function: new Function(),

onRedirect: new Value({required: true}),

nbuissoncoveo · 2021-06-09T17:03:20Z

Completed the controller's initial structure but I'm a bit confused about which actions the controller should have.

ThibodeauJF · 2021-06-09T17:57:44Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+  /**
+   * The function used to handle whenever the `Redirection` controller's state's `redirectTo` value changes.
+   */
+  function: Function;


I would pick something more significant as a name, like onRedirect

Suggested change

function: Function;

onRedirect(): void;

ThibodeauJF · 2021-06-09T18:00:12Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+}
+
+const optionsSchema = new Schema({
+  function: new Function(),


We don't have anything in Bueno I think, it only needs to be defined, perhaps this would work, it would have to be tested

Suggested change

function: new Function(),

onRedirect: new Value({required: true}),

ThibodeauJF · 2021-06-09T18:01:16Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+}
+
+/**
+ * A scoped and simplified part of the headless state that is relevant to the `Pager` controller.


Suggested change

* A scoped and simplified part of the headless state that is relevant to the `Pager` controller.

* A scoped and simplified part of the headless state that is relevant to the `RedirectionTrigger` controller.

ThibodeauJF · 2021-06-09T18:01:23Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+/**
+ * The `Redirection` controller handles redirection actions.
+ */
+export interface Redirection extends Controller {


Suggested change

export interface Redirection extends Controller {

export interface RedirectionTrigger extends Controller {

Also complete the name for other interfaces/methods

ThibodeauJF · 2021-06-09T18:02:40Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+
+    get state() {
+      return {
+        redirectTo,


you have to extract the state from the engine's state

ThibodeauJF · 2021-06-09T18:03:14Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+  validateOptions,
+} from '../../utils/validate-payload';
+
+export interface RedirectionInitialState {


there should be no initial state for that controller since it's triggered later depending on the response

ThibodeauJF · 2021-06-09T18:04:40Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+    props.initialState,
+    'buildRedirection'
+  );
+  const redirectTo = initialState.redirectTo;


We should not save local variables in controllers if possible and use the engine's state instead to save values

ThibodeauJF · 2021-06-09T18:06:15Z

packages/headless/src/features/redirection/redirection-slice.ts

+        const redirectTriggers: Trigger[] = action.payload.response.triggers.filter(
+          (trigger) => isTriggerRedirect(trigger)
+        );
+        state.redirectTo = (redirectTriggers[0] as TriggerRedirect).content;


It's good to filter, be careful thought, because not all responses contain triggers, even less redirect triggers

ThibodeauJF · 2021-06-09T18:09:04Z

Good for the scaffold, its still missing the most important part: to call the method (onRedirect) at the right moment, when a redirect trigger is returned by the API

https://coveord.atlassian.net/browse/KIT-548

ThibodeauJF

I would consider using tests or Atomic or React code samples (packages/samples/headless-react) to make sure the feature works as expected while you implement it.

We will have to add RedirectionTrigger components to both Atomic & the react samples nevertheless

ThibodeauJF · 2021-06-10T11:53:05Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+
+export interface RedirectionTriggerOptions {
+  /**
+   * The function used to handle whenever the `Redirection` controller's state's `redirectTo` value changes.


Suggested change

* The function used to handle whenever the `Redirection` controller's state's `redirectTo` value changes.

* The function used to handle whenever the `RedirectionTrigger` controller's state's `redirectTo` value changes.

also in other tsdocs

ThibodeauJF · 2021-06-10T11:56:27Z

packages/headless/src/features/redirection/redirection-slice.ts

+        state.redirectTo = action.payload;
+      })
+      .addCase(executeSearch.fulfilled, (state, action) => {
+        const redirectTriggers: Trigger[] = action.payload.response.triggers.filter(


What if you don't set the type to Trigger, will it take on the TriggerRedirect type?

I thought I had to specify the type, any does not seem to work. isTriggerRedirect only accepts params of the type Trigger so I don't see how I would be able to filter for only TriggerRedirect objects.

Should the triggers feature live in it's own slice?

It seems like a single state property now gets it's value from two different api calls (/plan and /search). I think we should separate the two concerns,

Are you thinking of doing one slice for all the triggers or having one slice per type of trigger?

I was thinking one slice for all triggers, however it would be a good to spend some time documenting the design, comparing pros and cons of different approaches,

I think we should create a separate slice for triggers.

As is, if someone is using a standalone search box and a trigger, if the plan endpoint returns a url, then headless would log a redirection trigger event to UA which would be incorrect.

Goind point, agreed, the said slice's state should be split into the triggers types.

A con: would the redirection-slice become misleading then, if it's not affected by trigger on the /search call, but only on the /plan call ?

ThibodeauJF · 2021-06-10T11:59:16Z

packages/headless/src/features/redirection/redirection-slice.ts

+        state.redirectTo = redirectTriggers
+          ? (redirectTriggers[0] as TriggerRedirect).content
+          : '';


You should check the length of the array, see if any is filtered, the array should always be defined, but it won't always contain elements. I don't think you should need the typecast, as per my previous comment

Suggested change

state.redirectTo = redirectTriggers

? (redirectTriggers[0] as TriggerRedirect).content

: '';

state.redirectTo = redirectTriggers.length

? redirectTriggers.content

: '';

ThibodeauJF · 2021-06-10T12:05:25Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+  /**
+   * The function used to handle whenever the `Redirection` controller's state's `redirectTo` value changes.
+   */
+  onRedirect(): void;


The method could return the string of the redirectTo, but since it's already returned in the state, it's not really necessary, user will be able to access it.

Question of preference

ThibodeauJF · 2021-06-10T12:12:00Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+    'buildRedirectionTrigger'
+  ) as Required<RedirectionTriggerOptions>;
+
+  const redirectTo = engine.state.redirection.redirectTo!;


Here, you only access the state value once, when the buildRedirection method is called, but it's not updated each time the engine state's changes. Here a few cues:

this line could be a method, returning the state, so every time it's called it's the current state

when you make the comparison, at line 78, it's with that original value, but it's never compared further, consider using the engine.subscribe method, you can also override the controller's own subscribe method, like it's done for headless-url-manager.ts

https://coveord.atlassian.net/browse/KIT-548

github-actions · 2021-06-10T15:57:13Z

Pull Request Report

PR Title

❌ Title should follow the conventional commit spec:

(optional scope):

Example:

feat(headless): add result-list controller

Bundle Size

File	Compression	Old (kb)	New (kb)	Change (%)
dist/browser/headless.js	bundled	529.2	535.9	1.3
	minified	218.3	220.7	1.1
	gzipped	62.4	63	0.9
dist/browser/headless.esm.js	bundled	512.7	519.1	1.2
	minified	280	283.8	1.4
	gzipped	68.4	69	0.9
dist/browser/case-assist/headless.js	bundled	0.5	0.5	0
	minified	0.3	0.3	0
	gzipped	0.2	0.2	0
dist/browser/case-assist/headless.esm.js	bundled	0.1	0.1	0
	minified	0	0	0
	gzipped	0.1	0.1	0
dist/browser/recommendation/headless.js	bundled	351.8	352.2	0.1
	minified	156.2	156.4	0.1
	gzipped	45.3	45.3	0.1
dist/browser/recommendation/headless.esm.js	bundled	342.7	343.1	0.1
	minified	193.1	193.4	0.1
	gzipped	49.5	49.5	0.1
dist/browser/product-recommendation/headless.js	bundled	347.1	347.5	0.1
	minified	154	154.2	0.1
	gzipped	44.7	44.8	0.1
dist/browser/product-recommendation/headless.esm.js	bundled	338	338.4	0.1
	minified	191.1	191.3	0.1
	gzipped	49	49	0.1

samisayegh · 2021-06-10T15:57:16Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

@@ -0,0 +1,106 @@
+import {Schema, Value} from '@coveo/bueno';


Curious if there is a design doc for the trigger feature? Is the redirection trigger the only one in scope or is there a plan to support e.g. notify too?

I am currently doing redirection but will work on notify and query once this is done.

Ok, have the apis for each type been designed? Are they similar, or completely different? Depending on the answers, this will affect how things would best be named and structured.

If there is no design, I strongly recommend spending some time creating a document and sharing it with the team. It will us to collaborate and iterate faster compared to actually coding the feature,

The triggers.ts file in headless defines the interfaces for each trigger.

Ok, but will the controllers look like? Does it make sense to have a separate controller by type? Or would it be better to have one controller for everything related to triggers?

I remember meeting with Olivier and Jean-Felix and deciding on having a controller for each trigger type but I don't remember the reason for this choice.

We discussed the design together with Olivier and Nicolas, it's roughly described in the Jira https://coveord.atlassian.net/browse/KIT-548

https://coveord.atlassian.net/browse/KIT-548

samisayegh · 2021-06-10T16:01:07Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+ * @param props - The configurable `Redirection` properties.
+ * @returns A `Redirection` controller instance.
+ * */
+export function buildRedirection(


Shouldn't the name be buildRedirectionTrigger? Depending on what is in-scope, locking in the word redirection could also be too restrictive, hmm

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

https://coveord.atlassian.net/browse/KIT-548

This reverts commit 2a578d5.

ThibodeauJF · 2021-06-15T20:32:04Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+  const controller = buildController(engine);
+  const {dispatch} = engine;
+
+  let previousRedirectTo = '';


should be typed string | null and be instantiated to null

ThibodeauJF · 2021-06-15T20:32:43Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+        const hasChanged = previousRedirectTo !== this.state.redirectTo;
+        console.log('prev value', previousRedirectTo);
+        console.log('current controller state', this.state.redirectTo);
+        previousRedirectTo = this.state.redirectTo!;


You won't need the ! to force the type

https://coveord.atlassian.net/browse/KIT-548

samisayegh

My main comment would be the creation of a dedicated slice rather than share the redirection slice across two components,

samisayegh · 2021-06-18T16:06:42Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.test.ts

+    redirectionTrigger.subscribe(listener);
+
+    expect(listener).toHaveBeenCalledTimes(1);
+    expect(getLogTriggerRedirectAction()).toBeTruthy();


It would be possible to avoid logging an analytics event immediately on subscribe if this line was initialized to the value in state instead of null.

Not sure I get this, we should log and call the listener on subscribe if the redirection state did contain a trigger (not null, or equivalent would be not an empty string)

Use cases could be SSR or creating a trigger controller later, after the latest search

I'm thinking it should log on state change so headless does not log the same event over and over if someone instantiates multiple controllers.

We've said controllers should be instantiated before the first search. Allowing late registration feels inconsistent. UX-wise too, a user would see the results of their search and then suddenly a redirection when the late controller registers? I don't find that very nice,

I think it's better for redirection not to work in this situation, a) encouraging devs to adjust their code and b) avoiding questions around why instantiating one controller late "works", whereas others need to be instantiated before the search.

samisayegh · 2021-06-18T16:08:18Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+  /**
+   * The url used for the redirection.
+   */
+  redirectTo: string | null;


I think it would be possible to remove null from the type, and always initialize as a string.

Not a hard argument from my part but: Its initialized as null in the slice/state as well, and checking against undefined/null is easier than for empty strings

I initialized it to null for the case where a redirection trigger is received and saved to the engine's state but a redirection-trigger controller has not been initialized yet. Upon its initialization, it would need to immediately deal with that trigger and log it. If we immediately initialize it to the value in state then we would lose that functionality.

samisayegh · 2021-06-18T16:16:12Z

packages/headless/src/features/redirection/redirection-slice.ts

+        state.redirectTo = action.payload;
+      })
+      .addCase(executeSearch.fulfilled, (state, action) => {
+        const redirectTriggers: Trigger[] = action.payload.response.triggers.filter(


I think we should create a separate slice for triggers.

As is, if someone is using a standalone search box and a trigger, if the plan endpoint returns a url, then headless would log a redirection trigger event to UA which would be incorrect.

samisayegh · 2021-06-18T16:19:26Z

packages/samples/headless-react/src/components/triggers/redirection-trigger.class.tsx

+    this.setState(this.controller.state);
+  }
+
+  render() {


Let's remove the render function, or just return null, since there's no visual in the sample.

samisayegh · 2021-06-18T16:21:44Z

packages/samples/headless-react/src/components/triggers/redirection-trigger.class.tsx

+    this.unsubscribe();
+  }
+
+  componentDidUpdate() {


This function is not really needed, since the redirection can happen inside the updateState function.
The setState call is not necessary because the render function is not visual.

I would rename updateState to redirect and add the window.location.href line there,

samisayegh · 2021-06-18T16:26:54Z

packages/samples/headless-react/src/components/triggers/redirection-trigger.fn.tsx

+  if (!state) {
+    return null;
+  }
+
+  if (state.redirectTo) {
+    window.location.href = state.redirectTo;
+    return null;
+  }
+
+  return <div></div>;


I think can replace these lines with a simple return null. No need for a state hook too,

const redirect = () => { window.location.href = controller.state.redirectTo; } useEffect(() => controller.subscribe(redirect), []); return null;

ThibodeauJF · 2021-06-18T16:55:00Z

packages/headless/README.md

@@ -32,6 +32,12 @@ To run the unit tests and watch, run:
 npm run test:watch
 ```

+To use @coveo/headless locally, you have to build the package by running:


ThibodeauJF · 2021-06-18T16:57:44Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts

+  /**
+   * The url used for the redirection.
+   */
+  redirectTo: string | null;


Not a hard argument from my part but: Its initialized as null in the slice/state as well, and checking against undefined/null is easier than for empty strings

ThibodeauJF · 2021-06-18T17:00:41Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.test.ts

+    redirectionTrigger.subscribe(listener);
+
+    expect(listener).toHaveBeenCalledTimes(1);
+    expect(getLogTriggerRedirectAction()).toBeTruthy();


Not sure I get this, we should log and call the listener on subscribe if the redirection state did contain a trigger (not null, or equivalent would be not an empty string)

Use cases could be SSR or creating a trigger controller later, after the latest search

ThibodeauJF · 2021-06-18T17:03:13Z

packages/headless/src/features/redirection/redirection-slice.ts

+        state.redirectTo = action.payload;
+      })
+      .addCase(executeSearch.fulfilled, (state, action) => {
+        const redirectTriggers: Trigger[] = action.payload.response.triggers.filter(


Goind point, agreed, the said slice's state should be split into the triggers types.

A con: would the redirection-slice become misleading then, if it's not affected by trigger on the /search call, but only on the /plan call ?

https://coveord.atlassian.net/browse/KIT-548

samisayegh

Left some final thoughts, but aside from that, looking good 💯

samisayegh · 2021-06-21T13:57:35Z

packages/headless/src/controllers/triggers/headless-redirection-trigger.test.ts

+    redirectionTrigger.subscribe(listener);
+
+    expect(listener).toHaveBeenCalledTimes(1);
+    expect(getLogTriggerRedirectAction()).toBeTruthy();


I'm thinking it should log on state change so headless does not log the same event over and over if someone instantiates multiple controllers.

We've said controllers should be instantiated before the first search. Allowing late registration feels inconsistent. UX-wise too, a user would see the results of their search and then suddenly a redirection when the late controller registers? I don't find that very nice,

I think it's better for redirection not to work in this situation, a) encouraging devs to adjust their code and b) avoiding questions around why instantiating one controller late "works", whereas others need to be instantiated before the search.

samisayegh · 2021-06-21T14:21:35Z

packages/headless/src/app/reducers.ts

@@ -57,6 +58,7 @@ export const searchHub = searchHubReducer;
 export const debug = debugReducer;
 export const resultPreview = resultPreviewReducer;
 export const version = versionReducer;
+export const trigger = triggerReducer;


Should we use the plural triggers if the reducer is going to support all 4 triggers?

samisayegh · 2021-06-21T14:22:51Z

packages/samples/headless-react/src/components/triggers/redirection-trigger.fn.tsx

+  const redirect = () => {
+    setState(props.controller.state);
+    console.log(state);
+    console.log(props.controller.state);


Let's remove these logs,

https://coveord.atlassian.net/browse/KIT-548

nbuissoncoveo added 3 commits June 8, 2021 14:49

added triggers to search-response interface

1467908

https://coveord.atlassian.net/browse/KIT-548

added executeSeearch action to redirection slice

6c6615d

https://coveord.atlassian.net/browse/KIT-548

initial version of controller

036665f

https://coveord.atlassian.net/browse/KIT-548

nbuissoncoveo commented Jun 9, 2021

View reviewed changes

nbuissoncoveo requested a review from ThibodeauJF June 9, 2021 17:06

ThibodeauJF reviewed Jun 9, 2021

View reviewed changes

nbuissoncoveo added 5 commits June 9, 2021 14:41

refactored and removed initial state

17846c7

https://coveord.atlassian.net/browse/KIT-548

extracted state from engine

f544823

https://coveord.atlassian.net/browse/KIT-548

added check to make sure response contains redirect triggers

a5ff2ce

https://coveord.atlassian.net/browse/KIT-548

called onRedirect when response contains a redirect trigger

af6bd09

https://coveord.atlassian.net/browse/KIT-548

log trigger to analytics

04ae168

https://coveord.atlassian.net/browse/KIT-548

nbuissoncoveo requested a review from ThibodeauJF June 9, 2021 20:43

ThibodeauJF reviewed Jun 10, 2021

View reviewed changes

nbuissoncoveo added 4 commits June 10, 2021 09:49

fixed documentation

71e9dd6

https://coveord.atlassian.net/browse/KIT-548

checking length of array

5b50a9a

https://coveord.atlassian.net/browse/KIT-548

added subscribe

ea483c2

https://coveord.atlassian.net/browse/KIT-548

fixed build

6c8680b

https://coveord.atlassian.net/browse/KIT-548

samisayegh reviewed Jun 10, 2021

View reviewed changes

added lodash.memoize package to run local headless test

2c078b7

https://coveord.atlassian.net/browse/KIT-548

samisayegh reviewed Jun 10, 2021

View reviewed changes

packages/headless/src/controllers/triggers/headless-redirection-trigger.ts Show resolved Hide resolved

nbuissoncoveo and others added 5 commits June 10, 2021 15:27

added tests for redirection-slice

351735a

https://coveord.atlassian.net/browse/KIT-548

added lodash.memoize to package-lock.json

6c209b6

https://coveord.atlassian.net/browse/KIT-548

Delete package-lock.json

ffde6d1

Delete package.json

2a578d5

Revert "Delete package.json"

bcd9cb8

This reverts commit 2a578d5.

ThibodeauJF reviewed Jun 15, 2021

View reviewed changes

nbuissoncoveo and others added 9 commits June 16, 2021 10:54

unit test controller

700a724

https://coveord.atlassian.net/browse/KIT-548

previousRedirectTo instantiated to null

792bde7

https://coveord.atlassian.net/browse/KIT-548

added controller export to index file

7417d85

https://coveord.atlassian.net/browse/KIT-548

initial versions of react samples

94e0453

https://coveord.atlassian.net/browse/KIT-548

added instruction to README

85d6b15

https://coveord.atlassian.net/browse/KIT-548

added react samples

99aded8

https://coveord.atlassian.net/browse/KIT-548

Merge branch 'master' into KIT-548

ab8db94

fixed typo index file

dd2e378

https://coveord.atlassian.net/browse/KIT-548

ts narrowing getter bug

f72d205

https://coveord.atlassian.net/browse/KIT-548

nbuissoncoveo marked this pull request as ready for review June 17, 2021 14:52

nbuissoncoveo requested review from btaillon-coveo and olamothe as code owners June 17, 2021 14:52

nbuissoncoveo requested review from ThibodeauJF and samisayegh June 18, 2021 14:26

samisayegh reviewed Jun 18, 2021

View reviewed changes

ThibodeauJF approved these changes Jun 18, 2021

View reviewed changes

nbuissoncoveo added 3 commits June 18, 2021 13:30

migrated to trigger slice

064035c

https://coveord.atlassian.net/browse/KIT-548

created trigger section for engine

0eed201

https://coveord.atlassian.net/browse/KIT-548

fixed react samples

d00a8ac

https://coveord.atlassian.net/browse/KIT-548

nbuissoncoveo requested a review from samisayegh June 21, 2021 12:35

ThibodeauJF requested a review from dlutzCoveo June 21, 2021 12:47

dlutzCoveo approved these changes Jun 21, 2021

View reviewed changes

samisayegh approved these changes Jun 21, 2021

View reviewed changes

nbuissoncoveo added 3 commits June 21, 2021 10:50

adjustements

0a33602

https://coveord.atlassian.net/browse/KIT-548

fixed test

eb5d528

https://coveord.atlassian.net/browse/KIT-548

merge master

c77e399

https://coveord.atlassian.net/browse/KIT-548

nbuissoncoveo merged commit 1439c9c into master Jun 21, 2021

nbuissoncoveo deleted the KIT-548 branch June 21, 2021 16:20

	function: new Function(),
	onRedirect: new Value({required: true}),

	* A scoped and simplified part of the headless state that is relevant to the `Pager` controller.
	* A scoped and simplified part of the headless state that is relevant to the `RedirectionTrigger` controller.

	export interface Redirection extends Controller {
	export interface RedirectionTrigger extends Controller {

	* The function used to handle whenever the `Redirection` controller's state's `redirectTo` value changes.
	* The function used to handle whenever the `RedirectionTrigger` controller's state's `redirectTo` value changes.

		@@ -0,0 +1,106 @@
		import {Schema, Value} from '@coveo/bueno';

feat(headless): TriggerRedirection #875

feat(headless): TriggerRedirection #875

Conversation

nbuissoncoveo commented Jun 9, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nbuissoncoveo commented Jun 9, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ThibodeauJF commented Jun 9, 2021

ThibodeauJF left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nbuissoncoveo Jun 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samisayegh Jun 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Jun 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samisayegh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ThibodeauJF Jun 18, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ThibodeauJF Jun 18, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samisayegh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nbuissoncoveo Jun 10, 2021 •

edited

Loading

samisayegh Jun 10, 2021 •

edited

Loading

github-actions bot commented Jun 10, 2021 •

edited

Loading

ThibodeauJF Jun 18, 2021 •

edited

Loading

ThibodeauJF Jun 18, 2021 •

edited

Loading