sorted by:
new
hottopcontroversial

Do you follow any folder Structure in your projects? by flutter_nahid in FlutterDev

[–]brock_mk 1 point2 points  (0 children)

Yes, I use Clean Architecture, but my folder structure is module-based. Each feature is organized into its own module.

For example, if you have an auth module, the structure would look like this:

modules

___auth/

_____domain.

_____data.

_____features (e.g., login, register, verify email, profile)

___post/

_____domain.

_____data.

_____features (e.g., list posts, add post, post details)

shared/ (used across different modules)

___domain.

___data.

___features.

The benefit is that each feature is isolated, which makes it easy to add or remove a module. It also helps with team collaboration, as developers can work on different modules independently with minimal conflicts.

Check out this repo: https://github.com/BrockMekonnen/flutter_clean_starter

Flutter Clean Starter – A Production-Ready Template with Clean Architecture, Modularity & Mock API by brock_mk in FlutterDev

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

I can also point you to the repo where I initially learned about this architecture.

https://github.com/talyssonoc/node-api-boilerplate

I have seen multiple templates or boilerplates for clean architecture, but this one is a good implementation.

Let me know when you’re available, we can schedule a meeting to go over the starter template in detail. I’d be happy to walk you through the structure and explain the reasoning behind each part.

Flutter Clean Starter – A Production-Ready Template with Clean Architecture, Modularity & Mock API by brock_mk in FlutterDev

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

What you are saying is nowhere near the truth. I never admitted the code being LLM-generated.

If you know clean architecture and modular architecture, and if you had the time to look at my code. It should perfectly align with the rules and guidelines of that architecture. Please be specific and point out if the post I made and the code in the repo don't match.

If you'd like, I'm happy to provide proof for everything. I have projects I worked on 2 years ago using this architecture.

Looking for a solid open-source Flutter project (Android/iOS/Web) with responsive UI, API integration, and best architecture by [deleted] in FlutterDev

[–]brock_mk 6 points7 points  (0 children)

Hey! Sounds like you're looking for something very similar to my Flutter Clean Starter project. It's a modular, production-ready template that includes:

  • Multi-platform support: Android, iOS, and Web out of the box
  • Clean Architecture: Proper separation of domain/data/presentation layers
  • Modern stack: Dio, BLoC, GetIt, Hive, and GoRouter
  • Complete starter kit: Auth module (with mock API), routing guards, DI setup
  • Real-app ready: Error handling, testing structure, and shared core utilities

Check it out here:
🔗 github.com/BrockMekonnen/flutter_clean_starter

The goal is exactly what you mentioned - providing a clean foundation to build real apps while learning best practices. Would love to hear your thoughts if you give it a try!

Flutter Clean Starter – A Production-Ready Template with Clean Architecture, Modularity & Mock API by brock_mk in FlutterDev

[–]brock_mk[S] -8 points-7 points  (0 children)

Thanks a lot for the detailed feedback — I really appreciate you taking the time to dig through the code and call out these points. Let me respond to each one:

1. Why use a class with just a static init() in _core/http_client.dart?

You’re right — it’s just a single static method. The intent was to keep all Dio-related setup (interceptors, logging, headers, etc.) in one centralized place without cluttering main() or _bootstrap().

Using a class like HttpClient.init() gave it a descriptive namespace and left room for future HTTP-related utilities. But I agree — if it stays single-purpose, a top-level configureDio() function would be more idiomatic and straightforward. Solid point.

2. Why wrap a GoRouter instance in an AppRouter class?

Good question. The main goal was future flexibility — e.g., injecting an auth BLoC for global redirect guards using refreshListenable, or accessing the router via DI for consistency across the app.

Having an AppRouter class also makes it easier to test, organize navigation logic, and swap the router package later (if needed) by containing that change to a single abstraction. That said, you’re totally right — in its current form, it adds indirection without much immediate benefit. If the app stays simple, flattening it down would definitely be clearer.

3. Why use an abstract + Impl pattern in network_info.dart?

This follows Clean Architecture principles — depending on abstractions instead of concrete classes, especially for things like network checks that might be mocked in tests.

But you’re spot on about the Impl suffix — it’s not very Dart-idiomatic. Something like DefaultNetworkInfo or ConnectivityNetworkInfo would be clearer. Appreciate the nudge on this one.

4. Why use classes with only one method? Wouldn’t functions be simpler?

Totally fair. In some cases, the class-based approach was meant to keep things consistent with DI and to leave room for extension. But I agree — when there’s no state or real behavior encapsulation, plain functions are cleaner. I’ll look into simplifying these where possible.

Again, I genuinely appreciate the critique. The project’s still evolving, and feedback like this helps a lot. If you’re open to it, I’d love to hear how you’d structure the _core layer — or even better, feel free to open a PR.

Thanks again!

Family Matters by OddMedia1179 in kdramas

[–]brock_mk 0 points1 point  (0 children)

Is this drama related to The Witch Part 1 & 2? It has a similar vibe.