可重复使用的React + Flux表单组件的存储(具有不同字段的多个表单的一个组件)

时间:2015-05-05 16:30:10

标签: javascript reactjs reactjs-flux flux

在我正在处理的应用程序中,我有几种不同形式的不同字段。我想为每个表单创建一个可重用的组件。

  • 表单#1可以包含以下字段:电子邮件,密码
  • 表单#2可能包含以下字段:移动消息,平板电脑消息,桌面消息,背景颜色,文本颜色

对于这个例子 - 让我们说我使用表格#1;这是我用于该用例的代码:

var LoginForm = React.createClass({
    handleSubmit: function(){
        var formValues = {
            username: '',
            password: '',
            url:      '/api/login/'
        };

        // Submit form, whee!
        FormActions.submit(formValues);
    },
    render: function(){
        var formSections = [
            {
                name: 'Sign in here',
                fields: [
                    {
                        name: 'username',
                        label: 'Username',
                        type: 'text'
                    },
                    {
                        name: 'password',
                        label: 'Password',
                        type: 'password'
                    }
                ]
            }
        ];
        return (
            <FormComponent sections={formSections} handleSubmit={this.handleSubmit} />
        );
    }
});

所以,我希望能够传递我的FormComponent一个包含包含字段的表单部分的数组。表单部分的示例包括:个人信息,送货地址,账单明细。

我想弄清楚的是,我怎样才能产生一般性的&#39; Flux商店将处理我抛出的任何形式字段。例如,在我的formSections数组中,我希望能够传递不同的字段并仍然使用Flux架构。

如果我使用这种模式犯了错误,我不确定的是什么;我应该为我将要使用的每种类型的表单创建一组不同的操作,常量,存储等吗?或者,创建一个能够处理单个FormComponentStore商店中不同字段的表单组件是一种可靠的做法吗?

2 个答案:

答案 0 :(得分:1)

我已经在React / Flux中实现了类似的功能,我对结果非常满意,尽管它可能对你整体使用有点过于专业。我将简要介绍一下移动部件,您可以决定是否喜欢这种方法,以及哪些部件可能符合您的需求。基本思想是能够生成表单DOM以及从一组配置中与我的API的不同部分进行通信所需的行为。首先,这里是我如何实例化一个BasicAPIForm,它是一个由Flux&#34; FormStore&#34;支持的有状态组件:

请参阅code

render: function(){
  var formProps = {
    formId: "uniqueFormId1",
    fieldsMeta: {
      name: {inputType: "text", label: "Name", required: true},
      description: {inputType: "textarea", label: "Description", required: true},
      url: {inputType: "text", label: "Website URL", required: true},
      email: {inputType: "text", label: "Contact Email", required: true},
      image: {inputType: "image", label: "Logo", required: false, filename: "logo.png"}
    },
    defaultValues: {
      name: "",
      description: "",
      url: "",
      email: "",
      image: null,

      imageData: null,
      actionState: "ready",
      message: ""
    },
    columns: [
      { fields: ['image'], className:'col-xs-5 col-sm-4 col-md-3' },
      { fields: ['name', 'description', 'url', 'email'], className:'col-xs-7 col-sm-8 col-md-9' }
    ],
    apiContext: {
      formId: this.props.type,
      apiCollectionKey: "theRightCollection",
      actionUrl: "/v1/resource/items",
      method: "POST",
      successHttpStatus: [201],
      successMessage: "New resource created"
    }
  };
  FormStore.getOrInitFormData(this.props.type, formProps);

  return (
    <div className="active-panel api-form image-upload-form clearfix">
      <div className="container-fluid">
        <BasicAPIForm {...formProps} />
      </div>
    </div>
  );
}

BasicAPIForm组件需要一个唯一的formId,它可以理解的字段列表(例如,图像上传字段需要filename之类的道具),一些初始状态(defaultValues),关于如何将字段分组为列的一些配置,以及帮助APIStore构造API请求并处理响应的类似API配置对象。 BasicAPIForm是一个复杂的组件,有很多行为,因为我已经实现了它。对于每种不同类型的输入(例如&#39;图像&#39;),我必须创建一个组件。在BasicAPIForm的render()方法中,它基本上通过列进行搅拌,根据配置和当前状态呈现每个列中的字段。这是一个&#34;管理&#34;表单,所以每次更改DOM输入时,它都会更新自己的状态并与FormStore同步。

调用FormStore.getOrInitFormData(this.props.type, formProps)中显示的FormStore与应用程序上所有活动表单的状态保持同步。这可能不需要;你可以保留组件中的所有状态。

我们实施中的APIStore负责管理前端应用程序已知的数据,并与服务器通信以获取或发布所需数据。 APIStore监听表单POST操作,从FormStore获取相关输入和API配置,向API发送请求,存储结果,并在完成时创建成功或失败操作,FormStore(和Form组件)可以接受显示结果。

在我们的FormStore实现中,当BasicAPIForm发生状态更改时,FormStore中的表示将被修补。为不同的表单存储不同的数据不是障碍,只要数据基本上看起来像JSON {}对象,并且表单有一个唯一的密钥,通过对FormStore的所有调用传递。起初,我在Store中存储了默认值和类型,但这并没有很好地扩展,因此我将其移动到上面的大配置blob,它可以非常接近相关的渲染代码。未来肯定会有一些重大变化。

这种方法在我们的项目中继续发展。到目前为止,第一次构建需要很长时间,但每个连续的重构和新形式的添加花费的时间越来越少,总体而言,它似乎越来越高效。这证明了在表格中进行高度互动和润色。

答案 1 :(得分:0)

我无法评论,所以我必须回答,但这真的是一个简单的问题。为什么要使用FormStore ?,表单的提交不应创建域实体,然后将该实体保存到EntityXStore?

例如,我从一个简单的Flux应用程序开始,我也有一个LoginForm,但如果登录成功,我有一个UserStore存储(或不存储)用户。

除非在您的具体情况下保存已履行的表格是有道理的,因此我说这是一个问题。

对不起英文!