In this post, I'll go through the data flow in the KubeRider application. The application is still fairly small and I'm experimenting with few ideas as I add more features.
There are four main components in the application.
I've found the using events to communicate between components makes it easy to decouple different parts of the application. However it comes with its own challenges which I'll try to cover in a separate post.
So taking an example usecase of loading the available contexts when the application starts up, here is a diagram showing the communication between the different components.
And the code behind covering the implementation of this feature.
It starts with KubeRiderMainPresenter which is the presenter behind the main form. Its job is to initialise few things and then leave the rest of the use-cases to component specific presenters.
def after_window_loaded(self):
if not self.initial_load:
return
self.initial_load = False
self.contexts_loader.load_contexts()
self.check_updates()
The context loader is an instance of ContextsLoaderInteractor which handles the execution of kubectl command to load contexts.
It runs the kubectl config get-contexts --output='name' command to get the list of contexts, parses it and saves it in application state.
Then it emits an event to notify that the contexts are successfully loaded.
app.data.signals.contexts_loaded.emit()
This event is then consumed in the ToolbarPresenter to refresh the user interface in the toolbar.
app.data.signals.contexts_loaded.connect(self.on_contexts_loaded)
Which then loads the contexts from state and populates the combo box.
def on_contexts_loaded(self):
contexts_ui = self.__get_combox_box("Contexts")
contexts_ui.clear()
contexts = app.data.load_contexts()
for ctx in contexts:
contexts_ui.addItem(ctx)
The chain continues after that with loading the currently active context and then the namespaces based on that context but the general pattern follows the same principle as above.
Top comments (0)