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

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions