Spike: Repeating UI

APERTA-11579 - Repeating UI Spike

This is a review of the repeater functionality that was completed in APERTA-11151 and how it compares to the following two tickets:

• APERTA-11152 - Update containers and controls for repeated card config components Dev Review
• APERTA-11578 - Drag and drop reordering for repeated and nested repeated components Dev Review

The hopeful outcome of this is to evaluate what additional development work would be required to achieve the AC of both tickets, as well as recommendations on how to accomplish that (reduce scope, build, change UI, etc.). As of October 24th, 2017, the initial implementation is still a WIP (see https://github.com/Tahi-project/tahi/pull/3592), but is in a far enough along state to assume that nothing major should change. If there are, I'll try to adjust as this documentation as needed.

APERTA-11152

The original implementation has already created the ability to add and delete particular repeaters. However, it currently doesn't have the concept of saving or cancelling within a container. In order to support this, we need to adjust its current behavior of doing autosaving to only save when the containers save button is pressed. Likewise, we need to support being able to rollback a containers set of answer values to its original state on cancel. This will likely require a flag we would need to pass down to each card content to modify its saving behavior to wait for an action (a button click) before saving. There's also some additional complexity in that we would only want to return a subset of card content validations in order to display any errors that are applied to sub card content elements According To Sam (see comments below), the button in the content will just close the container, which at least simplifies things since we can use the same debounce behavior as before. Everything mentioned before would likely most the work since this is the first case of this being done in card config where we treat a repeater container like a mini-card with its own ruleset.

We will also need to support showing and constraining the amount of repeater elements allowed within a single container. However, this work was also completed as part of APERTA-11151.

APERTA-11578

There isn't anything implemented from the work done in APERTA-11151 regarding being able to rearrange that we can immediately leverage to supporting doing drag-n-drop type behavior. There's various different tools that we can use and I don't think there's a particular one that's preferable to use (jQuery UI is already in the project, but even something as simple as straight up HTML5 drag-and-drop is probably fine, for example.

Currently, we're using a gem called 'closure_tree' which is essentially an upgraded and more efficient version of 'nested_awesome_sets' (a gem we've use before). The gem provides support for handling model hierarchies which we use in our card content scheme. For example, the hierarchies for our card content was kinda like this:

In this system, card content can have a parent (or none, in the case of the root card content) and siblings and children. The order of this is then recursively added to the page which constructs how the contents of a card is presented. Both 'nested_awesome_sets' and 'closure_tree' have the same db schema with one exception - we added a new position column to support deterministic order (which, granted, nested_awesome_sets supported too, but I don't believe we've used it before). This particular column was added for repetitions, a new data model which we use to track "clones" (for lack of a better word) of a reference card content.

There is one concern I noticed after doing some code experiments with a "pretend" drag and drop scenario though with how the gem handles the reordering of nodes that I'm hoping is just me messing up. Imagine there are five repetitions within a single container with a zero-based position index:

0,1,2,3,4

closure_tree provides various methods for rearranging nodes in all sorts of neat ways; parent-to-parent, swapping siblings, adding and removing children, and so on. It seemed nature to assume that a drag and drop event would result in the client sending a request to the server with a JSON representation of the repetition model getting send to the server, with the new position set. There are options to prepend and append sibling nodes, so I went ahead and used them.

They generally worked as advertised - they did in fact swap the nodes I chose via a simple -1 +1 change and reset all of other nodes to match up with the new order. It seems to be aware of it's own bounds quite well, so we can probably get away with just using that to do the reordering.

Suggestions

1. APERTA-11152 scope should be reduced to only include the container opening and closing behavior, as I think those are the only things left that need to be done
2. APERTA-11578 probably has enough stuff set backend wise to support sorting thanks to previous work and the closure_tree gem. My gut is that the biggest chunk of work will be the drag and drop work client side, but would argue that it isn't a 8 point story anymore. I'm not certain it can be broken up in a separate tickets, but it's definitely something that can be paired on to work in parallel.

Attachments:

supportingInfo-current.png (image/png)
authorsCard-current.png (image/png)
68747470733a2f2f7261772e6769746875622e636f6d2f436c6f73757265547265652f636c6f737572655f747265652f6d61737465722f696d672f6578616d706c652e706e67.png (image/png)