feat(dashboard): in-app editor loading state #7006
Conversation
LetItRock
requested review from
SokratisVidros,
BiswaViraj,
ChmaraX and
desiprisg
✅ Deploy Preview for novu-stg-vite-dashboard-poc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| export const AvatarPicker = forwardRef<HTMLInputElement, AvatarPickerProps>(({ id, ...props }, ref) => { | ||
| export const AvatarPicker = forwardRef<HTMLInputElement, AvatarPickerProps>(({ name, value, onChange }, ref) => { | ||
| const { step } = useStepEditorContext(); | ||
| const variables = useMemo(() => (step ? parseStepVariablesToLiquidVariables(step.variables) : []), [step]); |
There was a problem hiding this comment.
the component was missing variables and the CodeMirror editor field for the avatar URL
| const { workflowSlug = '', stepSlug = '' } = useParams<{ workflowSlug: string; stepSlug: string }>(); | ||
| const EditStepSidebarInternal = () => { | ||
| const navigate = useNavigate(); | ||
|
|
||
| const { workflow } = useFetchWorkflow({ | ||
| workflowSlug, | ||
| }); | ||
|
|
||
| const { step } = useFetchStep({ workflowSlug, stepSlug }); | ||
| const stepType = useMemo( | ||
| () => workflow?.steps.find((el) => getStepBase62Id(el.slug) === getStepBase62Id(stepSlug))?.type, | ||
| [stepSlug, workflow] | ||
| ); |
There was a problem hiding this comment.
Moved to the StepEditorProvider component which shares the step across the components.
I decided to do that because, in a few places, we were fetching the step with the useFetchStep hook, which on mount fetches the data from API, triggering the loading skeleton to be shown, and it was infinite because the skeleton was in the parent.
| [StepTypeEnum.CUSTOM]: () => null, | ||
| }; | ||
|
|
||
| export const StepSkeleton = ({ |
There was a problem hiding this comment.
the step skeleton which simulates the step editor shell for the sidebar with: header, body, footer
| {workflowOrigin && workflowOrigin !== WorkflowOriginEnum.EXTERNAL ? ( | ||
| <SkeletonContent /> | ||
| ) : ( | ||
| <SingleLineSkeleton /> | ||
| )} |
There was a problem hiding this comment.
There is a problem that I didn't know how we can solve. Basically, when the page is refreshed, we don't have the stepType or workflow.origin fields. This creates the problem that we don't know what skeleton to render as the content, because ideally it should be:
- different for code created steps - because the editor will have only custom control fields
- different for the dashboard created steps, even different depending on the step type
So what the code does here is:
- on page refresh it will show
SingleLineSkeleton, while theworkflowis loading - on app navigation, the
workflowis loaded and we can show the loader for a particular step type
Maybe I unnecessarily complicated it, but it doesn't look bad 😅
| <Avatar className="p-px"> | ||
| <AvatarImage src={props.value as string} /> | ||
| <AvatarImage src={value as string} /> |
There was a problem hiding this comment.
| <AvatarImage src={value as string} /> | |
| <AvatarImage src={value} /> |
It's a string already so this isn't needed
thanks @BiswaViraj, we need to remove the URL validation, I guess. Otherwise, we can't allow for the variables |
Yes, I think we can remove it.currently it will also fail for relative URLs as well "/posts/new" |
|
the validation will be removed on the BE side in separate PR |
What changed? Why was the change needed?
StepEditorContextwhich is the central place where we fetch the step information. More about in the comments.variablesto missing In-App form fields.Screenshots
Screen.Recording.2024-11-14.at.15.23.29.mov
Screen.Recording.2024-11-14.at.15.22.56.mov