React: Beyond 'how we redux' - how to visFilter for multiple lists? (& sneak peak at PlanetX Boilerplate)

I’m still figuring out redux, so I’m doing exercises by building a meteor 1.3 boilerplate app that I hope to polish and share with the community before the end of the month.

This is my Task List Page that creates each task list rather than creating only 1 list as most tutorials do. Most applications are more advanced than a simple todos app, and I have had difficulty in finding advanced coding samples for learning.

My question is how do I change the “(Meteor) How We Redux” tutorial’s setVisibilityFilter to be able to control the visibility of completed items per list. I think the issue is that the store only has one value visibilityFilter, so when one toggler is changed it changes the state for all the togglers and thus the data that the component displays. I think the change has to be in this TaskLists.jsx file I’ve linked, but you can find actions in imports/ui/actions/ and reducers in imports/ui/reducers

Thanks a lot for your help and I’ll be sure to link this thread in my /docs/ for others to reference.

I also noticed that some people are compiling lists of react tutorials, my latest list is /docs/

Really cool! I like your use of Material UI too.

I know Redux but am brand new to Meteor, so I’m not the best for this… But what the hell.

To start, unless callbacks are too painful (sibling components or nested), or you need the state to persist, I wouldn’t put UI information in the Redux store. Instead, consider using React’s component state. Everything I’m about to write could be solved with:

this.state={isFiltered: true}

for the Task Lists component. I know Dan uses filters in his example, but he’s a big advocate of using component state in addition to a Redux tree.

Your state tree for the visibility reducer is simply a string. I would initialize the reducer as an empty object and pass an action object for that task list.

After retrieving the task lists and firing the appropriate action creator / dispatching the action, your visibility reducer state would look something like this…

  taskListVisibilityFilters: {
      [taskListId]: {
            isVisible: bool,

(I’m not sure how to initialize that with Meteor. In a traditional REST, once the tasks lists were received, actions would dispatch to the reducer)

Then your filtering component will call an action creator with the task list ID and the new visibility (true or false)

Once processed that action creator will dispatch an action…

return { type: 'SET_VISIBILITY_FILTER, filter, taskListId }

Your reducer would be:

    return ReactUpdate(state, {
        [action.taskListId]: {
              isVisible: {$set : action.filter}

(ReactUpdate is React’s immutability helper. I like it because it follows the Mongo syntax)

My approach may be a little overkill (you could use an array for tasks that are visible or not), but I’ve found, inevitably, you want more of the same kind of data so I like objects. For instance, change the state tree from ‘taskListVisibilityFilters’ to taskListUi and then you can save any ui information in the task list’s object.

Hopefully that helped.

Thanks for your response. Since then, I’ve taken several steps backwards to better understand redux. I concluded that to redux with meteor, the client data should also be stored in the state treating Meteor as an API for redux to asynch with.

I haven’t gotten back to visibilityFilter but I think it will it be easy once I have this new methodology in place. I’ve currently a step backwards from there.

My page is probably loading all the lists (using redux REQUEST_LIST, etc.). Loading all the lists is fine.
Each list has multiple tasks. I get an infinite loop of “requesting task items” and when I console in on this line: it seems that my subscription is never ready.
My reducer is here:

I’m using the Redux Real World - Reddit API Example.

I think that I need to change my action/reducer in some way but I don’t see the solution and infinite looping makes it difficult to debug what’s happening beyond the TaskItems subscription never being ready.

P.S. It’s been a few weeks @LawJolla - how is your meteor learning coming along? Do you agree with my conclusions ?