GetX代码生成IDEA插件，超详细功能讲解（透过现象看本质）

本文更新非常频繁，最新内容请查看：最新内容---GetX代码生成IDEA插件功能说明

前言

本文章不是写getx框架的使用，而且其代码生成IDEA插件的功能讲解

我之前写过俩篇很长很长的getx文章

一篇入门使用：Flutter GetX使用---简洁的魅力！

一篇原理深度剖析：Flutter GetX深度剖析 | 我们终将走出自己的路（万字图文）

鱼和渔都已经交给大家了，就没必要去赘述了

同时，我也写了一个getx代码生成插件：getx_template，这个工具相当于钓鱼座椅（让你更舒服的钓鱼或吃鱼？）吧！初期功能十分简单，就是生成单页面相应的模块代码，连个记忆选项功能都没有，基本上就是个塑料座椅的程度

但是随着大量叼毛靓仔给我提的各种需求，这个插件变的已经有点复杂了
尤其是涉及Select Function模块，有些人可能都搞不懂选中的功能按钮是啥意思，就一通全部勾中。。。
所以，本凤雏想详细的，和各位卧龙谈谈这个工具方方面面的功能，希望能帮助各位节省点开发时间

兄弟们，我实在不想写水文；但是这个工具一个功能按钮，改变的代码可能很少，其背后所蕴含的东西，可能需要大量的笔墨去描述，这边就统一的和各位彦祖于宴亦菲们，说道说道。

本文长期更新，如果想知道插件每次详细更新内容，可以点进来看。

代码生成

Plugins里搜索getx即可

对比

早期代码生成弹框，可选功能比较少，当时还不支持持久化储存
- 淦，图标也丑

20210130182809

这是多次完善后的功能选择弹窗

getx_new

鄙人是个十足的颜值党，这次最新版本的页面，我做了很多考量

首页随着各位靓仔提的各种需求，Select Function，从最初的俩个功能，增加到现在的七个功能
- 随着功能按钮的增多，在dialog上平铺下来，整个dialog的高度会变得相当的长
- 最重要的是：会让使用者，不明确Function里面的重点功能按钮是什么！
基于上述的思考，我绞尽脑汁的想解决这个问题
- 方案一：我本来是想做一个折叠收纳区域，次要功能按钮放在折叠区域中
  - 用swing一通写后，发现效果是真的丑，收纳的时候，高度计算也有问题：放弃
- 方案二：这个是我在翻swing控件的时候，发现了 JBTabbedPane 这个tab控件
  - 效果简洁优雅，完爆折叠思路：采用
这次我全面的改善了dialog布局问题
- 以前的整个dialog的长宽是写死的，在高尺寸的分辨率屏幕上会存在问题
- 这次，发现了pack方法的妙用（swing菜狗的辛酸泪），全面重构的界面布局逻辑
这一次，在48寸的屏幕上，肯定不会出现下面这种情况了

虽然我没试，但是我对自己的代码有信心

模式选择

这里提供俩种大的模式选择：default，easy

来看下区别

default模式

view

