为什么会有mini-core

原生开发有哪些缺点？

• 取值和赋值繁琐

  原生开发中，取值方式为this.data.x，赋值方式为this.setData({x: y})，如果代码量大，逻辑复杂。则可读性极差。

• 对TypeScript支持性较差

  原生开发中，因为官方设计api时并未向TypeScript靠拢，而是采用option api的形式，既 Page({data: {x: y}}}) 与Component({data: {x: y}})，这种传统js的方式，后续官方通过泛型加入了对TypeScript的支持，但是多个泛型对代码组织结构和可读性都并不是很好的解决方案。

• 代码冗余、结构不清晰

  对于开发中来说Page({data: {x: y}}}) 与Component({data: {x: y}})这样的代码是和业务逻辑无关系的，然而小程序开发中却需要这样来使用，造成代码组织结构嵌套过深。

• 页面之间缺少有效的逻辑交互解决方案

  对于在下一个页面更改了数据，而需要在当前页面刷新数据这样的操作，通常需要实现当前页面的onShow声明周期方法，页面显示时对数据进行刷新。如果不加判断直接刷新，则会造成不必要的流量浪费和用户感知到页面的刷新，体验较差。如果判断则需要存储或者设置标识位，代码冗余且容易出错，且错误信息不易于排查。

• 页面之间传递参数被统一处理为字符串，使用时需要手动进行类型装换和取值判断适配

  下一个页面在接收上一个页面传入参数时，原生小程序会将所有类型的数据都转为字符串，如：true被转为了’true’, 1被转为了’1’， undefined被转为了’undefined’，然而为了代码语义及增加代码可读性，我们需要将数据再次转为正确的类型，再进行代码逻辑编写，无疑增加了工作量和代码冗余。

• 使用到的全局属性无法监听属性值是否被其他页面或组件修改

  对于整个应用的部分数据状态，我们需要记录到全局，以便多个地方共用，而原生的开发方式中，如果不去再次触发读取全局状态值，是无法感知到值是否被更改。

• WXML文件中Mustache语法能力较弱

  WXML文件中Mustache语法对JS表达式支持较弱，微信给出的WXS解决方案对原生js语法支持度较低，且书写繁琐。而用户拿到后端返回数据时往往需要特殊处理才能正确显示在界面上。

• 页面逻辑代码中无属性监听解决方案

  当数据变化时，需要手动调用方法触发逻辑更新，增加了代码耦合度。

  mini-core框架会对原生开发造成破坏吗？

  不会，mini-core只是对代码编写形式的增强，你任然可以书写原生代码。

  了解一下？

  文档地址
  源码地址
  入门案例