Refactoring overview

This is a very quick overview of the refactorings in the Experiment and NewExperiment views.

The goals are:

• Minimize merge conflicts
• Separation of concerns and more maintainable code
• Eventbus code specific to interested components
• Prevent full page reloads on every eventbus event

This will be done through a series of PR's to try and keep the merge conflicts to a minimum.

At this stage I'm learning towards an MVP (Model-View-Presenter) architecture for the page where the Presenter is initially the view class just to help facilitate the refactoring effort. That being said at this point the effort is still mainly in separating out the components and eventbus handlers. Once that effort is done we'll be able to better asses the state of the code and determine if that is the best approach or not.

Steps to reach the goals

• Separate out components into classes
• Separate out eventbus subscriber logic to classes.

The next big step will be pushing out the handlers (subscribers) that are listening for eventbus events into their own subscriber classes. So that each component is responsible to update itself as needed. This is separate from a page load, or even a button pressed (user initiated action) where the view needs to let the components know about an action. That too will be later decided but for now we're focusing on moving out the eventbus listeners to their respective components.

Affects to developers:

• Any new components should be implemented in their own classes and NOT the views
• Code for Eventbus listeners for the components should be in their subscriber classes and NOT the views. The component class should NOT know about the eventbus or the listener/subscribers. The NavBar and NavBarItem are good examples of this. Do NOT put any new eventbus code in the updateExperimentComponents() method
• Separate business logic from component logic in the component code. For example in the NavBar the subscriber calls updateComponent() but has no idea what that means for the component.

Below is a diagram of the architecture I'm working towards now after which point we'll be able to better decide what architecture we really want to go with. In other words the architecture below is to separate out the code so that we can then decide how to properly implement it.