class TestPage extends StatelessWidget {
  final logic = Get.put(TestLogic());
  final state = Get.find<TestLogic>().state;

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

logic

class TestLogic extends GetxController {
  final TestState state = TestState();
}

state

class TestState {
  TestState() {
    ///Initialize variables
  }
}

Easy模式

view

class TestPage extends StatelessWidget {
  final logic = Get.put(TestLogic());

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

logic

class TestLogic extends GetxController {

}

总结

上面的default模式和easy模式，从代码上看，还是能看出很明显的区别

Default模式比Easy模式多了一个State层
State是专门用来存放页面变量和初始化相关变量数据的

我曾写过一个比较复杂模块

页面的变量达到几百个（涉及到复杂的表单提交），与用户的事件交互也有几十个
整个模块很多逻辑依靠相关变量去标定，会初始化很多不同数据，State层的代码几乎快一千行
所以当业务逐渐的复杂，State层并不薄，他支撑着整个模块的逻辑标定和扭转

除非是肉眼可见的业务极简模块，推荐使用Easy模块；其余的情况推荐使用Default模式

main（主要功能）

useFolder，usePrefix

useFolder和usePrefix功能比较简单，这里就放在一起讲了

useFolder

本项功能是默认选中的，会在创建的多个文件外，创建一个文件夹，方便管理

useFolder

usePrefix

一些小伙伴喜欢在各层：view，state，logic，前加上module名的前缀（小写+下划线）

这边也为大家提供了一个这样的可选功能

usePrefix

isPageView

请注意：isPageView和autoDispose按钮不能同时选中，他们俩都能解决PageView中存的问题，选择其中一按钮，另一按钮会自动取消勾选

这算是一个非常有用的功能了

如果大家在PageView中使用getx，可能会发现，所有的子页面中的GetXController，一下全被注入了！并不是切换到对应页面，注入对应的GetXController！

PageView(children: [
    FunctionPage(),
    ExamplePage(),
    SettingPage(),
])

分析

我们可以来分析下，为什么会发生这种情况，来看下：FunctionPage

class FunctionPage extends StatelessWidget {
  final logic = Get.put(FunctionLogic());
  final state = Get.find<FunctionLogic>().state;

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

我们注入的步骤，是放在类的成员变量作用域

这个作用域是在实例化构造函数之前起效的
所以我们在添加被实例的Page的时候，成员变量的作用域直接被触发，GetXController就被注入

PageView触发机制

PageView触发被添加Widget，是触发对应Widget的build方法
切换到哪个Widget，就触发对应Widget的build方法

有了上面这层理解，就很容易解决PageView的问题了

只需要将注入过程放在build方法中
因为我们使用的是StatelessWidget，并不需要考虑其刷新问题，只有它的父节点刷新，它才会被刷新
GetX存储对象使用的putIfAbsent方法，只会存储第一次注入对象，后续相同类的对象直接忽略，这能避免很多问题

处理

所以此功能只需要改变View文件里，GetXController的注入位置即可（其它文件不需要改动）

class FunctionPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final logic = Get.put(FunctionLogic());
    final state = Get.find<FunctionLogic>().state;

    return Container();
  }
}

对比

isPageView

addBinding

binding是为了统一管理GetXController，来看下binding和非binding的区别

addBinding

非Binding

view

class TestOnePage extends StatelessWidget {
  final logic = Get.put(TestOneLogic());

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

logic

class TestOneLogic extends GetxController {

}

Binding：需要配套GetX路由

binding

class TestTwoBinding extends Bindings {
  @override
  void dependencies() {
    Get.lazyPut(() => TestTwoLogic());
  }
}

view

class TestTwoPage extends StatelessWidget {
  final logic = Get.find<TestTwoLogic>();

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

logic

class TestTwoLogic extends GetxController {

}

需要在路由模块绑定下这个binding

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return GetMaterialApp(
      initialRoute: RouteConfig.testOne,
      getPages: RouteConfig.getPages,
    );
  }
}

class RouteConfig {
  static const String testTwo = "/testTwo";

  static final List<GetPage> getPages = [
    GetPage(
      name: testTwo,
      page: () => TestTwoPage(),
      binding: TestTwoBinding(),
    ),
  ];
}

总结

binding文件里面，使用的是懒注入：在使用了find方法的时候，才会真正的注入

所以在view里面，就需要将put改成find就行了，总结下

增加binding文件，使用懒注入
view文件，put改成find
需要在getx路由模块，对应的页面上绑定binding实例

minor（次要功能）

addLifecycle

这是个非常简单的功能，就放在次要功能tab下

一些小伙伴，logic模块需要经常写onReady和onClose回调，懒得每次手写；所以在插件里添加了自动补上这俩个回调的功能

仅仅Logic文件有区别，开启该功能时：会自动添加onReady()和onClose()方法

class TestLogic extends GetxController {
  final TestState state = TestState();

  @override
  void onReady() {
    // TODO: implement onReady
    super.onReady();
  }

