which one do u use?
I saw react-komposer
a while back. While it solves some problems, opens unnecessary complexity. withTracker
is a HOC for following reactive data sources, they are different in concept.
Should be stop tracker inside “container” (meteor-react-data-withTracker) (react-komposer@1.13.1 composeWithTracker) while componentDidUnmount ?
it seems stop tracker will clean client side minimongo on next subscription.
we’re using react-komposer@1.13.1 currently, and we might change this to react-meteor-data.
react-komposer
import { composeWithTracker } from 'react-komposer'
const container = (props, onData) => {
const sub = Meteor.subscribe('test')
if (!sub.ready())
return onData({ sub })
const data = Test.find().fetch()
onData({ sub, data })
}
const component = ({ sub, data }) => {
if (!sub.ready)
return <div>loading</div>
return (
{data.map(datum => <div>{datum}</div>)}
)
}
const Test = composeWithTracker(container)(component)
import { withTracker } from 'react-meteor-data'
const container = props => {
const sub = Meteor.subscribe('test')
if (!sub.ready())
return { sub }
const data = Test.find().fetch()
return { sub, data }
}
const component = ({ sub, data }) => {
if (!sub.ready)
return <div>loading</div>
return (
{data.map(datum => <div>{datum}</div>)}
)
}
const Test = withTracker(container)(component)
should i stop subscription while component unmount ?
it seems react-komposer@1.x doesn’t stop tracker, that cause trouble with our app(mainly we can’t write client side selector same as server side).
i’ve made an example
if we can’t write client side selector (because you can only get those data from server), the cursor will overlap between switching route.
if u check ddp frame, you can see it sub next page first, then unsub. and its adding documents first then remove old data one by one, and this will cause container rerun times.