Other potential API updates

[taion]

Just some thoughts, to bring things more closely in line with facebook/relay#1298:

• Add subscribe as a method on a subclass of RelayEnvironment, and optionally implement [meta] Support real-time updates via event subscriptions facebook/relay#541 (comment) and add RelaySubscriptions.createContainer to make it available on props.relay
• Delegate subscribe implementation to custom network layer rather than inject into <SubscriptionProvider>

[edvinerikson]

add RelaySubscriptions.createContainer to make it available on props.relay

I am still not sure how that will be possible, do you have any small code-snippet that show it?

I like this, feels more integrated than the current API.
If you want to work on this, feel free to do so 👍

[taion]

It'd essentially be

function createContainer(Component, config) {
  return Relay.createContainer(injectSubscribe(Component), config);
}

[edvinerikson]

👍🏼 but that would still make us use subscriptions.subscribe, right?

On Saturday, 20 August 2016, Jimmy Jia notifications@github.com wrote:

It'd essentially be

function createContainer(Component, config) {
return Relay.createContainer(injectSubscribe(Component), config);
}

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#7 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADtdjKPv1IDXIpAno-UaByRBQtV18ZO_ks5qhyOXgaJpZM4Jo5Sq
.

[taion]

I would actually make that call up to context.relay.subscribe, which would then delegate it to the network layer.

[edvinerikson]

Hmm I see.. if we inject our HOC inside the Relay HOC we can hijack the props.relay object a little..

[taion]

Yup exactly. It's one more HoC, but it saves having to make two separate wrapping HoC calls.

[edvinerikson]

Yeah, sounds like a plan

[taion]

2nd point in OP is handled in graphql-relay-subscription.