  @override
  void onClose() {
    // TODO: implement onClose
    super.onClose();
  }
}

对比

addLifecycle

autoDispose

该功能正如名字一样：自动释放GetXController；实际上，这是个非常重要的功能，但是实现的太不优雅了，就把它移到了次要功能tab里面了

在我们使用GetX的时候，可能没什么GetxController未被释放的感觉，这种情况，是因为我们一般都是用了getx的那一套路由跳转api（Get.to、Get.toName...）之类：使用Get.toName，肯定需要使用GetPage；如果使用Get.to，是不需要在GetPage中注册的，Get.to的内部有一个添加到GetPageRoute的操作

通过上面会在GetPage注册可知，说明在我们跳转页面的时候，GetX会拿你到页面信息存储起来，加以管理，下面俩种场景会导致GetxController无法释放

GetxController可被自动释放的条件
- GetPage+Get.toName配套使用，可释放
- 直接使用Get.to，可释放
GetxController无法被自动释放场景
- 未使用GetX提供的路由跳转：直接使用原生路由api的跳转操作
- 这样会直接导致GetX无法感知对应页面GetxController的生命周期，会导致其无法释放

Navigator.push(
    context,
    MaterialPageRoute(builder: (context) => XxxxPage()),
);

由此，可从上面可以看出，GetxController无法被释放的场景：不使用GetX路由

最优解

有个最优解方案，就算你不使用Getx路由，也能很轻松回收各个页面的GetXController，感谢 @法的空间在评论里指出

手动让getx感知路由

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: HomePage,
      ///此处配置下！
      navigatorObservers: [GetXRouterObserver()],
    );
  }
}

///自定义这个关键类！！！！！！
class GetXRouterObserver extends NavigatorObserver {
  @override
  void didPush(Route<dynamic> route, Route<dynamic>? previousRoute) {
    RouterReportManager.reportCurrentRoute(route);
  }

  @override
  void didPop(Route<dynamic> route, Route<dynamic>? previousRoute) async {
    RouterReportManager.reportRouteDispose(route);
  }
}

讲真的，这个原理其实很简单，但是思路很有趣；大家点进reportCurrentRoute 和 reportRouteDispose 这俩个方法，大概就知道是怎么回事了

reportCurrentRoute 就是让当前的路由标定给GetX
当我们进入一个页面的时候，相应GetXController会进行初始化，最终会调用 _startController<S>({String? tag})方法
_startController中会调用RouterReportManager.appendRouteByCreate(i)，将注入的GetXController都保存起来
保存在一个map中，key为当前路由route，value为HashSet，可以保存多个GetXController
ok，路由关闭的时候，在reportRouteDispose方法中回收，key为当前route，遍历value中所有的GetXController回收
我giao，基于这种思路，大家能干很多事了！！！

StatefulWidget方案

如果上面的最优解没法帮你解决GetXController的回收问题，你可能就遇到特殊的场景了，一般来说，分析分析你自己的代码，基本都能分析出来

如果懒得分析原因，就试试下面这种折中方案吧；颗粒度极小，针对单页面维度解决

这边我模拟了上面场景，写了一个解决方案

第一个页面跳转

Navigator.push(
    Get.context,
    MaterialPageRoute(builder: (context) => AutoDisposePage()),
);

演示页面
- 这地方地方必须要使用StatefulWidget，因为在这种情况，无法感知生命周期，就需要使用StatefulWidget生命周期
- 在dispose回调处，把当前GetxController从整个GetxController管理链中删除即可

class AutoDisposePage extends StatefulWidget {
  @override
  _AutoDisposePageState createState() => _AutoDisposePageState();
}

class _AutoDisposePageState extends State<AutoDisposePage> {
  final AutoDisposeLogic logic = Get.put(AutoDisposeLogic());

  @override
  Widget build(BuildContext context) {
    return BaseScaffold(
      appBar: AppBar(title: const Text('计数器-自动释放')),
      body: Center(
        child: Obx(
          () => Text('点击了 ${logic.count.value} 次',
              style: TextStyle(fontSize: 30.0)),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => logic.increase(),
        child: const Icon(Icons.add),
      ),
    );
  }

  @override
  void dispose() {
    Get.delete<AutoDisposeLogic>();
    super.dispose();
  }
}

class AutoDisposeLogic extends GetxController {
  var count = 0.obs;

