Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow nested CachedRenders #46

Merged
merged 1 commit into from
Jul 25, 2016
Merged

Allow nested CachedRenders #46

merged 1 commit into from
Jul 25, 2016

Conversation

jgaskins
Copy link
Member

This fixes #45 by recursively invoking the cache checker if needed, but I want to have a discussion surrounding it before it gets merged in. Specifically, two things I want to discuss:

  1. Is this a good idea?
    1. I have no idea what the maintenance burden of this might be. It will probably be trivial, but still worth having a conversation.
    2. It will probably overflow the stack when someone inevitably returns self from render. Do we care?
  2. What are the performance implications?
    1. If I'm being completely honest, this is my main concern. I haven't benchmarked this and that makes me nervous. :-)
    2. The most common case will be that the while loop is not invoked, but the conditional, while pretty cheap, isn't free and is potentially invoked thousands of times during a render. Even cheap things can get expensive in loops.
    3. CachedRender is intended to keep our apps fast. If it adds significant overhead, we should decide whether to support this use case.

cc @balmoral

@jgaskins jgaskins merged commit 6b2ec3e into master Jul 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

First rendering of a CachedRender component failing
1 participant