[Feature]: Rewrite Reactivity Logic

[DeepanshKhurana]

Guidelines

• I agree to follow this project's Contributing Guidelines.

Description

Based on @Gotfrid's comment on #12

Another comment (out of scope of this PR) I have is related to a pattern that I see in main.R and which I find weird: > observeEvent(..., { renderUI(mod$ui()); mod$server() }
Would it be cleaner if you create ui+server for a particular app section only once, and inside a corresponding server you decide what to render by passing a reactive key, e.g. state$selected_app()$guid?

Problem

The reactivity logic is awkward and can be streamlined a bit as Pavel suggests.

Proposed Solution

We could take Pavel's suggestion to have the reactiveValues inside the modules instead if having the current mechanism does not offer a clear advantage.

Alternatives Considered

N/A