  ///自增
  void increase() => ++count;
}

看到这，你可能会想，啊这！怎么这么麻烦，我怎么还要写StatefulWidget，好麻烦！

各位放心，这个问题，我也想到了，我特地在插件里面加上了自动回收的功能

如果你写的页面无法被回收，记得勾选autoDispose
- 怎么判断页面的GetxController是否能被回收呢？实际上很简单，上面的未被释放的场景已经描述的比较清楚了，不清楚的话，就再看看

来看下代码，default模式一样可以的

view

class AutoDisposePage extends StatefulWidget {
  @override
  _AutoDisposePageState createState() => _AutoDisposePageState();
}

class _AutoDisposePageState extends State<AutoDisposePage> {
  final AutoDisposeLogic logic = Get.put(AutoDisposeLogic());

  @override
    Widget build(BuildContext context) {
      return Container();
    }

  @override
  void dispose() {
    Get.delete<AutoDisposeLogic>();
    super.dispose();
  }
}

logic

class AutoDisposeLogic extends GetxController {

}

优化StatefulWidget方案

上面的是个通用解决方法，你不需要额外的引入任何其它的东西；但是这种方案用到了StatefulWidget，代码多了一大坨，让我有点膈应

鄙人有着相当的强迫症，想了很久，从外部入手，我就写了一个通用控件，来对相应的GetXController进行回收

GetBindWidget

本控件含义：将GetXController和当前页面的生命周期绑定，页面关闭时，自动回收
该控件可以回收单个GetXController（bind参数），可以加上对应tag（tag参数）；也可以回收多个GetXController（binds），可以加上多个tag（tags参数，请和binds 一一对应；无tag的GetXController的，tag可以写成空字符：""）

import 'package:flutter/material.dart';
import 'package:get/get.dart';

/// GetBindWidget can bind GetxController, and when the page is disposed,
/// it can automatically destroy the bound related GetXController
///
///
/// Sample:
///
/// class SampleController extends GetxController {
///   final String title = 'My Awesome View';
/// }
///
/// class SamplePage extends StatelessWidget {
///   final controller = Get.put(SampleController());
///
///   @override
///   Widget build(BuildContext context) {
///     return GetBindWidget(
///       bind: controller,
///       child: Container(),
///     );
///   }
/// }
class GetBindWidget extends StatefulWidget {
  const GetBindWidget({
    Key? key,
    this.bind,
    this.tag,
    this.binds,
    this.tags,
    required this.child,
  })  : assert(
          binds == null || tags == null || binds.length == tags.length,
          'The binds and tags arrays length should be equal\n'
          'and the elements in the two arrays correspond one-to-one',
        ),
        super(key: key);

  final GetxController? bind;
  final String? tag;

  final List<GetxController>? binds;
  final List<String>? tags;

  final Widget child;

  @override
  _GetBindWidgetState createState() => _GetBindWidgetState();
}

class _GetBindWidgetState extends State<GetBindWidget> {
  @override
  Widget build(BuildContext context) {
    return widget.child;
  }

  @override
  void dispose() {
    _closeGetXController();
    _closeGetXControllers();

    super.dispose();
  }

  ///Close GetxController bound to the current page
  void _closeGetXController() {
    if (widget.bind == null) {
      return;
    }

    var key = widget.bind.runtimeType.toString() + (widget.tag ?? '');
    GetInstance().delete(key: key);
  }

  ///Batch close GetxController bound to the current page
  void _closeGetXControllers() {
    if (widget.binds == null) {
      return;
    }

    for (var i = 0; i < widget.binds!.length; i++) {
      var type = widget.binds![i].runtimeType.toString();

      if (widget.tags == null) {
        GetInstance().delete(key: type);
      } else {
        var key = type + (widget.tags?[i] ?? '');
        GetInstance().delete(key: key);
      }
    }
  }
}

使用非常的简单

/// 回收单个GetXController
class TestPage extends StatelessWidget {
  final logic = Get.put(TestLogic());

  @override
  Widget build(BuildContext context) {
    return GetBindWidget(
      bind: logic,
      child: Container(),
    );
  }
}

/// 回收多个GetXController
class TestPage extends StatelessWidget {
  final logicOne = Get.put(TestLogic(), tag: 'one');
  final logicTwo = Get.put(TestLogic());
  final logicThree = Get.put(TestLogic(), tag: 'three');

