使用Redux时，在React视图中保留一些条件代码是否是反模式？

Question

I am fairly comfortable using React but I am confused about what is the right way to do this when using Redux. Everyone out there seems to be doing things their own way. On a button click I call a method in React view like:

handleClick(value) {
  this.props.action.handleValueChange(value);
}

Now I want to do a lot more things on this button click. So should I do those things in the triggered action or in the handleClick method itself?

handleClick(value) {
  this.props.action.handleValueChange(value);
  // is this fine?
  if(this.props.someValue === "somethign")
    this.props.action.fetchSomeData(value);
}

I can also use thunk and do this in the action creator itself, but what is the recommended way of doing such things?

Answer 1

Think of it in terms of single responsibility and pure functions. That method should handle the click and translate it into the next hoop, like passing a baton in a relay race. The click can cause an action or signal a state change. You can notice times when things are getting too logic heavy when you start using the word and (it's like your Batman signal to modularize):

• Get user input
• and save it to component state
• and call action creator
• and get the response back
• and save that into some new state
• and re-render the view

Consider making a "dumb" function for everything you can call for each thing you need done. Where they reside exactly is up to you. It's the same logic as when you remember learning about database calls and "dumb models" that don't care what you do with the data, they just get exactly what they were asked to. Give them input, like "get user id 1337" and they respond "here {}" or "no". They have one responsibility, and if you refactor everything around them, they hold their ground until the day "get user by id" is no longer sufficient.

This will make your apps nicely modular if you aim for the pureness. It could show up as nicely segmented methods in your class, or you could import each function in. If you want to do further reading, you will get a lot out of high-level articles and videos about functional programming. Listen to the things that are important to them. You will notice it allows for great modular architecture with lots of small pieces of code coming together that are reuseable. It is functional composition but it is also object composition. These things are never-more relevant in React also since you could create your whole app in one class if you wanted to :)

Redux-thunk fits in because it's app-level state. There is component-level state as well, and not just container state. When you pass props into a dumb component, it works with these props as its "state", so its like child #2. I trust you are thinking about hierarchies now. If you step from one dimension into the other, your logic may be over-extending. Maybe the logic could ask for what it needs, and a separate handler could join the handler to its data.

The point I'm trying to make is that I wouldn't intuitively look inside handleClick to find some event listener for when data comes back from the database. Anything longer than like 50-100 lines is getting pretty savage long and taxing for someone to have to read through. If you come back later and connect the top to the bottom, someone else might call it spaghetti, but they can't if you have one file per function per action per event (in which every function has one job and every object has one purpose).

I'm not saying it has to be similar to this. I'm just saying modular is king because it makes it easy to extend, maintain, and refactor. The less I need to absorb and front-load my short term memory when I see your code, the more I will enjoy it.

Here is a sample directory tree that my opinion prefers, and I hope illustrates a way of thinking, not an exact solution:

components/
    auth/
        auth_actions.js
        auth_types.js
        auth_reducer.js
        LoadingSpinner.js
        LoginForm.js
        SignupForm.js
        SplashScreen.js
queries/
    mongodb_checkIfEmailExists.js
    mongodb_getUserById.js
    neo4j_getUserByNodeId.js            

Now, imagine your friend is working with you. You are doing work on the Login View and she is working on the Dashboard View. You won't encounter any file collisions while working at the same time. You also probably have a pretty good idea what is going on as soon as you look at the files. You will also notice that all your imports are like ./Something rather than ../../../actions .

I hope this is illustrative to the thinking style not the exact solution.