Context utility wish-list

[brainkim]

Some context properties I wish I have when dogfooding, which would be relatively easy to implement:

• this.hasRendered Distinguish the initial run from subsequent runs in the render loop.
• this.isRefreshing Distinguish between parent update and local update. Maybe it would be better to do this as an enumeration of render sources (this.refresh() called, parent renders, root render?, provision/consumer renders?).
• this.renderer Get an instance of the renderer so you can do checks for SSR or whatever.
• this.$key Get the key passed to the component. I often have to pass the key around separately this for debugging purposes.
• this.$ref Get the ref callback passed to a component. Could be used to override what is passed to the component.

[brainkim]

this.hasRendered - easy to do yourself within the render loop

this.isRefreshing - a fun name for its pun potential but hard to determine for async trees. Is an enqueued update a refreshing update if it is the result of both a parent rendering and a refresh call? Should the last call determine this?

[brainkim]

I have been toying with the idea of computed properties which match the special props. There could even be special behaviors when reading/writing, if it makes sense. What would reading each computed property mean for each prop?

• this.$key for $key

  • Readable?
    Readability case is great. Great for visually debugging key behavior, which is actually tricky. I often pass the key along as a data attribute data-key, I just want to get what the key is so I can do some sanity checks.
    Could even make the case for key chains (not sure what this means but it sounds interesting)
  • Writeable???
    Not really sure what over-writing a key would do. A component which re-assigns its key to a new value, would be the same as committing seppuku. The valid result might be instant unmounting (and remounting), but what is the use-case of that?
    One thing I have wanted is the ability for components to somehow “suggest” a key to the parent. I thought that make this API could be verbosely written as this.setOuterKey(key). The idea would be giving the component a suggested key when a $key is not explicitly passed.
    The implementation of outer keys or over-writable keys suffers from a chicken and egg problem, where a component can’t suggest a key without being called, but we don’t really know how to call the component without knowing if there’s already a keyed instance with the same key. API would have to be constrained somehow. Or maybe we need dark magic.

• this.$ref for $ref

  • Readable?
    If refs are just callbacks, then reading this.$ref might imply the default behavior for refs and components is disabled. The idea is if you read the ref, you are responsible for calling it with the thing you need, probably passing the ref to a child.
  • Writable
    Probably no valid use-cases for a writeable this.$ref

• this.$static for $static

  • Readable???
    this.$static would always be false if the component is rendering, so uhhhh not sure.
  • Writable?
    Could create some optional default static semantics to fully isolate a child rendering from a parent rendering. But a lot of the same problems as writable $key, it would be dark magic.

[brainkim]

Closing for housekeeping purposes. Going forward in 0.6, special props aren’t erased from component props, so you can just read them from there.