Macros (Dart/Flutter)

[GregoryConrad]

• normal, factory, action, widget, inheritedRearchWidget, side effects
• https://github.com/dart-lang/language/pull/3176/files
• Also see rearch.gsconrad.com for some proposed syntax in addition to below:

  
  @asyncCapsule
  void countPlusOneCapsule(@countCapsule int count, CapsuleHandle use) {}
  @rearchWidget
  void countDisplay(BuildContext context, @countCapsule int count, WidgetHandle use) {}

@rearchSideEffect TextEditingController _textEditingController(UseUnstatePlugin use, String? initialText) { final controller = use.memo(() => TextEditingController(text: initialText)); use.effect(() => controller.dispose, [controller]); return controller; }

// Generates an extension: extension UseTextEditingController on UseUnstatePlugin { TextEditingController textEditingController(String? initialText) { return textEditingController(this, initialText); } }

Edit: per https://github.com/GregoryConrad/rearch-dart/issues/95#issuecomment-1925828051, we should just make one macro for any type of capsule (factory, action, async etc). That leads to a cleaner API.

[opsb]

Given macros could potentially be a year away or longer, would it be worth adding the macros using build_runner for now?

[GregoryConrad]

@opsb unfortunately I don’t have the time to go out and learn build_runner right now. Macros in ReArch aren’t going to bring any new features to the table, but rather just be a QoL improvement for boilerplate reduction.