React context-like feature

[sebastiandedeyne]

Would a React context-like feature ever be added?

Context is an implicit way to pass down data from a component without having to pass them through props on every level.

https://facebook.github.io/react/docs/context.html

It's generally not a good idea to use context for application-specific logic, but it's very useful for objects like stores.

Currently working on a helper mixin that achieves something similar, but would prefer to see this baked in the core.

[posva]

Why would you need contexts with Vue?

[sebastiandedeyne]

Afaik, there currently isn't a way to implicitly pass down props.

Current options:

• Explicitly passing down props isn't clean for object like stores for your application state
• Plugins kind of solve the issue, but they can only be applied globally
• this.$root is an option, but then you're forced to set the data on the root component

[sebastiandedeyne]

Possibly interesting alternative to context: plugins / mixins that apply to a component and all of it's descendants, instead of globally

[fnlctrl]

@sebastiandedeyne Functional components already have this context feature. (http://vuejs.org/guide/render-function#Functional-Components) Though currently normal components don't.
I guess it can be useful if normal components can get access to it too.

[sebastiandedeyne]

Context in functional components only provides data from the direct parent (I don't think context provides anything more than a normal component would have?), it doesn't solve the problem of passing data to deeper descendants—which is what context in React does, it's the same name for something different.

[ktsn]

I think this feature is nice to have in Vue.
Because some libraries actually implement this behavior (vue-router, vuex) their own global mixin.
And also, there is a use case on userland, e.g. passing an event bus instance to all descendants.

[sebastiandedeyne]

To get the ball rolling;

I needed this feature in a recent project, and solved it by writing two mixins: expose and inject. You'd apply expose to a parent component, and it would create an $exposes object on the vm with whatever data you want. Next, calling inject on a child component would recursively look for a parent component that exposes a certain property, and set it on the child component (prefixed by a $).

Vue.component('parent', {

    template: '<div><child></child></div>',

    data() {
        return {
            user: {
                name: 'Sebastian',
            },
        };
    },

    mixins: [
        expose(vm => ({
            user: this.user,
        })),
    ],
});

Vue.component('child', {

    template: '<div>{{ $user.name }}</div>',

    mixins: [
        inject('foo'),
    ],
});

[simplesmiler]

@sebastiandedeyne that is quite an interesting approach.

Maybe something like:

var parent = {
  ...,
  expose: ['user'],
};

var child = {
  ...,
  inject: ['user'],
};

[posva]

That would be the same as passing props.
I'm still unsure about the utility of a context on Vue.
To me it looks like the context issue is either solved with a state management library or by injecting something to every instance.
Is a plugin that inherits the context from the parent overriding properties what you're looking for @sebastiandedeyne ?

[sebastiandedeyne]

Let's say that, hypothetically, Vuex wouldn't be implemented as a global plugin, but as something that can be applied on a per-component basis.

• Passing down the store as a prop to every single child component would be counter-intuitive
• There's no other way to inject an object that's set on a specific component instance

I'm looking for a mechanism to have a property based on something that a parent—an ancestor—component defines, not necessarily the direct parent.

[ktsn]

Of course we can do the same thing by explicitly passing values to props but I think we sometimes need such implicit data propagation.

In my case, for example, I am writing canvas rendering abstraction library and it has components for shapes (rect, circle, etc...) rendered on canvas. The shape components have to be descendants of context component that has canvas DOM element.

Example:

<!--
  context has canvas element and it will render all shape components in its descendants.
-->
<context width="300" height="300">
  <rectangle x="10" y="20" width="50" height="50"></rectangle>
  <group x="100" y="100">
    <triangle v-for="t in triangle" :x="t.x" :y="t.y"></triangle>
  </group>
</context>

When the data of shape components are updated, I have to notify to context component through an event bus to re-render the canvas. To do so, I need such react's context-like feature to propagate an event bus because 1) it is quite verbose to write props for all shape components, 2) it needs its own event bus instance for each context component instance and 3) I don't want to manage this on global state management as this is local view's concern.

[HerringtonDarkholme]

Context is a convenient construct for library author and coupled components(for example tabs and tab-panes). For a library, it is quite strange and lame to encapsulate library local context in a separate global store. Library author might be able to take the burden of passing props all over, but components may also be an interface for end users. @ktsn has a good example and good arguments for context feature.

But I have some questions about after reading React's context document. (disclaimer: I'm not a React user.)

It seems the cooperation of context and shouldComponnentUpdate is not a problem in Vue because context is also reactive. So there is no need to workaround context update as described in this article.

But I still have questions on how context should be found. For example, should context only be found as a child's parent? Or ancestors? Or only closest ancestor?
If we resolve context as ancestors, how can we handle context key conflict? It seems React's context implementation only chooses the closest ancestor. Example.
And this will easily cause problem when multiple libraries provide different contexts with the same name, say, one component receives context from another library component. Or we can collect all context properties from ancestors and pack these properties into an array or a map?

Also, should context in parent component be visible to all its children, in templates and slots? Or only to children in its template? Or only to children in slots? Or provide an option for users to choose?

[HerringtonDarkholme]

I have tried some toy implementation. It seems to be fully doable in user land without touching vue core.
A working example here and source here.

It requires a token for each expose and injection to avoid conflict. Other parts look like api suggested by @simplesmiler and @sebastiandedeyne

var user = createToken('user')
var parent = {
  ....
  expose: (vm) => ({[user]: this.user})  // computed property key for token
}
var child = {
  inject: {user} 
  // {user: user},the first user is for property name, second is token value
}

Context visibility is fully controlled by token. If parent component does not expose token, context is not visible to any child. Another helper method $inject can let children decide to inject only closest context or inject contexts from ancestors, all the way up to $root.

I agree with @posva that context is very delicate and can be replaced by passing props. Including it by default promotes bad practice to beginner. If advanced users do need it in library code, the implementation overhead is just few lines of code.