Skip to content

[Feature]: Rewrite Reactivity Logic #13

@DeepanshKhurana

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions