xyflow: Edge svg elements not being rendered to the dom

Describe the Bug

“react-flow-renderer”: “10.3.17”

Hello

For some reason the edges <g> elements are not being interested into the DOM after the application is bundled. Everything works fine in local development running in create react app which uses webpack under the hood.

Also I am not able to create new edges, the drag from the source handle does not create edges.

I tried with custom edges as well but the components for the custom edge do not render after bundling. I tried with a debugger statment in the CustomEdge component

The application is bundled with rollup for production. I have also tried with vitejs but it has the same issue. I am suspecting it has something to do with the bundler since that is the only main difference between the two. There are no errors or warnings in the console.

Any other ideas? Is there something about the edges code that will be an issue with rollup bundling?

See below videos

The example in the video is taken from https://codesandbox.io/s/coq0t9?file=/App.js&from-sandpack=true

Your Example Website or App

No response

Steps to Reproduce the Bug or Issue

n/a happens only internally

Expected behavior

As a user I expect edges to be displayed

Screenshots or Videos

Screen Shot 2022-09-16 at 1 26 14 PM

in local env with create react app OK

https://user-images.githubusercontent.com/52473897/190700409-147bab0e-8c20-4db6-9c5a-cef536dabe4f.mov

with edges issue after being bundled NOT OK

https://user-images.githubusercontent.com/52473897/190700636-dc7f9838-a12f-4df2-a32c-7c7f04f3a2ac.mov

Platform

all

Additional context

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 15 (5 by maintainers)

Most upvoted comments

@enoguchi-lmi do you have anything I could look at? A repo or a deployed app?

I will let you know if I can replicate it in a repo I can share. This is happening in an internal app but only once its deployed, locally it’s working.

FWIW this bug also happens with versions 10.3.16 and 10.3.9. I did a binary search on versions and the first working version I found was 10.2.3. So it is quite likely that 10.3.0 introduces this bug based on the amount of changed code.