前言
一个开源库，随着不断的迭代优化，难免会遇到一个很痛苦的问题
- 最初的设计并不是很合理：想添加的很多新功能都受此掣肘
想使得该库更加的强大和健壮，必须要做一个重构
- 因为重构涉及到对外暴露的api，所以大家会遇到一个比较烦躁的问题：更新版本后，会大面积报错
- 我考虑了很久，到底怎么帮大家快速迁移呢？最终想到了一个还算合理的方案
对于flutter_smart_dialog 4.0版本的改动，很多是为了解决自己以前考虑不周的历史遗留，以前这个库的初心，主要是为了解决loading和dialog穿透问题；现在扩展到：custom dialog，attach dialog，loading，toast，最初的设计真的力不从心了，config中的api难以去细分的控制这四个模块功能，一些参数的设计基于现在的功能和场景也不太合理等等
希望大家能够理解我为什么要重构