Notes

• Person is the only resource type that is adjacent aggregated
• Place is NOT suppose to be aggregated, BUT we are going to be implementing the function with a required types specification to allow for different types to be specified such that we don’t shoot ourselves in the foot when we submit the project. And we will make clear what we thought and how it can be rectified with the required types option of the strategy in the usage of the example.
• Type and Order are the keys to the kingdom. Name is almost irrelevant as it does not have an impact on the business rules. It’s simply used as a part of deriving the aggregate data. That’s it.
• This is meant to be a testable and flexible function. We will write test(s) for it.
• Input:

const resources = [{
        type: 'Person',
        order: 1,
        name: 'Brian',
      }, {
        type: 'Place',
        order: 2,
        name: 'Ohio',
      }, {
        type: 'Place',
        order: 12,
        name: 'Ohio',
      }, {
        type: 'Person',
        order: 14,
        name: 'Sarah',
`      },  {
        type: 'Person',
        order: 199,
        name: 'Sam',
      }, {
        type: 'Person',
        order: 19,
        name: 'Eric',
      }, {
        type: 'Place',
        order: 20,
        name: 'Home',
      }
    ];

• Output:

[
  {
    "type": "Person",
    "order": 1,
    "people": [
      "Brian"
    ]
  },
  {
    "type": "Place",
    "order": 2,
    "name": "Ohio"
  },
  {
    "type": "Place",
    "order": 12,
    "name": "Ohio"
  },
  {
    "type": "Person",
    "order": 19,
    "people": [
      "Sarah",
      "Eric"
    ]
  },
  {
    "type": "Place",
    "order": 20,
    "name": "Home"
  },
  {
    "type": "Person",
    "order": 199,
    "people": [
      "Sam"
    ]
  }
]

Approach Tasks(numbers indicate pomodoro units)

• 2 : Think of and write up approach tasks, function specs, and function unit tests for the design
• 1 : Create GitHub project
• 2 : Transfer all relevant design information from other sources to the Github projects wiki, etc...
• 4(P.S. took way to long re-using parts of another repo) : Setup project skeleton/scaffolding with todos and empty code file shells
• 2 : Write unit tests for the business logic, use challenge I/O
• 6 : Get the business logic working first, which should not be UI dependent. Once all the tests pass.
• 4 : Refactor Aggregate Adjacent Resource Function to accept a static Class after the resources parameters. This will make things hopefully a little more clear and re-usable.
• 1 : Migrate I/O data to it's own folder to be usable by both test and examples for that matter
• 2: Write simple UI to consume the business logic
• 1: Work on getting it deployed to firebase
• 2: Polish UI to make it more appealing and usable(aka actionable)

Utility Function(s) Specs

• Aggregate Adjacent Resources : 0-n resources must be grouped in place based on there asc order and there common type(if that type is requested to be aggregated).
  1. Order the resource collection ascending
  2. Iterate over the resource collection doing the following:
     1. Resource Is Not Of A Required Type - This resource(like one of type Place) is not going to be be grouped so it does not need to be tracked. However this means that the currently grouped resources need to be stored away and the collection reset. Then also store the current resource as is.
     2. Current Resource Type Differs From Previous - A previous resource grouping needs to be stored as an aggregate resource since the current valid resource is of a different type. Then start a new grouping with the valid resource
     3. Current resource is first valid or a successive valid of the same Type - We can go ahead and append on the current resource to the resource grouping. And save the current resource as the previous resource.
     4. At end of loop body, derive previous type and order if the previous resource is set, which is not the case if the last resource was not a required type
  3. Before function is left we need to attempt create and store an aggregate resource for the last resource grouping

Utility Function(s) Unit Tests(or cases)

• Aggregate Adjacent Resources
  • Interface: aggregateAdjacentResources(resources, strategy)
  • The following three test cases should all be covered by the default I/O data that's provided
    1. Test that some Person resources are grouped
    2. Test that some Person resources are not grouped based on the natural ordering
    3. Test that Place resources are not grouped at all
  • Added more cases that are felt to be relevant as the implementation proceeds