feat(web): templates store modal workflow preview #3450
Conversation
NV-2271 🏪 [Template store] Create detailed workflow preview (right side modal)
What?Template store/List of the templates/Description Why?Allow users to see extra information regarding a particular template before they make a decision regarding its usage of it.
How?Display the name of the template Display a description of the template Display a workflow of the template, it can be scrolled up and down Display a button Use template and Made by Novu sign and icon Workflow list - Template store (Figma) White theme |
| @@ -16,7 +16,7 @@ import { parseUrl } from '../../../utils/routeUtils'; | |||
| import { OnBoardingAnalyticsEnum } from '../../../pages/quick-start/consts'; | |||
| import { useSegment } from '../../providers/SegmentProvider'; | |||
| import { useDigestDemoFlowContext } from './DigestDemoFlowProvider'; | |||
| import { NodeStep } from '../common'; | |||
| import { NodeStep } from '../../workflow-nodes'; | |||
There was a problem hiding this comment.
moved to another folder, not specific to the quick-start
| data: { label: string; email?: string }; | ||
| Handlers: React.FC<any>; | ||
| Icon: React.FC<any>; | ||
| ActionItem?: React.ReactNode; | ||
| ContentItem?: React.ReactNode; | ||
| }; | ||
|
|
||
| export function NodeStep({ Handlers, Icon, data, ActionItem, ContentItem }: NodeStepProps) { | ||
| export function NodeStep({ className, Handlers, Icon, data, ActionItem, ContentItem }: NodeStepProps) { |
There was a problem hiding this comment.
allow to style it with className and styled
| const NodeStepStyled = styled(NodeStep)` | ||
| width: 200px; | ||
| `; |
There was a problem hiding this comment.
that's how easy is to update the styles
| const STEPS: IFormStep[] = [ | ||
| { | ||
| _id: 'digest', | ||
| name: 'Digest', | ||
| template: { | ||
| type: StepTypeEnum.DIGEST, | ||
| content: '', | ||
| }, | ||
| }, | ||
| { | ||
| _id: 'email', | ||
| name: 'Email', | ||
| template: { | ||
| name: 'Test email', | ||
| subject: 'Test subject', | ||
| title: 'Test title', | ||
| type: StepTypeEnum.EMAIL, | ||
| content: 'adsf', | ||
| }, | ||
| }, | ||
| ]; | ||
|
|
||
| const STEPS2: IFormStep[] = [ | ||
| { | ||
| _id: 'in-app', | ||
| name: 'In-App', | ||
| template: { | ||
| type: StepTypeEnum.IN_APP, | ||
| content: '', | ||
| }, | ||
| }, | ||
| { | ||
| _id: 'digest', | ||
| name: 'Digest', | ||
| template: { | ||
| type: StepTypeEnum.DIGEST, | ||
| content: '', | ||
| }, | ||
| }, | ||
| { | ||
| _id: 'email', | ||
| name: 'Email', | ||
| template: { | ||
| name: 'Test email', | ||
| type: StepTypeEnum.EMAIL, | ||
| content: 'adsf', | ||
| }, | ||
| }, | ||
| { | ||
| _id: 'push', | ||
| name: 'Push', | ||
| template: { | ||
| type: StepTypeEnum.PUSH, | ||
| content: 'Test push', | ||
| }, | ||
| }, | ||
| ]; |
| <FlowEditor | ||
| steps={selectedTemplate.steps} | ||
| nodeTypes={nodeTypes} | ||
| zoomOnScroll={false} | ||
| zoomOnPinch={false} | ||
| zoomOnDoubleClick={false} | ||
| panOnDrag={false} | ||
| panOnScroll | ||
| preventScrolling={false} | ||
| nodesDraggable={false} | ||
| elementsSelectable={false} | ||
| nodesConnectable={false} | ||
| selectNodesOnDrag={false} | ||
| wrapperStyles={{ | ||
| height: '100%', | ||
| width: '100%', | ||
| minHeight: '300px', | ||
| }} |
There was a problem hiding this comment.
reusing the same FlowEditor component as we do use in the Template Editor, allowing to pass any react-flow props
| const onStepInit = async () => { | ||
| await trigger('steps'); | ||
| }; |
| const nodeTypes = { | ||
| channelNode: ChannelNode, | ||
| triggerNode: TriggerNode, | ||
| addNode: AddNode, | ||
| }; | ||
|
|
||
| const edgeTypes = { special: AddNodeEdge }; |
There was a problem hiding this comment.
These were hardcoded before in the FlowEditor and they are using a lot of different functionalities, like react-hook-form etc., but it's only specific to the Template Editor. Now we can define whatever steps we want and we can reuse FlowEditor.
| const DEFAULT_WRAPPER_STYLES = { | ||
| height: '100%', | ||
| width: '100%', | ||
| minHeight: '600px', | ||
| }; |
There was a problem hiding this comment.
were defined on the first div wrapper before
| interface IFlowEditorProps extends ReactFlowProps { | ||
| steps: IFormStep[]; | ||
| dragging?: boolean; | ||
| errors?: any; | ||
| nodeTypes: { | ||
| triggerNode: ComponentType<NodeProps>; | ||
| channelNode: ComponentType<NodeProps>; | ||
| addNode?: ComponentType<NodeProps>; | ||
| }; | ||
| edgeTypes?: { special: ComponentType<EdgeProps> }; | ||
| withControls?: boolean; | ||
| wrapperStyles?: React.CSSProperties; | ||
| onDelete?: (id: string) => void; | ||
| onStepInit?: (step: IFormStep) => Promise<void>; | ||
| addStep?: (channelType: StepTypeEnum, id: string, index?: number) => void; | ||
| } |
There was a problem hiding this comment.
extends ReactFlowProps and adds some other useful props
| zoomOnScroll = false, | ||
| preventScrolling = true, | ||
| nodesConnectable = false, | ||
| nodesDraggable = true, | ||
| minZoom = 0.5, | ||
| maxZoom = 1.5, | ||
| defaultZoom = 1, |
There was a problem hiding this comment.
before these were defined in the const reactFlowDefaultProps
| setNodes((nds) => nds.concat(newNode)); | ||
|
|
||
| const newEdge = buildNewEdge(parentId, newId, edgeTypes ? 'special' : 'default'); |
There was a problem hiding this comment.
The condition of the third argument is a bit hidden and can be missed for someone not familiar with code. I'd suggest to extract it so it is a bit more clear.
| > | ||
| <Controls /> | ||
| {withControls && <Controls />} |
There was a problem hiding this comment.
Thinking if we should pass withControls as a show property to the Controls component and the proper component to handle their rendering rather than the parent. What do you think?
There was a problem hiding this comment.
This Controls component is from the react-flow-renderer library and it doesn't have the show prop.
But still, I think it's better to do it on the parent level, otherwise, if you do it on the child level then you might register some hooks unnecessarily and the React will create a fiber for that component and will do all its logic aka reconciliation work.
| return ( | ||
| <> | ||
| <Handle type="target" id="b" position={Position.Top} /> | ||
| <Handle style={noChildStyle} type="source" id="a" position={Position.Bottom} /> |
There was a problem hiding this comment.
Would be a problem if multiple components share the same id? Even if being part of a parent component? Thinking in the reconciliation algorithm and when debugging.
There was a problem hiding this comment.
I'm not sure if this is even needed, but I've copied it from the other place 🥲 I'll check it.
This id is not used as the HTML el id but as the internal library handleId. It shouldn't have any impact on the reconciliation.
There was a problem hiding this comment.
the id's are not needed, I'll remove them
What change does this PR introduce?
In this PR I've implemented the workflow preview in the Templates Store Modal.
The preview is using the same
FlowEditorthat we use in the Template Editor, so it's been a little refactored by moving the code that shouldn't be there outside of the component. I'll leave the explanation in the comments.Why was this change needed?
Templates Store PRD.
Other information (Screenshots)
Screen.Recording.2023-05-17.at.23.06.20.mov