OOP

  • Although the framework recommends the use of functional programming, it also provides object-oriented programming support.
    • ViewPart
      • Need to override the 'build' function.
      • The required state, dispatch, and viewService parameters have become fields of the object and can be used directly.
      • It is immutable, so there should be no need to define variable fields internally.
    • EffectPart
      • Need to override the 'createMap' function.
      • The required Context has been flattened as the fields which can be used directly.
      • Fields can be defined and their visibility is limited to themselves.
      • It must be used with higherEffect.
  • Sample Code
  1. class MessageView extends ViewPart<MessageState> {
  2.     @override
  3.     Widget build() {
  4.         return Column(children: [
  5.             viewService.buildComponent('profile'),
  6.             InkWell(
  7.                 child: Text('$message'),
  8.                 onTap: () => dispatch(const Action('onShare')),
  9.             ),
  10.         ]);
  11.     }
  12. }
  13.  
  14. class MessageEffect extends EffectPart<MessageState> {
  15.     ///we could put some Non-UI fields here.
  16.  
  17.     @override
  18.     Map<Object, OnAction> createMap() {
  19.         return <Object, OnAction>{
  20.             Lifecycle.initState: _initState,
  21.             'onShare': _onShare,
  22.         };
  23.     }
  24.  
  25.     void _initState(Action action) {
  26.         //do something on initState
  27.     }
  28.  
  29.     void _onShare(Action action) async {
  30.         //do something on onShare
  31.         await Future<void>.delayed(Duration(milliseconds: 1000));
  32.         dispatch(const Action('shared'));
  33.     }
  34. }
  35.  
  36. class MessageComponent extends Component<MessageState> {
  37.     MessageComponent(): super(
  38.         view: MessageView().asView(),
  39.         higherEffect: higherEffect(() => MessageEffect()),
  40.     );
  41. }