前端程序员干货

实现TODOS应用

2017-09-12  本文已影响0人  BIGHAI

自由来自于对自身力量的限度和上天所设置的自然之限度的了解。接受生命的限度,而不与其抗争,我们才能获得自由。相反,如果我们屈从于一时之念,想得到我们无法控制的事物时,我们就会失去自由。

THE BOX

1.功能分析

完成一个todos应用,对于处理每一个todo的方法应该有addTodo,deleteTodo,reverseTodo。同时在展示todo的时候还得筛选一下哪些todo应该展示-filterTodo。对于一个应用来说,我们第一步应该先着手设计一下store所维护的state对象。通过我们在上面提到的对todo的操作方法来看,在应用中那是必须要有一个todos状态的,而又还得进行一下筛选,并且这个筛选条件又是可以变化的。因此这个筛选条件也得是一个状态。所以我们的storeState可以这样设计:

{
  "todos": Array,
  "filter": String
}

问题是我们应该如何设计每一个todo?如果把每一个事项抽象成一个对象的话,那么我们先来看看对这个对象进行操作的方法有哪些,在上面也提到了,分别有addTodo,deleteTodo,reverseTodo。对于addTodo来说,它要将一个由输入文本加工而来的 todo添加到todos数组中。对于deleteTodo来说,它要将todos数组中指定位置的todo给删除。对于reverseTodo来说,它要将todos数组中指定位置的todo给翻转一下状态。对于filterTodo来说,我们要根据todos数组中每一个todo的完成状态来决定是否显示。通过上面的分析,我们的每一个todo应该长什么样就已经很清楚了:

{
  "text": String,
  "id": Number,
  "finished": Boolean
}

到这里,我们的store所维护的状态对象的设计就已经大致完成了,后期如果发现不足的话,那么我们将会继续更改。那么现在可以着手思考第二个问题,如何架构应用。

通过上面的分析,我们可以明白我们的todo应用有这么几个处理事项的方法:addTodo,deleteTodo,reverseTodo,filterTodo,showTodo。很显然这些方法都需要跟store进行交互。虽然对于我们的todos应用来说,我们可以把所有的reducer以及actionCreater和actionTypes文件合并到各自独属的那个文件中,但是呢,这样做的话,如果我们的应用所需要维护的状态太多以及响应类型太多的话,这样的一个架构会使得我们的代码太过臃肿,不便于日后的项目维护。因此,我们应该将这这部分逻辑转移到各自的组件中去。我们上面也提到了,有增加组件,删除组件,翻转组件,筛选组件,展示组件的功能。如果我们把这几个功能每一个都独立出来实现的话,那么我们将需要多个功能子文件,当项目一大起来的话,功能子文件将会井喷式增多。同时,对于这些功能来说,挺多功能是使用同一个store所维护的状态的,那么问题来了,我们的combineReducer()函数是否接受多个reducer对应同一个store所维护的state字段?先抛开这个不说,如果我们将每个功能都分开来的话,那么对于某些功能来说,它是强烈依赖某些功能的,比如对于展示功能来说它很依赖增添组件功能以及翻转,删除功能以及筛选条件,而为了实现这种依赖性,我们的组件将会是强耦合的,而这不利于一个系统。那么问题来了,我们如何根据功能来划分组件呢?一般的,我们可以根据下面这个原则划分:是否依赖store中的同一部分状态,如果是的话,那么最好将其放在同一个组件中实现。

对于上面所分析的功能:增加,删除,反转,筛选,展示。对于增加功能来说,很显然它是与todos进行交互的;对于删除功能来说,todos;对于反转功能来说,todos;对于展示功能来说,todos,filter;对于筛选功能来说,filter。

此时就很明显了,我们应该把增加,删除,反转,展示放在同一个组件中todos实现。筛选功能放在filter组件中实现。这个时候的架构设计还是有一点轻微的耦合的,不过程度不高——展示组件时需要读取store所维护的filter字段将它拿去去与filterTypes做比较,因此此时todos需要引入外部的filter组件的actionTypes文件。这个时候,应用的架构设计就已经基本明确了。

介绍一下redux库中的combineReducers方法,这个方法可以将多个reducer函数组合成一个结果函数返回,这个结果函数会囊括前面各个reducer函数的工作。问题是combineReducers函数接受的是一个对象,这个对象的键值就是我们的reducer函数所需要的storeState中的相应状态名,值就是reducer函数了。

因此,对于我们每个组件来说,它的reducer函数所接受的第一个参数state是自己所需要的,而不是store所维护的整个状态,同时,对于一个复杂的应用来说我们一般都很少在应用的根文件中设定store的初始值了,那么该怎么做呢?毕竟初始值是必需的——此时我们就会在每个功能组件的reducer文件中为自己所需要的store的某部分state设定初值,至于这个state的名字,前面也提到了,在combineReducers函数会被作为参数对象的键名被绑定。

第二个需要注意的地方是,尽管在每个功能文件中里reducer文件所接受的state是局部的。但是对于mapStateToProps来说,他所接受到的state那可就是整个storeState对象了。


2.总结

webpack打包过程中遇到了一些小问题:

return (
   <ul>
    todos.map()
  </ul>
)

上面那个是错的,由于没有熟悉JSX规范:在JSX中出现的js表达式必须在{}里面,因此对于上面加一对大括号就可以了。


项目地址
美化后地址

无样式效果 美化后效果

END

上一篇下一篇

猜你喜欢

热点阅读