站内搜索

本次搜索找到结果 18 条

阅读完之前的第四和第五章,分享了 DialogTable 组件的一点设计,还有一些小组件的代码都已经上传到 Github-smarty 上去了,能够自己翻阅看一下,接着我们开始整合这些组件来合成一个业务模块。

React 导读(四)中分享了组件设计最开始考虑的一些事情,不能介绍太矛盾了,其实对于设计来讲是有正反两面的分析的,就跟评论历史事件来看都是要分两面进行分析的。今天我们接着分享剩下的内容,我觉得不一定要求多,但是一定要带着思考来写,有点意识流。

首先弹框和表格是最常用的组件,下面就介绍表格吧。

一、前言

React 导读(三) 中介绍了项目的背景、功能需求、项目结构以及组件的划分层次,接下来我们就来看下实际的代码,这一篇文章会主要分享用到的基础组件的封装。

二、基础组件设计

我们在设计组件之前本来是有一个流程和过程的,这里我写的组件并不会像社区内的组件库一样完善或者说一定考虑很完整,但是这样也会有一个好处,可以按照自己项目的需求进行定制、扩展以及冗余的代码会更少,当然很多时候节约的这点代码可以忽略不计(特别是项目业务代码和库的代码比例上升到一定比例过后,所以一切不说场景就说某某库太大的观点都是不正确的),因为大家都有按需加载的配置可选。这不是绝对的,不一定说你自己花时间和精力去开发一个这样的库就更好,因为随着项目规模的扩大,组件的种类和需求会越来越多,即使是一个不错的工程师利用技巧保障项目持续迭代,但是人的时间和精力是有限的,更合理的利用现有资源去提高效率才是最优先考虑的事情。

前言

React 导读(一)

React 导读(二)

在之前 2 篇文章中中学习到了写第一个 Web 组件以及常用的生命周期函数的使用,这篇文章将继续之前的目录,开始新的知识点补充:

  1. [x] React 如何编写 Hello World!
  2. [x] React 中三个最基础、最重要的东西
  3. [x] React 中的 JSX
  4. [x] 你的第一个 Web 组件
  5. [x] React 中最开始需要关注的生命周期
  6. [x] React 一个组件集合的简单交互
  7. [x] React 开始一个项目的一点建议
  8. [ ] React 简单的项目结构组织

这篇文章主要会介绍第6、7的知识点。

六 & 七、React 一个组件集合的简单交互以及开始一个项目的一点建议

为什么要将6、7合在一起写呢?不是因为想偷懒...其实是脱离一个场景和合适的开始去规划组件等设计都是不合理的,多多少少都有点交集,所以将这 2 点融合在一起是更利于学习和理解的,到这里就已经不是太基础的内容了,基本上代码量会有所提高,但是分析依然会很细致。

这里用一个简单的表格的添加删除编辑搜索四个功能来作为实例吧。 因为这应该是日常开发过程中遇到过程最多的,我将参考 bootstrap-table 的方式来开发一个简单的表格组件和约定配置来做,感觉比较自由,如果你动手能力好且业务稍大和复杂可以参考 antd 设计规范来实现,目前市面上应该蚂蚁这套用的比较多,但是这并不意味着我们就一定是按照他来做,实际项目不复杂的情况是可以使用更简单的方式。

做这个开始之前,首先要假设一点场景和基本需求,这样才能带着去思考如何实现以及更接近需求目标。

前言

在上篇文章React 导读(一)中学习到了写第一个 Web 组件,这篇文章将继续之前的目录,开始新的知识点补充:

  1. [x] React 如何编写 Hello World!
  2. [x] React 中三个最基础、最重要的东西
  3. [x] React 中的 JSX
  4. [x] 你的第一个 Web 组件
  5. [ ]React 中最开始需要关注的生命周期
  6. [ ]React 一个组件集合的简单交互
  7. [ ]React 开始一个项目的一点建议
  8. [ ]React 简单的项目结构组织

前言

写这篇文章的主要目标是让初学者更快的上手 React 的项目开发,能有一个循循渐进的理解过程,第一次写较基础类的,有不太好的地方希望能直接指出来。需要有一定的 JavaScript 基础和 NPM 的使用经验。不多说了,下面会按这个顺序进行介绍:

  1. React 如何编写 Hello World!
  2. React 中三个最基础、最重要的东西
  3. React 中的 JSX
  4. 你的第一个 Web 组件
  5. React 中最开始需要关注的生命周期
  6. React 一个组件集合的简单交互
  7. React 开始一个项目的一点建议
  8. React 简单的项目结构组织

一、前言

模式是一种规律或者说有效的方法,所以掌握某一种实践总结出来的模式是快速学习和积累的较好方法,模式的对错需要自己去把握,但是只有量的积累才会发生质的改变,多思考总是好的。(下面的代码实例更多是 React 类似的伪代码,不一定能够执行,函数类似的玩意更容易简单描述问题)

二、前端的关注点迁移

这篇文章主要介绍现在组件化的一些模式,以及设计组件的一些思考,那么为什么是思考组件呢?因为现在前端开发过程是以组件为基本单位来开发。在组件化被普及(因为提及的时间是很早的或者说有些厂实现了自己的一套但是在整个前端还未是一种流行编写页面的单元)前,我们的大多数聚焦点是资源的分离,也就是 HTML、CSS、JavaScript,分别负责页面信息、页面样式、页面行为,现在我们编程上的聚焦点更多的是聚焦在数据组件

Typedoc 这是一个 TypeScript 项目的文档生成工具,类比 jsdoc。下面使用一个简单的例子来介绍一下这个工具。如果不想看文章的可以直接看下代码配置其实就能理解了~不过后面有介绍一些配置过程中的问题。栗子代码

一、前言

其实对于软件开发模式来说,Angular 有着整套的一条龙服务,而 React 只是单纯的解决 View 层的问题,如果只是使用 React 开发项目会或多或少有点麻烦。下面主要讨论下数据层的东西,之前出了一个 mobx 来解决这个问题,但是这里想换个思路套用一下。其实 mobx 主要是声明了 @action, @computed, @observable 等元素来做到将 Store 作为一个可监控的源头,自动做到 VM 的效果,下面我也是,不过我采用 Rx 来做这个事情,简单利用下这种思想,能不能不污染我的原始数据(因为如果是双向的一种数据结构,那么就会被包装成监听类型的数据结构),这样我们调试的时候依然看到的是清晰的数据,并且还可以解决最初 Flux 库的一些麻烦,经过 Rx 改造的结果,可能比 mobx 的可测试性更好一些,具体就不说了,先谈 DEMO。

如果不想看文章的可以直接看代码 GitHub

1. Observables & Reactive

先来一个简单直观的例子:

const { Observable } = require("rxjs");

const source$ = Observable.of([1, 2, 3]);
source$.subscribe(x => console.log(x));

过滤器节点:subscribe

2. Declarative Transformation( 声明式转换 )

如果我们想要平时开发的数据转换功能,可以使用一些类似管道的工具来做。

Observable.of(1, 2, 3)
    .map(n => n * 2)
    .subscribe(x => console.log(x));

过滤器节点:map、subscribe。我所理解的就像一条溪流流动的水,然后 map 这类 API 就像水桶,将水装入进行加工,当然,其他 map 的特性先不用细致了解。

3. Lazy Transformation( 懒执行透明特性 )

Observable 能够在流动的过程中进行选择,所谓的懒特性就是不会像 Promise 一样,给了一个数据承认,就一定会让你接受,你可以选择不接受或者现在不接受,先这样子理解。