8 ms·
Relay FAQ: Facebook's Data-fetching Framework for React
- ndreckshage 12y agoThis is the biggest thing for JSON payload control since...JSON APIs became a thing?
- modarts 12y agoWhat's "JSON payload control" exactly?
- ndreckshage 12y agoConfidence in returning the minimum to render a view. By default, without having to worry about over / under fetching data. Not having to worry about cleaning up endpoints when the needs of the consumer changes. A client that requests exactly what it needs, rather than hitting an endpoint with 'something', is extremely efficient.
- modarts 12y agoGreat answer; thanks for the clarification!
- ndreckshage 12y agoAlso, this is as interesting as React Native. And React Native is pretty interesting.
- j_s 12y agoDoes Facebook list browser requirements for all of this anywhere? (Translation: can I use any of this at my day job?)
- e1g 12y agoRelay is positioned as being complementary to React, and React itself currently works on IE8+. There is talk of phasing out IE8 compatibility from React (probably later this year), but as of today it works on IE8 perfectly fine for us.
- j_s 12y agoThanks! None of this tech requires much promotion since it's clearly the new hotness, but there is a silent majority of developers that would appreciate knowing when they can start paying attention professionally. Hopefully soon all JavaScript projects will include a list of supported platforms alongside their corner GitHub banner.
- cpojer 12y agoRelay will be same as React. Including React-Native of course – almost nothing in Relay is browser specific (except for routing). (source: I'm an engineer on Relay)
- wincent 12y agoI wrote the gist; happy to answer questions (although out and on my phone right now so I won't be super fast).
- Touche 12y agoCode example?
- cpojer 12y agohttps://www.youtube.com/watch?v=9sc8Pyc51uU https://www.youtube.com/watch?v=9sc8Pyc51uU - there are some examples in the talk from React JS Conf. We haven't yet finalized what API we will provide when we open source Relay. You'll certainly get one object, called Relay, however ;)
- Touche 12y agoI'm not watching a 30 minute video to get an idea of what writing code in this framework will look like. Can you really not give a single code example, even if the API is in a fluid state?
- underwater 12y agoApplication code will look like regular React components. The only difference is you declare what data you want in a GraphQL fragment. Here's a photo from the presentation that shows an example: https://twitter.com/devonbl/status/560532680513556481 https://twitter.com/devonbl/status/560532680513556481.
- iamartnez 12y agoA common problem in a service oriented architecture is needed to minimize the amount of round trips to a particular service. Example: To render a UI view, I need to fetch a list of friends, a list of posts, and a list of notifications. All 3 of these data types (friends, posts, notifications) have users associated with them. Instead of fetching users for the 3 data types 3 separate times, I need to flatten that into a single call. I end up with something like this: var [posts, friends, notifs] = yield [ getPosts(), getFriends(), getNotifs() ]; // executes in parallel var userIDs = new Set(); userIDs.addAll(posts.map(p => p.userID)); userIDs.addAll(friends.map(f => f.userID)); userIDs.addAll(notifs.map(n => n.userID)); var users = yield getUsers(userIDs.toArray()); return {posts, friends, notifs, users}; You can see where this gets cumbersome. I have to compose one of these for every kind UI view at the root level. On the one hand it's very explicit and the flow of data is very clear, but it also means relationships between data are dupicated in more than one place (often many places). Could GraphQL help with that scenario?
- javamonn 12y ago"Simplified server implementation: Rather than having a proliferation of end-points (per action, per route), a single GraphQL endpoint can serve as a facade for any number of underlying resources." GraphQL sounds tremendously exciting.
- deleted 12y ago[deleted]
- smspillaz 12y agoWhat's the name of the project that you're working on? edit: Looks like we'll never know ...
- zeroxfe 12y agoBased on his posting history, I think he was talking about this: https://www.loggur.com https://www.loggur.com
- tfb 12y agoSorry. I was hesitant to post the comment to begin with given that I'm 100% sure I'd be downvoted, which it was literally within 1 minute of posting it. You can check my comment history for details on the project.
- cpojer 12y agoStart talking about your implementation! It'll be a shame if you have worked on this for so long but no one else ever gets to see it. The world is a big place, chances are there is always someone else doing the exact same thing you are doing :)
- tfb 12y agoI'll start posting about it when things are further along. Unfortunately, I'm only one man and lack the resources to fund a team, unlike Facebook. It's just frustrating to see all this hype surrounding React/Relay when I've implemented essentially this exact functionality as part of a much larger project. For the past year (at least), I've considered this functionality to be fairly basic and implicit to modern web apps. However, millions of people will see it eventually. Epic Games will almost certainly be using it for the community portion of their new Unreal Tournament. This thread on their forums details some of the functionality on a more abstract level as it exists thus far: https://forums.unrealtournament.com/showthread.php?14859-Web-App-Design https://forums.unrealtournament.com/showthread.php?14859-Web...
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- pwpwp 12y agoI am confused: why is data made available as props and not as state?
- chacham15 12y agoThis https://github.com/uberVU/react-guide/blob/master/props-vs-state.md https://github.com/uberVU/react-guide/blob/master/props-vs-s... is a good explanation of the difference. But in short, it essentially comes down to who can manipulate the data. If the component will manipulate it, then it is state. On the other hand, if a difference source is going to be manipulating it, then it should be a prop. In this case, the client side of relay will be changing the data according to instruction from the server (e.g. a new message arrived). Therefore, the state is being passed as a prop.
- dustingetz 12y agoWould it be accurate to say that Relay's approach works best for component-based apps (not React components, "component" in the more general sense) - that is, the app is made up of a bunch of mostly separate components that encapsulate their own state, like {Feed, Ads, Groups, Messaging, Photos, Events, Minifeed}, which don't really share much state and don't require central coordination?
- wincent 12y agoNot really. It's true that those kinds of "components" will usually live on their own routes, but there's nothing intrinsic to the framework that favors that particular kind of app structure.
- skrebbel 12y agoI'd like to phrase dustingetz' question slightly differently: if you're building an app that does not have multiple relatively independent parts as dustin describes, does Relay still have a major advantage over what's currently common? (i.e. if one page is only ever one "thing", how is it better than just calling the right APIs from the router be done with it?)
- dlau1 12y agoThis looks incredible. Especially excited at the idea of a single store. I've always had a little bit of a beef with Flux when it came to interdependencies within stores. I feel like one of the problems with react that is currently not well solved is the integration of a client and server side router for a truly isomorphic application. There have been quite a few implementations that rely on a single om-like state that they serialize and deserialize to the client. Relay feels like it would fit extremely well into this paradigm.
- fattenap 12y agoCheck out http://entrendipity.github.io/astarisx/ http://entrendipity.github.io/astarisx/ . It uses a Single Source of Truth to accomplish what you're after.
- xanderjanz 12y agoIf you're interested in building GraphQL with Node+Mongo, checkout this github project: https://github.com/lutherism/GraphNoQL https://github.com/lutherism/GraphNoQL
- juliennakache 12y agoWow! That was fast!
- city41 12y agoThis looks very similar to a library I've been working on (live demo here for webkit browsers: http://city41.github.io/bookends/demo.html http://city41.github.io/bookends/demo.html), and it was inspired by a similar framework that is used at my former employer.
- phi16180 12y agoHere's the video introducing it at React.js conf: https://www.youtube.com/watch?v=9sc8Pyc51uU https://www.youtube.com/watch?v=9sc8Pyc51uU
- _wo6a 12y agoThis is very interesting. I'm currently a little bit of the way through solving some of the problems solved by Relay using an existing open source stack, and I'm curious if anyone has any thoughts on how it would compare. I've only skimmed the Relay video, and I haven't created a full React app yet, so forgive me if I get something wrong. First, for the framework-level handling of fetching all data before rendering, where the data needed by each component is defined in each component, just copy how it's done in react-router's async-data example [1], modified to expect a hash of promises as in [2]. The promises return Backbone-Relational models [3]. You can model arbitrary relations using Backbone-Relational, although many-to-many is apparently kind of hacky (but just needs work to be seamless). It supports parsing REST API responses with nested models and collections as related models. A REST API generator like Flask-Restless [4] creates these responses with a single efficient query. You have the flexibility to either sync all models before rendering, or render any component without all data already being fetched, and have it automatically re-render when loaded. Components subscribe and unsubscribe to model events at the proper points in the component lifecycle using react-backbone-component.[5] I missed this and wrote my own version [6] before I found it, but mine is cleaner, slightly more featureful, and presents a simpler API. Anyway, this requires some work to pull together, but I think it presents a viable alternative that: - uses existing libraries that do one thing well and allows as much departure from each elements of the architecture as you want - works with react-router, which is the shit - works with your existing REST API Relay looks wonderful, but it's possible to build the abstractions that do pretty much the same thing that support existing REST APIs. [1] https://github.com/rackt/react-router/blob/master/examples/async-data/app.js#L121 https://github.com/rackt/react-router/blob/master/examples/a... [2] https://github.com/rackt/react-router/wiki/Announcements https://github.com/rackt/react-router/wiki/Announcements [3] http://backbonerelational.org/ http://backbonerelational.org/ [4] https://flask-restless.readthedocs.org/en/latest/ https://flask-restless.readthedocs.org/en/latest/ [5] https://github.com/magalhas/backbone-react-component https://github.com/magalhas/backbone-react-component [6] https://gist.github.com/mwhite/f763c189f58de7af5d34 https://gist.github.com/mwhite/f763c189f58de7af5d34
- dragonshed 12y agoMuch of this FAQ reminds me of a little-known library called Breeze. BreezeJS is a stand-alone data library for SPAs which takes care of managing the lifecycle of data objects; querying, fetching, caching is all taken care of. Queries use OData by default, but implements a specific subset of the query language that can rendered down and used against REST apis. Breeze also provides server libraries for different stacks to easily integrate and get up and running. Granted the usecase of embedding declarative queries as part of a component which gets composed along with other components+queries is unique to React, but I speculate it wouldn't be too difficult to implement within Breeze. All that said, it will be nice to see another rich-data management library to compare and contrast. The days of painstakingly writing business objects in 34 places will end.