React Transmit

[ericclemmons]

Though this project (which started internally @ work) was made public a couple months before @RickWong's react-transmit's initial commit, Transmit's comparison to Relay, React Native support, and continued development looks like it may have superseded this project.

Our goals are similar, although with v1 I dropped the comparisons to Relay, since lack of GraphQL made the comparison to Relay tenuous at best, in my opinion. Really, this project's goals were always to support isomorphic lazy-loading of data, primarily for work.

I've continued development of this project internally, since a major relaunch @ work greatly depends on this (there's even a sibling Flux implementation that gets around dispatcher issues), but I'm curious if it's best to let @RickWong's project be endorsed rather than risk fragmentation, stagnation of this project, or competing over the same problems.

I've tagged @RickWong several times, mainly to get his feedback :)

[gilesbradshaw]

noooo am just getting into it! :P

[ericclemmons]

Hahah, no worries @gilesbradshaw :) It works great, and has more features + fixes getting prepped for release in June.

The question popped up in other channels, so I wanted to bring it up here to have an open discussion.

[gilesbradshaw]

I feel it would be good if any of the upcoming changes that can easily be implemented could be

[RickWong]

With Transmit, I'm trying my best to make it a Relay_ish_ API that works without GraphQL. That's the most important goal. The current Transmit implementation supports only Promises, but I'm planning to support Streams and Observables as well (see RickWong/react-transmit#25). That way more of the update/write functionality provided by Relay and GraphQL (see @josephsavona's comments in RickWong/react-transmit#9) can be implemented with standard Javascript APIs that we're used to, know and love.

I think the main difference between Transmit and React-Resolver is that I have decided to follow the Relay API and feature set closely. In that sense I'm restricted in terms of supporting other patterns. Transmit's server-side rendering is also very basic compared to React-Resolver's recursive component traversal etc.

So even if our projects' goals are similar, I believe it's a good thing to continue to explore different paths together. Fragmentation shouldn't be a huge issue as lots of people prefer to have more libraries to choose from, to find one that resonates well with their own projects.

[ericclemmons]

@RickWong Thanks for weighing in! You've done fantastic work with Transmit, and I wanted to ensure as both projects progress, it's easier for users to know the key strengths/patterns/opinions in how they both work.

Admittedly, despite the API differences, on the surface they almost seem to be drop-in replacements for each other, which is why I questioned pursuing this project when yours has done so well.

Thanks again, and I hope to see you in http://reactiflux.com/ ! :)