Migrate to version 2.x antv/x6

[jgadsden]

Summary:
first pass at migrating to version 2.x antv/x6
unit tests broken
stencil incomplete
various unfinished features

Description for the changelog:
migrate to version 2.x antv/x6

Other info:

Closes #722

• the usability of data flows and trust boundaries is very much better, so closes Improve selection of edges and creation of bendpoints #1067 and closes Clicking on data flow does not open it in properties #785
• double clicking a component to get a data flow is not intuitive, so has been removed to close I have to click undo five times to actually undo the action #1068
• closes Can't move ends of line objects inside of Trust Boundary frame #1082 because the dataflow is still manageable even after it is wrongly associated with a trust boundary
• closes Implement mousewheel button dragging for graph panning #954 now that we have better scrolling ability
• closes Out of scope datastore displayed incorrectly #1101 by fixing schema errors in v2 demo threat model
• closes Improve Drag and Drop of Components #1065 by improving the drag and drop of components from the stencil area

[jgadsden]

@lreading feel free to progress this, there is a lot of work still to do
the data flows are now very easy to use so the migration will certainly be worth it

[leo-reading-springhealth]

Looking at the tests right now, they're giving me a hard time. 😩

I only tested the history implementation, and that seems to work. I'll want to test all the other functions that are implemented via plugin now, as they may or may not work the same. I found that calling graph.history was returning undefined, graph.getPlugin(<name>) gets the history plugin which seems to have the same interface as the old version.

[leo-reading-springhealth]

Wait, let me try again - I had my wires crossed. I'm going to start anew from this branch! I had created a new branch and copied some of the work from your old PR. This is even better, thank you @jgadsden !

[leo-reading-springhealth]

Do we want to delete the trust boundary curve and flow stencils?

[jgadsden]

Many thanks for the additions @lreading
I agree we need to have flows and TB curves in the stencils, they are just commented out for now because (I think) they are handled differently in the new stencil package - but I probably have that wrong
There is still a lot of work to do, for example scrolling the diagram produces very unexpected results :)
The blocking bug where only part of the diagram is displayed has been fixed, but reappears when the diagram is saved, and so on

[jgadsden]

Do we want to delete the trust boundary curve and flow stencils?

definitely want to keep trust boundary curve and flow stencils, it was only that I could not see how to migrate them when I committed these changes

[lreading]

There's a bug when clicking undo very quickly after populating the history stack. No fix for it yet, but I wanted to comment on it so that I don't forget to look into it more. :)

[Thanks for fixing this @lreading ]

[jgadsden]

There's a bug when clicking undo very quickly after populating the history stack.

yes, agreed -we probably should check for state.cell in :

        disableNewThreat: function (state) {
            return state.cell.ref.data.outOfScope || state.cell.ref.data.isTrustBoundary || state.cell.ref.data.type === 'tm.Text';
        }

[jgadsden]

The only thing left is the unit tests which are in progress and a bug where the the diagram in the report is still modifiable - freeze/unfreeze was removed from antv/x6 1.x -> 2.x and the only reference I can find for something similar in version 2.x is to do with graph.async boolean, and this does not seem to be effective

@lreading I can work on the unit tests and raise an issue for the mutable report diagram - unless you want to determine how it can be done, possibly use graph.toPNG instead ?

[lreading]

It looks like setting interacting: false on the readonly graph gets us really close to an immutable copy for reporting. The cursor will still change to a pointer when hovering over components, but you cannot move them or reconnect edges. I think this will be good enough? 😄

I'm going to take a peek at the unit tests as well!

[jgadsden]

wondering if we should provide more ports along the edges of the node components? We have one each side centred , which is a 'must have' , but how about 3 per side to provide less bunching?

ie something like in ports.js :

    items: [
        {
	    group: 'top'
        },
        {
	    group: 'top'
        },
        {
	     group: 'top'
        },
        {
             group: 'right'
        },

to give:

[lreading]

wondering if we should provide more ports along the edges of the node components? We have one each side centred , which is a 'must have' , but how about 3 per side to provide less bunching?

ie something like in ports.js :

    items: [
        {
	    group: 'top'
        },
        {
	    group: 'top'
        },
        {
	     group: 'top'
        },
        {
             group: 'right'
        },

to give:

I think that'd be a great addition!

[lreading]

The unit tests are now passing, and it looks like the e2e tests did as well! 🎉

The coverage is probably down from where it once was, I was primarily focused on getting them passing. :)

[jgadsden]

thanks @lreading for all this - we are ready to commit it I think? The honour is yours :)
maybe I can sneak in one last update to the number of ports ...

[lreading]

I'll leave it up to you @jgadsden ! If you feel it's ready for merge, by all means 🙌

[jgadsden]

apologies @lreading , I was sneaking in a last minute change which removes the ports from the text box - the thinking being that we don't want dataflows attaching to a text box
I also went against the idea of multiple ports on each edge - it did not add to the usability and looked a bit strange
please go ahead and merge, many thanks