Fix/Diagram refactor

[body-clock]

• When a new quire is inserted above an existing quire, the numbering increases from bottom-up. It should be numbered top-down.
• This problem exists until the page is refreshed, so last resort is to force a page refresh.

[body-clock]

Currently, the system that draws the diagrams has been modified to accommodate subquires. This system needs to be rethought and refactored with subquire functionality in mind.

[body-clock]

The order of the drawings is dependent on the order of a groupIDs array. This array is list of every group, but at one level. Because we have nested groups, this one dimensional array doesn't make sense.The groupIDs array looks like this:

[  "Group_6052287516ec5800013c9674", "Group_000193f37c16171974907280", "Group_6052287616ec5800013c9693" ]

or, more simply:

[ "G1", "G1.1", "G2" ]

In the above example, the second group in the array is a subgroup. We decided to list a subgroup immediately after its parent, as this order works with the drawing system.

[body-clock]

There should be a groupIDs array, but it should only contain the outermost groups (nestLevel 1). When we need to access subgroups, we do it computationally by looking if there are any groups in the memberIDs array of the outermost group.

[body-clock]

The PaperJS diagrams work like this:

1. project props are passed into VisualMode from CollationManager
2. paperManager assigns this.props.project.groupIDs to a value called groupIDs
3. paperGroup assigns the value y to the index of the current group in context of groupIDs
4. in paperManager draw(), y positions of groups and leaves are calculated and stored in groupYs
5. groupYs is used to calculate height: let height = this.getYOfLastMember(group.id) - this.groupYs[this.groupIDs.indexOf(group.id)];

[body-clock]

The two main questions:

1. What depends on this groupIDs array to function properly? (maybe mess it up and see what happens)
2. What exactly should the groupIDs array look like, and what do we have to do to achieve that?

[demery]

1. What depends on this groupIDs array to function properly? (maybe mess it up and see what happens)

This sounds a good approach.

As you suggest above, it would be nice not to store the complete array of groups at the project level, but rather to compute that that list when it's needed. This has to be done, though, in the Rails model and on the JS side, yes? Perhaps you could make the change just on the Rails side, see if that works, and then move to the JS side.

[body-clock]

add_groupIDs is called in two places:

1. in groups_controller create (post to /groups)
2. in projects_helper addGroupsLeafsConjoin() which is called in projects_controller create

[body-clock]

groups_controller:48

 # Create groups
      noOfGroups.times do |i|
        group = Group.new(group_params)
        if groupIDs
          group.id = groupIDs[i]
        end
        if parentGroupID != nil
          group.parentID = parentGroupID
          group.nestLevel = parent_group.nestLevel + 1
        end
        if group.save
          new_groups.push(group)
          new_group_ids.push(group.id.to_s)
        else
          render json: {group: group.errors}, status: :unprocessable_entity and return
        end
      end

Groups are pushed to one array, and IDs are pushed a separate one. These IDs are then used when we call `add_groupIDs'

@project.add_groupIDs(new_group_ids, order.to_i - 1)

Groups are added to this groupIDs array regardless of whether they are an outermost group or a subgroup.