Implement UC: View Map Home Page

[evomimic]

Implement the View Map Home Page Use Case as described in: UC: View Map Home Page

Dependencies

None

Proposal

• [ ] Frame out the initial client-side architecture with dance and holon data types defined in the Model Layer
• [ ] Define the Home Page HX from the wireframe provided
• [ ] Implement the Use Case Main Flow

Testing

We are using human-testing (not automated testing) protocols for testing use case functionality.

• [ ] Ensure application runs and the use case steps can be performed successfully

Definition of Done:

• [ ] Human use case testing confirms all flows and visual elements are complete and functioning
• [ ] PR approved

[evomimic]

@nphias : Maybe a place to start with the client-side architecture would be to get aligned around some basic architectural principles.

I'm assuming the following:

1. Separation of concerns -- clean separation of presentation logic (in dynamically selectable visualizers) from model objects (entity objects) from behavioral logic (e.g., controllers + dances).
2. Decoupling -- careful attention to dependencies to support "plug and play" visualizers and dynamic task flows.

I'm open to discussing the trade-offs in the following areas:

3. Data Flow -- I favor bi-directional flows (though we may initially start with uni-directional)
4. State Management -- I'm leaning towards centralized state management (e.g., Redux) vs. distributed state management (e.g., Component-Based Architecture). But this distinction may be somewhat moot in our architecture due to the uniform nature of the API. I'm leaning AWAY from direct DOM manipulation.
5. Interaction Handling -- I suspect mediated interaction (e.g., MVVM) will more easily accommodate dynamic visualizer selection
6. Reactive (RxJS, MobX) vs. Non-Reactive (MVP, MVC) -- I lean towards the former

For the Model layer,

• I see DanceRequests and DanceResponses as pretty simple and passive DTO's. CallZome behavior should be the responsibility of a Controller object, not a DTO.
• DanceRequest, DanceResponse, RequestBody, ResponseBody are standard objects within the Uniform API. They should remain independent of any specific types of dances. Thus, they should NOT have dance-specific build methods.
• When a new dance_type is introduced, we will need to introduce builders on BOTH the client- and guest-sides. Following some consistent patterns and naming conventions on both sides can make this straightforward and less error prone . On the guest-side, each dance_type has a standalone build_xxx_dance_request function, where xxx is the dance_name. Using the exact _dancename as part of the function name makes it very clear what type of dance request is being built, even when several dances have similar names. I would expect the client-side to follow the same naming convention.

[evomimic]

Here's a diagram that reflects some additional thoughts I have on client-side architecture.