M2-7011: feat conditional logic extend item type #883
Conversation
felipeMetaLab
changed the title
…swerValidator, adding fieldValue to time range and improving payloads
| @@ -15,10 +15,130 @@ type Condition = | |||
| | EqualCondition | |||
| | NotEqualCondition | |||
| | BetweenCondition | |||
| | OutsideOfCondition; | |||
| | OutsideOfCondition | |||
There was a problem hiding this comment.
Nit: Could we keep these and the individual types in both this file & ActivityItemDto.ts in the same order? In order to improve readability
| // @ts-expect-error | ||
| delete updatedCondition.itemName; |
There was a problem hiding this comment.
With the de-structuring done above, these two lines can be deleted.
| // @ts-expect-error | ||
| delete updatedCondition.itemName; | ||
| switch (condition.type) { |
There was a problem hiding this comment.
Some cases are missing from this one, that aren't straightforward
payload: {
value: number;
};General conditions
case 'BETWEEN':
case 'OUTSIDE_OF':
Row option conditions
case 'EQUAL_TO_ROW_OPTION':
case 'NOT_EQUAL_TO_ROW_OPTION':
Slider row conditions
case 'GREATER_THAN_SLIDER_ROWS':
case 'LESS_THAN_SLIDER_ROWS':
case 'EQUAL_TO_SLIDER_ROWS':
case 'NOT_EQUAL_TO_SLIDER_ROWS':
case 'BETWEEN_SLIDER_ROWS':
case 'OUTSIDE_OF_SLIDER_ROWS':
Should those be added?
| break; | ||
|
|
||
| case 'BETWEEN_DATES': | ||
| case 'OUTSIDE_OF_DATES': |
There was a problem hiding this comment.
The cases 'BETWEEN_TIMES', 'OUTSIDE_OF_TIMES', 'BETWEEN_TIME_RANGES' and 'OUTSIDE_OF_TIME_RANGES' can be grouped with these two, all are passing both minDate and maxDate.
This could be left as is to preserve ordering. Order for this switch can be replicated from the actual Condition type
|
|
||
| export const isEqualToDate = (input: Maybe<string>, date: string) => { | ||
| if (!input) return false; | ||
| return input ? isEqual(parseISO(input), parseISO(date)) : false; |
There was a problem hiding this comment.
Since we're already validating if input exists, this can be updated to just:
| return input ? isEqual(parseISO(input), parseISO(date)) : false; | |
| return isEqual(parseISO(input), parseISO(date)); |
| function isValidTimeFormat(time: any): boolean { | ||
| return ( | ||
| time && typeof time.hours === 'number' && typeof time.minutes === 'number' | ||
| ); | ||
| } |
There was a problem hiding this comment.
Are we able to narrow the types time can have? For example, if it's either the expected { hours: number, minutes: number } or undefined? Maybe replace undefined with null, or even include both, if that's the case. Just to stay on the type-safe side of things
| function isValidTimeFormat(time: any): boolean { | |
| return ( | |
| time && typeof time.hours === 'number' && typeof time.minutes === 'number' | |
| ); | |
| } | |
| function isValidTimeFormat( | |
| time: | |
| | { | |
| hours: number; | |
| minutes: number; | |
| } | |
| | undefined, | |
| ): boolean { | |
| return ( | |
| !!time && | |
| typeof time.hours === 'number' && | |
| typeof time.minutes === 'number' | |
| ); | |
| } |
| return null; | ||
| }; | ||
|
|
||
| const timeToMinutes = (time: { hours: number; minutes: number }): number => { |
There was a problem hiding this comment.
Ditto as for getTimeBasedOnFieldName and convertToMinutes
| return isEqualToValue(selectedOption, optionValue); | ||
| }, | ||
|
|
||
| isGreaterThen(value: number) { | ||
| isGreaterThan(value: number) { |
There was a problem hiding this comment.
Nice catch! Makes me wonder, how were these working properly 🤔
| function isValidTimeFormat(time: any): boolean { | ||
| return ( | ||
| time && typeof time.hours === 'number' && typeof time.minutes === 'number' | ||
| ); | ||
| } |
There was a problem hiding this comment.
Ditto as for AnswerValidator.ts
| @@ -45,7 +45,127 @@ type ConditionDto = | |||
| | EqualConditionDto | |||
| | NotEqualConditionDto | |||
| | BetweenConditionDto | |||
| | OutsideOfConditionDto; | |||
| | OutsideOfConditionDto | |||
📝 Description
🔗 Jira Ticket M2-7011
This PR is focused to extend and create item types and conditional logic.
here is described the rules it must to follow:
https://mindlogger.atlassian.net/wiki/spaces/MINDLOGGER1/pages/596410369/Item+Flow+-+Extend+the+list+of+supported+Item+Types
📸 Screenshots
Screen.Recording.2024-10-28.at.2.02.27.PM.mov
Screen.Recording.2024-10-27.at.9.29.36.PM.mov
🪤 Peer Testing
1 - Launch admin app, and create a new applet or open an existed one.
2 - go to the items and create the items you would like to test, example, Date, Message, Text ...
3 - click on "item flow" tab and create your conditional logic, example:
4 - launch the app and choose the applet you created.
5 - check if the logic is working, I left a video sample to demonstrate one of the logics.
✏️ Notes
For it works on development it depends of the backend, the backend branch I am testing is: feature/M2-7011_extend_the_list_of_supported_item_types.
Somehow when you create a condition on admin side, the date looks little different, so its super important makes a validation based on what was inserted on API