  @override
  Widget build(BuildContext context) {
    return GetBindWidget(
      binds: [logicOne, logicTwo, logicThree],
      tags: ['one', '', 'three'],
      child: Container(),
    );
  }
}

/// 回收日志
[GETX] Instance "TestLogic" has been created with tag "one"
[GETX] Instance "TestLogic" with tag "one" has been initialized
[GETX] Instance "TestLogic" has been created
[GETX] Instance "TestLogic" has been initialized
[GETX] Instance "TestLogic" has been created with tag "three"
[GETX] Instance "TestLogic" with tag "three" has been initialized
[GETX] "TestLogicone" onDelete() called
[GETX] "TestLogicone" deleted from memory
[GETX] "TestLogic" onDelete() called
[GETX] "TestLogic" deleted from memory
[GETX] "TestLogicthree" onDelete() called
[GETX] "TestLogicthree" deleted from memory

LintNorm

pub：lint库

这个功能，乍一看，大家估计都懵逼了；这要不是我写的，我看了也懵逼啊

但是，这个功能，真是少部分强迫症患者的福音

因为getx作者，在demo项目里面，引入的lint库，一些小伙伴可能也用了这个库

lint是一个严格规则的代码库，对于代码相应不规范的地方，会通过IDEA给与提示；对于我们很多认为合理的代码，有时候可能也会给出相应的警告

在生成的模板代码，有几行就会在lint规则下被警告
- 这俩个注入代码，都会自动推导出对应的类型；但是在lint规则下，会有黄色下划线警告

需要做这样的调整，才能去掉警告

选中lintNorm按钮，就会以下面这种形式生成模板代码；所以说这个功能是强迫症患者福音。。。

对于用lint这种强规则的人，我表示：

pub：flutter_lints

最近Flutter在新建项目里面，默认加上了flutter_lints这个库，这个库的规则宽松很多，规则基本也是规范flutter的写法

生成了模板代码里面，会有一个警告

需要做如下调整，才能去掉警告

当你开启lintNorm，也会帮你补上生成页面的构造函数

template（切换模板命名）

场景

该功能提供了切换模板命名的操作

提供三套模板命名，只提供三套，不会再多增了

内部对持久化模块进行了重构

不重构不行，增加了大量的持久化变量，还全部使用静态变量着实不优雅
增加了数据类，来记录大量重复的持久化数据

为什么要提供切换模板命名的功能？

当业务逐渐的复杂，很多时候，复杂的通用组件，也可以使用getx去封装

但是使用插件生成对应模块，view模块的Widget可能还是为XxxPage
上面这种情况就不太友好了，你可能需要XxxComponent或者XxxWidget
虽然，可以在设置里重命名后缀名，但是这样可能又对生成Page模块产生影响
所以，这里提供三套模板命名切换，可以快速切换到你需要的自定命名方式

功能演示

插件窗口增加三套模板切换

选择Template，提供三套切换模板命名：Page、Component、Custom
- 默认Page

三套模板命名都支持自定义修改

上面的切换，对应设置页面的三套自定义通用后缀
- 设置页面布局也重写了，看起来更舒服一些，对整体空间利用率也更高了

示例

mode选择：Easy；Template选择：Component

看下代码

view

class TestComponent extends StatelessWidget {
  final logic = Get.put(TestLogic());

  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

logic

class TestLogic extends GetxController {

}

Wrap Widget

这是一个非常好用的功能

目前支持四种Wrap Widget类型：GetBuilder，GetBuilder（autoDispose），Obx，GetX

使用注意事项：鼠标点击在Widget上即可，然后按 alt+enter；请勿双击选中Widget名字

GetBuilder

GetBuilder

GetBuilder（Auto Dispose）
- assignId设置为true：GetBuilder就会在页面被回收的时候，自动回收其指定泛型的GetXController

GetBuilder（Auto Dispose）

Obx
- 说下这里为什么不用箭头符号，如果需要包裹的Widget非常长的话，使用箭头符号后，格式化后的代码并不整齐
- 考虑到这种情况，所以使用了return形式

Obx

GetX
- 这个组件我虽然不太喜欢用，但是指不定有喜欢用的小伙伴，就加上了

GetX

可选择性关闭

快捷代码生成

插件也为大家提供了，输入关键字生成快键代码片段的功能

请注意：关键字前缀为getx

路由模块

getxroutepagemap

getxroutepagemap

getxroutename

getxroutename

getxroutepage

getxroutenpage

getxto，getxtoname

getxto

getxoff，getxoffall，getxoffnamed，getxoffallnameed

getxoff

依赖注入

getxput

find

getxfind

lazyPut

getxlazyput

业务层

GetxController

getxcontroller

getxfinal，getxfinal_

getxfinal

getxget，getxget_

getxget

getset，getset_

getset

其它

getsnakebar，getdialog，getbottomsheet

getxdialog

getxbuilder，getxobx

getxobx

binding

getxbinding

还有其它的一些快捷代码，自行感受喽~~

Setting功能

随着功能的不断增加，一些细分功能，需要在放在设置模块里了，是时候写下详细说明了。

lintNorm细分

开启 lintNorm 功能时，生成的模板代码是支持俩种库的：lint 和 flutter_lints

现在对支持做了细分，大家可以随意设置：支持其中一种库或者都支持

useFolderSuffix

这个功能可以选择是否使用文件夹后缀，默认关闭

useFolderSuffix未选中的时候

设置页面

生成的文件夹是这样的

useFolderSuffix选中的时候

设置页面

文件夹后追加后缀

追加的后缀，是各Template中ViewName字段

版本更新说明

3.2.x

增加模板切换功能，大幅度优化内部持久化方式
重构设置页面布局
支持 flutter_lints 规则
拆分lintNorm：lint 和 flutter_lints （可在设置里自定义支持）
修复Template标题丢失（感谢 @胶带帮忙测试）
设置里增加useFolderSuffix功能

3.1.x

显著的提升整体页面布局
- 高尺寸屏幕不会再出现坑比问题了
支持lint规则（lintNorm）
改善快捷代码提示功能，“get”前缀改成为“getx”
- get为前缀，会让提示代码被很多系统代码淹没，改为getx之后就可以一目了然了
插件描述页面，添加本篇文章链接

3.0.x

项目代码从Java迁移为kotlin
ModuleName输入：首字母小写，内部会自动标为大写
增加大量快捷代码片段生成
插件项目逻辑重构，界面层和逻辑层分离
Wrap Widget增加：GetBuilder（Auto Dispose）
- 可自动回收对应的GetXController
增加PageView解决方案
修复一些bug

2.1.x

重大更新！
增加Wrap Widget：GetBuilder，Obx，GetX
增加快捷代码片段生成
大幅度优化插件布局
增加完善生命周期回调功能（addLifecycle）
添加binding功能（addBinding）

1.5.x

增加记忆功能（记忆选择的按钮）
添加GetXController自动回收功能（autoDispose）
支持修改通用后缀：view，logic，state
调整插件说明，修复一些bug

1.3.x

适配多版本的IDEA（之前只适配了一个IDEA版本，坑）
添加插件logo
增加一篇getx英文文章（机翻自己的博客文章）
改善插件描述

1.2

调整描述内容

1.1

修复增加前缀时，发生的导包异常问题

1.0

你可以使用本插件生成大量的getx框架代码
这能大大提升你的效率
如果有任何问题，欢迎给我提issue；提之前：请先思考下，合不合理

最后

在不断完善这个插件的时候，也是我不断思考的一个过程，

感谢大家提的各种蛋痛的需求

能让这个插件一点点的完善，以至于现在,，能真正的帮助靓仔们节省一点开发时间

系列文章 + 相关地址

GetX代码生成IDEA插件，超详细功能讲解（透过现象看本质）

前言

代码生成

对比

模式选择

main（主要功能）

useFolder，usePrefix

isPageView

addBinding

minor（次要功能）

addLifecycle

autoDispose

LintNorm

template（切换模板命名）

场景

功能演示

Wrap Widget

快捷代码生成

路由模块

依赖注入

业务层

其它

Setting功能

lintNorm细分

useFolderSuffix

版本更新说明

最后

小呆呆666

引用和评论

横扫鸿蒙弹窗乱象，SmartDialog出世

CSS团队协作规范

100个React最佳实践小技巧

不使用 JS 纯 CSS 获取屏幕宽高

前端开发工具

开发插件集合

CSS 现在终于支持高度 auto 过渡动画了