My app already has a large collection of selectors used by the various container objects. These are great for accessing different parts of the state and make refactoring the state much easier.
Now I want to use my selectors inside some of my reducer functions. The problem is that inside the reducer, the state parameter refers to a specific slice of the state, whereas the selector functions expect to be called with the state root object.
Contrived Example:
/* Selectors */
const getTodos = state => state.todos;
const getUncompletedTodos = createSelector(
[ getTodos ],
todos => todos.filter(t => !t.completed)
);
/* Reducer */
const todosReducer = (state, action) => {
switch (action.type) {
case 'ADD_TODO':
return [
...state,
{
id: action.id,
text: action.text,
completed: false
}
];
case 'REMOVE_COMPLETED_TODOS':
return getUncompletedTodos(state); // <-- this won't work
}
}
You selector works from root state object.
To fake this you could do
return getUncompletedTodos({todos: state});
But IMHO a better idea would be to reuse filtering function
/* Selectors */
const getTodos = state => state.todos;
const filterCompleted = todos => todos.filter(t => !t.completed)
const getUncompletedTodos = createSelector(
[ getTodos ],
filterCompleted
);
// inside reducer
case 'REMOVE_COMPLETED_TODOS':
return filterCompleted(state);
The answer by Yury works, but doesn't take advantage of memoization (see comments). If you want that, the solution would be to write the selector only for the slice of the state that it needs.
The selector would become:
const getUncompletedTodos = createSelector(
[todos => todos], // Not sure if there's a way to skip this redundancy and still take advantage of memoization with reselect.
todos => todos.filter(t => !t.completed)
);
In the reducer, you would simply use it like this:
case 'REMOVE_COMPLETED_TODOS':
return getUncompletedTodos(state);
However, when using the selector on the root state somewhere else, you use it like this:
getUncompletedTodos(state.todos)
The only downside I see is that you would have to remember to call the selector with the right part of the state, though of course if you're using TypeScript properly, it will remind you of this.
Related
Using the factory selector pattern const selectA = (id: number) => createSelector(...) I have an instance where I want to reuse this selector within another selector (that iterates through an array of IDs) but I don't know the value to pass into the factor selector when calling createSelector.
So I have a selector that I use whenever I want to get a slice of the state for component A.
const selectA = (id: number) =>
createSelector(
selector1.selectEntityMap,
selector2.selectEntityMap,
selector3ById(id),
(
thing1,
thing2,
thing3
) => {
return ...
});
Now I want to get a list of component A for each item in an array.
const selectListOfA = (ids: number[]) =>
createSelector(
selectA,
(selectorA) => {
return ids.map((id) => selectorA(id));
});
The problem is selectA, which is now a factory selector, expects a parameter, but I don't know it when calling createSelector.
I can get the code to compile by creating another factory onto of the factory
const selectAFactory = () => selectA;
And then reference the new factory in the createSelector
const selectListOfA = (ids: number[]) =>
createSelector(
selectAFactory, <<< here
(selectorA) => {
return ids.map((id) => selectorA(id));
});
But of course, what's now happening is the selector is returning a list of MemoizedSelector[].
This pattern doesn't seem like it should be this complicated, are people not reusing their selectors in this way, what am I missing?
The function returned by selectA is a standard function, ie nothing magical about it, as explained well in this blog post: https://dev.to/zackderose/ngrx-fun-with-createselectorfactory-hng
This means selectListOfA can simply call the function returned from selectA for each id and an array of the state slices for component A will be returned:
export const selectListOfA = (ids: number[]) =>
createSelector(
(state) => state,
(state) => ids.map((id) => selectA(id)(state))
);
This works as expected but since the projector function will be executed every time anything in the store changes (recreating the selector for every id) this solution will have major performance issues.
We could just as well simplify the code to this with equally poor performance:
const selectListOfA = (ids: number[]) =>
(state) => ids.map(
(id: number) => selectA(id)(state)
);
If we instead supply an array of selectors as input to the createSelector call then Ngrx will be able to correctly determine when it has to reevaluate the selectA selectors:
const selectListOfA = (ids: number[]) =>
createSelector(
ids.map((id) => selectA(id)), // This results in an array of selectors
(...resultArr) => resultArr
);
However, Typescript will complain since the createSelector method does not have a matching overload declared for an array of variable length so we need to loosen up the input type of the array (to any) as well as specify the return type of selectListOfA.
The answer to the question is thus:
const selectListOfA = (ids: number[]) =>
(createSelector(
ids.map((id) => selectA(id)) as any,
(...resultArr) => resultArr
) as (state) => string[]);
being rather new to react.js + redux, I'm facing the following conundrum:
I have multiple files, which need to update the store in exactly the same way, based on the stores current state. Currently I simply copy-paste the same code (along with the needed mapStateToProps), which goes again DRY.
Similar to something like the below, where getData is an Ajax call living in the actions file and props.timeAttribute is coming from mapStateToProps:
props.getData(props.timeAttribute).then((newState) => {
console.log(newState)
})
Would a function like that go in the actions file? Can the current state be read from within that actions file? Or does one normally create some sort of helperFile.js in which a function like that lives and is being called from other files?
Thanks!
If your file is executing the same action, then yes, you would put the action creator in a separate file and export it. In theory, you can put state in an action by passing the state as a parameter, but the philosophy behind an action is that it announces to your application that SOMETHING HAPPENED (as denoted by the type property on the return value of the action function). The reducer function responsible for handling that type subsequently updates the state.
You can access the current state of the store inside of an action creator like this:
export const testAction = (someParam) => {
return (dispatch, getState) => {
const {
someState,
} = getState(); //getState gets the entire state of your application
//do something with someState and then run the dispatch function like this:
dispatch(() => {type: ACTION_TYPE, payload: updatedState})
}
I like this approach because it encapsulates all the logic for accessing state inside of the one function that will need to access it.
DO NOT modify the state inside of the action creator though! This should be read only. The state of your application should only be updated through your reducer functions.
Yes, it is recommended to maintain a separate file for your actions.
Below is an example of how i use an action to fetch information and dispatch an action.
export const fetchComments = () => (dispatch) => {
console.log("Fetch Comment invoked");
/*you can use your Ajax getData call instead of fetch.
Can also add parameters if you need */
return fetch(baseUrl + 'comments')
.then(response => {
if (response.ok){
return response;
}
else {
var error = new Error('Error ' + response.status + ': ' + response.statusText);
error.response = response;
throw error;
}
},
error => {
var errmess = new Error(error.message);
throw errmess;
})
.then(response => response.json())
.then(comments => dispatch(addComments(comments)))
.catch(error => dispatch(commentsFailed(error.message)));
}
/* Maintain a separate file called ActionTypes.js where you can store all the ActionTypes as Strings. */
export const addComments = (comments) => ({
type : ActionTypes.ADD_COMMENTS,
payload : comments
});
export const comments = (errMess) => ({
type : ActionTypes.COMMENTS_FAILED,
payload : errMess
});
Once, you receive dispatch an action, you need an reducer to capture the action and make changes to your store.
Note that this reducer must be a pure function.
export const comments = (state = { errMess: null, comments:[]}, action) => {
console.log("inside comments");
switch (action.type) {
case ActionTypes.ADD_COMMENTS:
return {...state, errMess: null, comments: action.payload};
case ActionTypes.COMMENTS_FAILED:
return {...state, errMess: action.payload};
default:
return state;
}
};
Don't forget to combine the reducers in the configureStore().
const store = createStore(
combineReducers({
comments
}),
applyMiddleware(thunk,logger)
);
In your components where you use the Actions, use
const mapDispatchToProps = dispatch => ({
fetchComments : () => dispatch(fetchComments()),
})
Note to export the component as
export default connect(mapStateToProps,mapDispatchToProps)(Component);
I need to dispatch some actions in some order using redux-observable however, it takes just last action to dispatch. Please see example:
export const fetchClientsEpic = (action$, { dispatch }) =>
action$
.ofType(fetchClients)
.mapTo(fetchClientsPending(true))
.mergeMap(() => {
return ajax
.getJSON('some/get/clients/api')
.map((clients: IClient[]) => {
return fetchClientsSuccess(
map(clients, (client, index) => ({
key: index,
...client,
})),
);
});
});
fetchClientsSuccess is dispatched with clients but fetchClientsPending not, I totally do not get it why. I could use dispatch because I get it in params, but I feel it is not good solution(?). It should be done in the stream I guess. I am starting with RxJs and redux-observable. Is it possible to do?
Operators are chains of Observables where the input of one stream is the output of another. So when you use mapTo you're mapping one action to the other. But then your mergeMap maps that Pending action and maps it to that other inner Observable that does the ajax and such, effectively throwing the Pending action away. So think of RxJS as a series of pipes where data flows through (a stream)
While there is no silver bullet, in this particular case what you want to achieve can be done by using startWith at the end of your inner Observable
export const fetchClientsEpic = (action$, { dispatch }) =>
action$
.ofType(fetchClients)
.mergeMap(() => {
return ajax
.getJSON('some/get/clients/api')
.map((clients: IClient[]) => {
return fetchClientsSuccess(
map(clients, (client, index) => ({
key: index,
...client,
})),
);
})
.startWith(fetchClientsPending(true)); // <------- like so
});
This is in fact the same thing as using concat with of(action) first, just shorthand.
export const fetchClientsEpic = (action$, { dispatch }) =>
action$
.ofType(fetchClients)
.mergeMap(() => {
return Observable.concat(
Observable.of(fetchClientsPending(true)),
ajax
.getJSON('some/get/clients/api')
.map((clients: IClient[]) => {
return fetchClientsSuccess(
map(clients, (client, index) => ({
key: index,
...client,
})),
);
})
);
});
That said, I would recommend against synchronously dispatching another action to set the state that fetching is pending and instead rely on the original fetchClients action itself for the same effect. It should be assumed by your reducers that if such an action is seen, that some how the fetching still start regardless. This saves you the boilerplate and helps a bit on micro-perf since you don't need to run through the reducers, epics, and rerender twice.
There's no rules though, so if you feel strongly about this, go for it :)
I am a novice in Redux and I am creating a react book app with redux for state management. As far as I read about redux, it is recommended to use spread syntax to prevent state mutation. In my case, I have 2 default books and I want to output them when the program gets starting. Something goes wrong with the return in case 'GET_BOOK' because I got a syntax error. Any recommendation to reduce my code in bookReducers, I am highly appreciated
bookReducers.js:
let defaultBooks=[{
id:1,
title:'First Book',
description:'This is first book description',
price:33,
currency:'Euro'
},
{
id:2,
title:'Second Book',
description:'This is second book description',
price:24.50,
currency:'Euro'
}];
// Book reducer
export function bookReducer(state={books:defaultBooks} , action){
switch (action.type) {
case 'GET_BOOK':
return {...state, books:[...state.books]};
break;
case 'POST_BOOK':
// return state= action.load;
return {books:[...state.books,...action.load]};
break;
case 'DELETE_BOOK':
const indexToDelete=[...state.books].findIndex((book)=>{return book.id===action.load.id;})
return {books:[...state.books.slice(0,indexToDelete),...state.books.slice(indexToDelete+1)]};
break;
case 'UPDATE_BOOK':
const indexToUpdate=[...state.books].findIndex((book)=>{return book.id===action.load.id});
const newBook={
id:state.books[indexToUpdate],
title:action.load.title,
description:action.load.description,
price:action.load.price,
currency:action.load.currency
};
console.log(newBook);
return {books:[...state.books.slice(0,indexToUpdate),newBook,...state.books.slice(indexToUpdate+1)]};
break
}
return state
}
action.js
export function getBooks(){
return{
type:'GET_BOOK'
}
}
// add books
export function postBooks(book){
return{
type:'POST_BOOK',
load:book
}
}
// delete a book
export function deleteBook(id){
return{
type:'DELETE_BOOK',
load:id
}
}
// Update a book
export function updateBook(book){
return{
type:'UPDATE_BOOK',
load:book
}
}
The error occurs in return {...state, books:[...state.books]}; in case GET_BOOK in bookReducers. And here is my error:
You don't need a Redux action to get books, just have your component in react that connects to redux get the books from the state.
For example:
const library = (props) => {
// You can access your books here with this.props.books
}
const mapStateToProps = (state) => {
return {books: this.state.books}
}
const mapDispatchToProps = () => {}
export default connect(mapStateToProps, mapDispatchToProps)(library)
Edit:
Your interaction with Redux seems like you are trying to mock a RESTful api, you really don't need to do this, you can just have update, add, and delete book actions. If you want initial books in the state then add them when you create the store with the preloaded state parameter.
In link: Task-Based Updates
I don't understand below code:
import posts from "./postsReducer"; // missing this code??
import comments from "./commentsReducer"; // missing this code??
and why should do that?
const combinedReducer = combineReducers({
posts,
comments
});
const rootReducer = reduceReducers(
combinedReducer,
featureReducers
);
only featureReducers is okie? not need combindedReducer? anh what is postsReducer code, commentsReducer code?
Thanks for helps!
Unfortunately that example is a little confusing (one of the few places in the normally solid Redux docs). If you go here and check out the 'third approach', you'll see this concept explained a little better.
Essentially, postReducer and commentReducer are there to handle actions that modify only posts or only comments--that is, things that do not require changes to multiple tables (e.g posts AND comments). featureReducer is the task-based reducer that handles actions that require updates to multiple tables.
A very simplified example:
const postReducer = (state = {}, action) => {
return state
}
const commentReducer = (state = {}, action) => {
return state
}
const combined = combineReducers({
posts: postReducer,
comments: commentReducer
})
const createComment = (state, action) => {
switch(action.type) {
case 'CREATE_COMMENT':
// update multiple tables (linked example actually does an ok job ok demonstrating this)
return updatedState
default:
return state;
}
}
const rootReducer = reduceReducers( combined, createComment )
In this example, the first two reducers just create the state shape. The third, which depends on the first two to set the state up for it, updates multiple tables across the redux store.
Your state shape will look like this:
{
posts: {},
comments: {}
}
If you're confused about reduceReducers, just try to think of it like combineReducers, only it doesn't affect state shape.