Refactoring overview

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

Please feel free to contact me if you need any further details or help with any of the information below. Especially with the Request from Developers section.

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 (with page redirects and reloads that quickly adds up)

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 Experiment views but it's still too early to confirm yet. That being said at this point the effort is mainly in separating out the components and eventbus subscribers. 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
• Prevent full page reloads on each eventbus event

The first big steps will be separating out components and eventbus subscribers into their own classes. Each component will be responsible to update itself as needed, preferably avoiding database calls if possible. 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 decided later but for now we're focusing on extracting components and eventbus subscribers.

Request from developers (ExperimentView and NewExperimentView) :

• Any new components in these views should be implemented in their own classes and NOT in the views
• Code for to handle the eventbus events for the components should be in subscriber classes and NOT in the views (some have already been created). An example includes NavBarItemRunUpdateSubscriber.
• The component class should ONLY subscribe/unsubscribe to the listener/subscribers. Do NOT put any new eventbus code in the updateExperimentComponents() method An example includes ExperimentsNavBar
• Component code should only include GUI code and NO business logic. The same as for example you don't include business logic in the Label class.

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.