Update connect to work with multiple connecting blocks

[alschmiedt]

The basics

• I branched from develop
• My pull request is against develop
• My code follows the style guide

The details

Resolves

There were three cases when connecting multiple blocks that were failing:

1. When there is a marker in the middle of a stack and the cursor is on a previous connection:

• The block with the cursor should be inserted into the stack.

2. When there is a cursor in the middle of a stack and the marker is on a previous connection:

• The stack should be moved to the location of the marker
• The block with the cursor attached should be inserted into the stack

3. When there is a marker in the middle of a stack and the cursor is on the next connection:

• The block with the cursor should be inserted into the stack

Proposed Changes

Reason for Changes

Test Coverage

Tested on:

Documentation

Additional Information

There are a few more bugs around connecting inline inputs that will be addressed in a different PR.

[RoboErikG]

Having one of the parameters called targetConnection makes this sentence really confusing since you're referring to the targetConnection property on each of the two connections being passed. Not sure how to clean that up...

[RoboErikG]

This rename also makes the code confusing. Because you didn't want to call it targetTarget you've implicitly renamed target to marker, which means when you use them both down below it's confusing how they're related. Change movingConnection and targetConnection to use names that can be continued with their Targets. Maybe movingConnection and toConnection or moving/destination?

[RoboErikG]

This is assuming the targetConnection is always a previous connection, which isn't the case at the end of a stack. It gets caught by later cases, but it's better practice to explicitly check things instead of depending on failures.

[RoboErikG]

I think you could make this method a bit more readable by having it do the following:

1. On the moving connection, get the best inferior connection or null.
2. If 1 succeeded, on the destination connection, get the best superior connection or null.
3. If 1 and 2 succeeded try connecting those two.
4. Else, try connecting the moving and destination connections.

Picking the best inferior would be:

1. If it's already an inferior connection use it.
2. If it's the next connection on a block use its previous/output connection if it exists.

Picking the best superior would be:

1. If already superior use it.
2. Use its target if it exists.

[alschmiedt]

Does this take into account #2 on the list? With the inferior connection being on the destination block? Also, if we have two next connections then it will find a way to connect those blocks, I don't particularly mind this but just throwing it out there.

[RoboErikG]

You're right, it doesn't. Let's stick with your version, but maybe organize it to be more readable instead of more efficient?