Redux Action命名与结构规范：前端布尔型状态的选型疑问

Great question! This is a super common dilemma when working with Redux for UI state management—let’s break down the tradeoffs and best practices here.

First, I totally agree with you that the REQUEST/SUCCEEDED/FAILED pattern for API-related actions is rock solid. It’s clear, predictable, and maps perfectly to the async flow of data fetching. Now, for UI state like modal visibility, both approaches you mentioned have their place, and the choice depends on your specific use case and future plans.

Let’s break down each approach #

Approach 1: Explicit SHOW/HIDE action types #

// Action creators
const showCatModal = () => ({ type: 'CAT_PICTURE_MODAL_SHOW' });
const hideCatModal = () => ({ type: 'CAT_PICTURE_MODAL_HIDE' });

• Pros: This is incredibly semantic. Just looking at the action type, you immediately know exactly what’s happening—no need to check the payload. Debugging becomes easier because your Redux devtools will show clear, self-documenting actions like CAT_PICTURE_MODAL_SHOW instead of a generic SET_VISIBILITY with a payload.
• Best for: Binary, mutually exclusive states that are unlikely to evolve beyond two options. Modals are a perfect example here—99% of the time, they’re either visible or not, and you won’t need to add a "partially visible" or "minimized" state later.

Approach 2: Generic SET_VISIBILITY with a payload #

// Action creator
const setCatModalVisibility = (isVisible) => ({
  type: 'CAT_PICTURE_MODAL_SET_VISIBILITY',
  payload: isVisible
});

• Pros: This is far more flexible. If your state ever needs to expand beyond a simple boolean (say, your modal later gets a "loading" state, or you want to support different visibility levels), you only need to adjust the payload values instead of creating entirely new action types. It also works well if you need to sync the modal’s state with an external source (like a parent component’s prop).
• Best for: States that might evolve into more than two options, or when you need to dynamically pass the desired state value rather than triggering a specific toggle.

Your core question: Are SHOW/HIDE actions only for boolean data? #

Short answer: They’re optimized for boolean binary states, but that’s not a hard rule. The key is matching the action’s semantic meaning to the state it’s modifying.

For example:

• A toggle switch (on/off) works great with TOGGLE_SWITCH_ON/TOGGLE_SWITCH_OFF, but you could also use SET_SWITCH_STATE with true/false.
• If you have a state that’s not boolean (like a tab selector with TAB_A/TAB_B/TAB_C), explicit action types like SELECT_TAB_A make more sense than a generic SET_ACTIVE_TAB—unless you need to dynamically set the tab from a variable, in which case the generic approach is better.

Final Recommendation #

Stick with Approach 1 for your modal example! Since modals almost never need more than "show" or "hide" states, the explicit action types will make your code more readable and self-documenting.

If you’re worried about future changes, ask yourself: Is there a realistic chance this state will need to support more than two options? If the answer is no, go with the explicit actions. If yes, lean into the generic setter pattern.

And most importantly—keep your team’s style consistent. Whatever approach you choose, make sure everyone on the project follows the same convention to avoid confusion.

内容的提问来源于stack exchange，提问作者BoxOfTech