Redux or Relay?
If you are a web developer using React, then there will be times when you have to solve the problem of how to control all the states of the component on the client side. Modern webs can't wait to respond from the server and can't always call back data from the database when changing pages. Therefore, the state management layer is generated and by the time of writing, the two most commonly used libraries to manage this class are Redux and Relay. The article will analyze the differences between these two libraries.
Architectural overview
Both Redux and Relay are inspired by Flux's design, a model architecture for web app design. The idea of Flux's platform is always to have data run one way from Store to React components. The component calls Action Creators, which dispatch tasks to the Actions Stores are tracking. Flux was introduced by Facebook but they did not provide a library for it. But the idea of Flux is very well received and developed by the community, even there are some types of applications that can be customized according to the needs of each enterprise. Especially Flux is very suitable to go with React because it also prevents data from being output directly from the component to the store where the switch for the action dispatch takes care of.
REDUX
Redux takes very little idea from the Flux-style design. Collecting many stores in Flux to a central Store and handling Reducer actions makes state management easier. The special thing is that the Reducer is the pure function that receives the variable as a state and returns the new state (does not change the state of a component as in Flux's design). Redux Store can contain any data and Redux also doesn't care about the data source.
Redux is a small library, so if you want, you can add middleware to handle other processes (many open source middleware you can add to it for free).
RELAY
The relay is more inherited from Flux. There is also a central store, all changes are via actions (Relay is called Mutation). But Relay does not allow control of Store contents but instead relies on help from GraphQL query to automatically query the necessary requirements of components in the current component tree. Store can be adjusted through changing API but all mutation will correspond to mutation of server. The difference from Redux is that the Relay store only stores the corresponding data in the server in Relay and that server must have the GraphQL API.
Relay provides a lot of features including data calling from the database and ensuring that only the requested data is exported. Relay supports good pagination (page sharing) and especially permanent scroll pages (just scroll all pages and load new pages). Relay mutation can update, report status and rollback (return to the previous time).
Component Link
Redux
Both can link well to React Components. Redux is less dependent on React, but can use other comfortable view libraries ( Pre-act or Deku ) but Relay must depend on React (or React Native). However, if you want, you can still get component classes from Relay and use it outside React.
Redux encourages the presentation and processing of data logic through the concept of dumb and smart components. Normally, component wise will be created by Redux, store will listen to state of general and dispatch actions respectively and stupid component is React component normally. The component will not transmit data to the component stupidly by function and through props. Usually the component system will prioritize the design of as many stupid components as possible and the less the component, the better.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | import {connect} from 'react-redux' const getVisibleTodos = (todos, filter) => { switch (filter) { case 'SHOW_ALL': return todos case 'SHOW_COMPLETED': return todos.filter (t => t.completed) case 'SHOW_ACTIVE': return todos.filter (t =>! t.completed) } } const mapStateToProps = (state) => { return { todos: getVisibleTodos (state.todos, state.visibilityFilter) } } const VisibleTodoList = connect ( mapStateToProps, ) (TodoList) export the VisibleTodoList default |
Redux requires a top-level component called a Professional Provider who is responsible for transmitting props for the Redux components.
1 2 3 4 5 6 | render ( <Provider store = {store}> <App /> </Provider>, document.getElementById ('root') ) |
Relay
In Relay, most components will be smart. Relay React components bundle in Relay Container. Container notifies data to render with GraphQL fragment. Containers can create fragments from component children, but requests are often unclear. In this way, containers are separated from each other and you can reuse or change them without worrying about data being transmitted. Fragment that is solved will be transmitted into props via props.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Todo class extends React.Component { render () { return ( <div> {this.props.todo.id} {this.props.todo.text} </div> ); } } const TodoContainer = Relay.createContainer (Todo, { fragments: { todos: () => Relay.QL` fragment on Todo { id, text } `, } }) |
Fragments in the component tree are created together in a query. Data that was previously called will be adjusted accordingly for the query if there is enough data needed, no actual query will be executed.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | const TodoListContainer = Relay.createContainer (Todo, { fragments: { todoList: () => Relay.QL` fragment on TodoConnection { count, edges { node { $ {TodoContainer.getFragment ('todo')} } } } `, }, }) |
Relay has the original Component called RootContainer that acts as an entry point. RootContainer requires a Container and a Route. Relay Route determines the initialization of the query, this query will be aggregated with the fragment of that component component into a root query. Because component trees are the same but may have different originating data, it is mandatory to have a Route, such as a <TodoList /> component that can render the entire to-do list for a team or a person. The route can receive parameters (parameters), for example an object id can be passed in.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | TodoRoute class extends Relay.Route { static routeName = 'TodoRoute'; static queries = { todoById: () => Relay.QL` query { todoById (id: $ id) } ` }; static paramDefinitions = { id: {required: true} }; } render ( <Relay.RootContainer Component = {SingleTodoContainer} route = {new TodoListRoute} />, document.getElementById ('root') ) |
Mutations
Change the data in the store often found in the server-side data management layer. We always want to respond to user actions as quickly as possible (optimistic update), then, we wait for the server to return the results of the data actually called and confirm if the data is successfully retrieved.
We try to make a mutation change a TODO item, update on the server and rollback if it fails.
Redux
We use thunk middleware to do async actions. We will dispatch a trial of optimistic change first, then either confirm it, or rollback it.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 | function todoChange (id, text, isOptimistic) { return { type: TODO_CHANGE, todo: {id, text, isOptimistic} }; } function editTodo (id, text) { return (dispatch, getState) => { const oldTodo = getState (). todos [id]; // Perform optimistic update dispatch (todoChange (id, text, true)) fetch (`/ todo / $ {id}`, { method: 'POST' }) then ((result) => { if (result.code === '200') { // Confirm update dispatch (todoChange (id, text, false)) } else { dispatch (todoChange (oldTodo.id, oldTodo.text, false)) } }) } } // In store handler case TODO_CHANGE: return { ... state, todos: { ... state.todos, [id]: { id, text, isOptimistic } } } ) // Time to dispatch store.dispatch (editTodo (todo.id, todo.text)); |
Relay
Relay is not able to customize actions. Instead, we create Mutation using DSL mutation Relay. It is worth noting that GraphQL mutation is very special – mutation is an operation first and then a query, so we can request data with GraphQL mutation the same way as GraphQL query . We can request data changes so that Relay knows what to update.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 | class ChangeTodoTextMutation extends Relay.Mutation { // Get the mutation name on the server so we can call the server getMutation () { return Relay.QL`mutation {updateTodo} `; } // Direction props transmit mutation to server input object getVariables () { return { id: this.props.id, text: this.props.text, }; } // Get the query based on the result of payload and all data changed getFatQuery () { return Relay.QL` fragment on _TodoPayload { changedTodo { id text } } `; } // Determine really what relay should change in the store. This case is // item in the `changedTodo` element in the result must be the same // with the item in the store via id then update the corresponding item in the store getConfigs () { return [{ type: 'FIELDS_CHANGE', fieldIDs: { changedTodo: this.props.id, }, }]; } // To Relay create an optimistic update, we create a disguised response // from the server. Very simple. getOptimisticResponse () { return { changedTodo: { id: this.props.id, text: this.props.text, }, }; } } |
Now this mutation can be dispatched like an action
1 2 3 4 5 6 | Relay.Store.commitUpdate ( new ChangeTodoTextMutation ({ id: this.props.todo.id, text: text, }), ); |
We can pass more callbacks to commitUpdate to respond to successful or failed mutation. In any case, rollback will always automatically update if it fails.
1 2 3 4 5 6 7 8 9 10 11 12 | Relay.Store.commitUpdate ( new ChangeTodoTextMutation ({ id: this.props.todo.id, text: text, }), { onFailure: () => { console.error ('error!'); }, onSuccess: (response) => { console.log ('success!') } }); |
DSL mutation is also considered a weakness of Relay. Sometimes finding the exact query that the Relay expects and the parameters passed is not easy. If used correctly, Relay will solve many complex situations, such as applying mutation to items in the components of a data list in a certain page. However, maintenance members Relay are implementing mutation improvement by adding a lower API class (low level API).
Working with paginate data (data distributed by page)
Redux
There are many ways to paginate in Redux – as much as RESTful API. The first is to create a reducer to keep the information of the number of data that has been called and the next page number.
Practical examples that apply Redux paging are in Redux github.
Because Redux does not standard API server, this framework cannot handle automatic paging. But also because of that, you can work with API and with many different standards and store data in Redux store
Relay
GraphQl API has Connection concept , an abstract concept of data list. The key issue is all connections in the Relay. The GraphQL accepts the paging parameter and all the items of the connection have a cursor , which is used as a pointer to the connection related to the item. Connection has a pageInfo field that includes information related to the next page.
Relay will do most of this heavy work based on the standard API. We just need to update the parameter and it automatically calls the item we don't have.
To use the cursor, we use the variables of the Relay Container (can be changed in the Container always). These variables can be passed to GraphQL fragment
Here is a simple example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | class PaginatedTodoList extends React.Component { nextPage () { const lastElement = this.props.user.todos.edges.length - 1; this.setVariables ({ after: this.props.user.todos.edges [lastElement] .cursor; }); } render () { return ( <div> <TodoList todos = {this.props.user.todos} /> {this.props.user.todos.pageInfo.hasNextPage? <button onClick = {this.nextPage}: <div> Last page </div>} </div> ); } } const PaginatedTodoListContainer = Relay.createContainer (PaginatedTodoList, { fragments: { user: () => Relay.QL` fragment on User { todos (first: 10, after: $ after) { edges { cursor } $ {TodoList.getFragment ('todos')} pageInfo { hasNextPage } } } `, }, initialVariables: { after: null, }, }); |
When a user presses a button to load more items, we only update the variable after automatically calling missing data and updating the list.
Conclude
Both libraries have been thoroughly tested by many large companies. Relay provides more functions, thus limiting the ability to customize backend more and depends on GraphQL API. Redux is very flexible but so you have to write more code.
Article translated from source: https://www.reindex.io/blog/redux-and-relay/
ITZone via Techmaster