v2.1 Implementation of Subscription component #1483
Conversation
|
Noun or verb? <Subscription subscription={subscription}>or <Subscribe subscription={subscription}>I'm using I have no idea what is generic, but this illustrates where I'm going: <Subscribe node={subscripton}>
<Query node={query}> |
|
I'm in favour of sticking to the exact language used by graphql for the component: A |
|
I'm not sure. Using query is a length improvement, and I think an accurate name (not positive though). Either way I want to reduce length without reducing explicitness or clarity. |
excitement-engineer
changed the title
# Conflicts: # yarn.lock
Generated by 🚫 dangerJS |
| children: (result: any) => React.ReactNode; | ||
| } | ||
|
|
||
| export interface SubscriptionState<TData = any> { |
There was a problem hiding this comment.
Remove export. I just call these State since they are essentially private/not exported.
There was a problem hiding this comment.
I tried this but typescript doesn't allow it with error:
'extends' clause of exported class 'Subscription' has or is using private name 'SubscriptionState'.
There was a problem hiding this comment.
ok, if TS is going to complain and require the export (an obscure open issue in TS), then it is best to leave it as-is.
src/Subscriptions.tsx
Outdated
|
|
||
| private client: ApolloClient<any>; | ||
| //TODO: What is the type here? | ||
| private queryObservable: any; |
There was a problem hiding this comment.
From ApolloClient.d.ts (your IDE should allow you to follow the declaration of client.subscribe
import {Observable} from 'apollo-client/util/Observable'
Observable<any>There was a problem hiding this comment.
Great thanks!
src/Subscriptions.tsx
Outdated
| this.initialize(nextProps); | ||
| this.startSubscription(); | ||
| this.setState(this.getInitialState(nextProps)); | ||
| } |
There was a problem hiding this comment.
My preference in this section is that it is unnecessarily broken up. initialize and getInitialState are not reused, so i would simply bring their implementation up here. It increases comprehension without increasing complexity.
I could even say the same about start/end subscription - but I would have to see it before making a judgement.
My go-to in this case would probably be all that code right here. All init code, not reused, fairly simple, and if needed, a one-line comment to break it up.
Reasoning: when I see code in a method that is one-line I think - this must be reused, where is it reused and why?
There was a problem hiding this comment.
I'm not sure I understand? All of these methods are being reused in the component
There was a problem hiding this comment.
ah, ok good. It would have been easier for me to spot in my IDE, but you are right, these are needed.
Implementation of the Subscription component for the next version of react-apollo.