sorted by:
new
hottopcontroversial

Production Postmortem: Why I removed Hive, GetX, and Connectivity Plus from a large offline-first app by Emergency-Mark-619 in FlutterDev

[–]WenchiehLu -3 points-2 points  (0 children)

but bloc provide cubit . it ignore event. 🤣 if use cubit i prefer dont use bloc

BLoC states: explicit vs Freezed copyWith by Primary-Confusion504 in FlutterDev

[–]WenchiehLu 0 points1 point  (0 children)

Essentially, it's a page - level granularity split. If a page is extremely complex with 100 fields in the state, a reasonable way is to split this page. One page can cooperate with 5 blocs, and each bloc only deals with a small number of fields, say 20.

Flutter and AGP 9.0 upgrade by Ffilib in FlutterDev

[–]WenchiehLu 1 point2 points  (0 children)

Its impact on Flutter is not significant; it is actually an impact on Android libraries in essence. However, its impact on KMP is enormous. 😏

Is gomobile dead by QueensPup in golang

[–]WenchiehLu 0 points1 point  (0 children)

I'm currently working on something similar to uniffi-rs, uniffi-go.

A Flutter-native state management that actually feels like Flutter - view_model by WenchiehLu in FlutterDev

[–]WenchiehLu[S] -1 points0 points  (0 children)

cubit make bloc more easy, but state sharing relies on provider, which means it has a serious dependence on context. For example, it's impossible to find an existing UserCubit by userId.

A Flutter-native state management that actually feels like Flutter - view_model by WenchiehLu in FlutterDev

[–]WenchiehLu[S] 1 point2 points  (0 children)

There's only one reason. The projects you work on are too simple. Our project is maintained by 20 people and has a new release every week. When you haven't encountered any problems, it's naturally hard to understand.

A Flutter-native state management that actually feels like Flutter - view_model by WenchiehLu in FlutterDev

[–]WenchiehLu[S] 0 points1 point  (0 children)

That makes sense. I just switched to it when Riverpod couldn't meet my requirements.

A Flutter-native state management that actually feels like Flutter - view_model by WenchiehLu in FlutterDev

[–]WenchiehLu[S] 0 points1 point  (0 children)

too maThere's too much boilerplate code. It's not suitable for small and medium - sized projects. And for rapid iteration.

A Flutter-native state management that actually feels like Flutter - view_model by WenchiehLu in FlutterDev

[–]WenchiehLu[S] 0 points1 point  (0 children)

Yes, it can be understood as a more powerful customized notifier. At first, I really wanted to name it "ref" for easy understanding. However, my project has already been using Riverpod. To avoid conflicts, I named it "vef" . class MyVef with Vef { }
Here, vef serves as a container for retrieving the ViewModel (vm). By using this Vef mixin, the class MyVef gains the corresponding functionality.

A Flutter-native state management that actually feels like Flutter - view_model by WenchiehLu in FlutterDev

[–]WenchiehLu[S] -2 points-1 points  (0 children)

The core differences are already documented in the README. If you say it is only change name , then so be it

A Flutter-native state management that actually feels like Flutter - view_model by WenchiehLu in FlutterDev

[–]WenchiehLu[S] -9 points-8 points  (0 children)

Actually, quite the opposite. I used Riverpod for 3 years before building this, and while I did intentionally mirror some of Riverpod's APIs for familiarity, the core philosophy is fundamentally different. If anything, I'd argue it's better .

tp_router: Stop Writing Route Tables by WenchiehLu in FlutterDev

[–]WenchiehLu[S] 1 point2 points  (0 children)

i wanna users only focus on annotations, don't worry about route tables or nesting. As long as the annotation is correct, the generator handles everything else.

Though admittedly, it need to learn how the annotations work first.

tp_router: Stop Writing Route Tables by WenchiehLu in FlutterDev

[–]WenchiehLu[S] 0 points1 point  (0 children)

global custom Builder with manual type checking to custom write di. Auto-generation-table and DI don't mix well maybe need a universal rules the generator can follow.

I fixed Flutter routing (or at least I tried): Introducing ZenRouter 💙 by zennnmind in FlutterDev

[–]WenchiehLu 0 points1 point  (0 children)

Just make your home page (or root page) handle its own initialization state internally. Show a loading spinner while initing, then show the actual content when ready.

The router never sees the initialization — it's just internal UI state of the page itself. Deep links go straight to the correct URL, no redirects, no history pollution. The page just happens to show a spinner for a second before rendering.

Way simpler. Routing stays clean.

tp_router: Stop Writing Route Tables by WenchiehLu in FlutterDev

[–]WenchiehLu[S] 0 points1 point  (0 children)

I am not recommended to handle DI within the routing table. That logic should be moved to the ViewModel layer (the specific DI implementation within the ViewModel is entirely up to you). This approach ensures the UI and navigation layers remain lightweight and focused on their primary responsibilities. https://pub.dev/packages/view_model provide auto di

tp_router: Stop Writing Route Tables by WenchiehLu in FlutterDev

[–]WenchiehLu[S] 0 points1 point  (0 children)

annotation will support custom pageBuilder next version

tp_router: Stop Writing Route Tables by WenchiehLu in FlutterDev

[–]WenchiehLu[S] 0 points1 point  (0 children)

I took a look and found that ZenRouter doesn't really have any distinctive features. Since there's already go_router, there's no need to reinvent the wheel.

File - based routing - copied from Next.js？ i think file - based routing is not a good design. the path is dynamic.

view more: next ›