将Ionic组件的ngModel变量转为NgRx状态的正确方式及疑问

我正尝试将Ionic应用迁移至NgRx。在某组件中，原本通过以下方式将模型变量与textarea绑定：

组件代码：

myTextVar: string = '';

模板代码：

<ion-textarea ... [(ngModel)]="myTextVar" ...></ion-textarea>

为转换为NgRx实现，我做了以下操作：

1. 在模块reducer中添加相关字段：

const textsFeatureKey = 'texts';

export interface TextsState {
    ...
    myTextVar: string;
}

export const initialState: TextsState = {
    ...
    myTextVar: '',
};

export const textsReducer = createReducer(
    initialState,
    ...
    on(TextsActions.setMyTextVar, (state, { myTextVar }) => ({ ...state, myTextVar })),
);

2. 定义action：

export const setMyTextVar = createAction('[Texts Page] Set myTextVar', props<{ myTextVar: string }>());

3. 定义selector：

export const selectMyTextVar = (state: AppState) => state.texts.myTextVar;

随后修改组件代码：

myTextVar$: Observable<string>;

constructor(
    private store: Store<{ texts: any; }>
) {
    ...
    this.myTextVar$ = this.store.select(selectMyTextVar)
}

ngOnInit() {
    this.myTextVar$.subscribe(text => {
        console.log('mtv debug', text);
    })
    this.store.dispatch(setMyTextVar({ myTextVar: 'some initial text'}));
    ...
}

通过以下方式能成功在textarea中加载myTextVar：

<ion-textarea [ngModel]="myTextVar$ | async" ></ion-textarea>               

但更新状态时，采用了如下方式：

<ion-textarea (ionInput)="onIonInputMyTextVar($event)" [ngModel]="myTextVar$ | async" ></ion-textarea>              

组件中对应的方法：

onIonInputMyTextVar(event: any) {
    this.store.dispatch(setMyTextVar({ myTextVar: event.detail.value }));
}

该方式能正常工作，但仅为更新一个模型变量就编写了大量代码（处理ionInput事件、reducer、selector等），显得繁琐且不易维护。因此产生以下疑问：

1. 我的实现方式是否正确？有没有更简单的转换ngModel变量的方法？
2. 我是否应该采用这种方式？传统的[(ngModel)]='myTextVar'在这类简单场景下是不是更简洁？
3. 这是单组件的简单变量，NgRx的真正适用场景是什么？是否仅用于多组件共享的数据？

1. 实现方式的正确性与简化方案 #

你的实现方式是正确的，完全符合NgRx的核心工作流（Action → Reducer → Selector → 组件订阅）。

要简化ngModel的双向绑定逻辑，可以直接使用ngModel的拆分语法糖，省去组件内的事件处理方法：

<ion-textarea 
  [ngModel]="myTextVar$ | async" 
  (ngModelChange)="store.dispatch(setMyTextVar({ myTextVar: $event }))"
></ion-textarea>

这种写法直接在模板中完成状态的读取与更新，代码更紧凑，不需要额外定义组件方法。

如果项目中有大量类似的NgRx表单绑定需求，也可以封装一个通用的ngrxFormControl指令，把订阅状态和分发动作的逻辑统一封装，但单个字段场景下，上面的语法糖已经足够简洁。

2. 是否应该在该场景使用NgRx？ #

不推荐。传统的[(ngModel)]在这种单组件独立维护的简单变量场景下，确实要简洁得多：不需要定义Action、Reducer、Selector，代码量减少80%以上，维护成本极低。

NgRx带来的状态可追溯、统一管理等优势，在单组件局部状态场景下完全体现不出来，反而会增加不必要的复杂度。

3. NgRx的真正适用场景 #

NgRx不是“所有状态都必须用”的框架，它的核心价值体现在以下场景：

• 多组件/跨页面共享状态：比如用户信息、全局主题、购物车数据，这类需要在多个组件中读取或修改的状态，用NgRx可以避免组件间传值的繁琐，保证状态一致性。
• 复杂状态逻辑：当状态更新涉及多个步骤、异步操作（比如API请求）、或者需要根据多个条件计算状态时，NgRx的Effect、Reducer可以把逻辑抽离到组件外，让组件只负责UI渲染。
• 状态需要可追溯/调试：NgDevTools可以记录每一次状态变化的动作，方便排查问题，对于复杂应用的调试非常有用。
• 大型团队协作：统一的状态管理规范可以让团队成员遵循相同的开发模式，减少沟通成本，避免状态管理混乱。

简单来说：局部的、独立的组件状态，用原生ngModel或组件属性即可；全局共享、复杂逻辑的状态，才是NgRx的主场。

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