[EPIC] Restructure the flutter_templates

[manh-t]

Why

Currently, the flutter_templates repository is a mix between the template and Flutter project. It could confuse a new-dev (ex. why do we have Makefile inside a Flutter project?), and it's hard to maintain when the template stuff grows.

As discussed in the Flutter-guild meeting, we came to an agreement to re-structure the flutter_templates with the following:

• Create a .template directory and move Flutter-related stuff into this dir. Now, .template will become a place to store the Flutter project.
• Keep template-stuff (e.g. scripts/, Makefile, etc) at root.
• For optional features, we may store them in .features directory and add them to the generated project via the scripts. (need more info later 🐕‍🦺 )
• The team decided not to create an example project to present our MVVM structure but implement it directly to our .template. WHY?
  • When creating the example project, we have to implement the features in more detail (List screen, detail screen). It requires more effort but brings less value for us.
  • When initializing a project, we don't need to manually copy & paste repository, service, use case, etc. We may also need to update the repository name or service name that matches our project context via script.

Please let me know if I'm missing something. I welcome comments for improvement 🙇

More tasks will come for this epic 🚀

Who Benefits?

Developers, maintainers.

[sleepylee]

@manh-t I'm a bit concerned with the last idea:

The team decided not to create an example project to present our MVVM structure but implement it directly to our .project. WHY?

The main concern to me is NOT about enforcing us to have it, but rather the later phase that might make us fall in the same trap as before:

present our MVVM structure but implement it directly

There are a few things we need to reconsider:

• If we don't want to have example/ - fine, but then we shouldn't implement a concrete implementation at the root level because it might not match with our expectation later on. Let's say you want to switch to the VIPER pattern, we can't make it happen unless developer has to:

  • Init the project with MVVM
  • Remove the ViewModel
  • Adding Router... => As you can see, that is cumbersome.

• My suggestion is that we should keep the root clean, only just to have the implementation ready at the:

  • Dependencies declaration (flutter version, lib version...)
  • Networking or HTTP service ready to use.
  • Logging, crashlytics, utility lib setup... => Anything above that (repository, use case) should be added by the developers who init a project from the template. The other way is that we should add mvvm as a feature option (so later you can add viper if anyone wants to support it). This can ensure the project will be extensible when technology evolves.

Now back to the example:

we have to implement the features in more detail (List screen, detail screen).

• First, we should NOT implement this in the root project either. Remember that it might cost us removal effort later when we don't want to have them.
• So what option do we have to demonstrate the templated project? Imo, that's why I suggested we have multiple examples inside example/. If an example is outdated, or when we add a new major feature, instead of changing it we can have another examples directory: ---examples/ |--mvvm/ |--viper/ |--xyz/

If you are still unsure about it, I recommend NOT taking the example/ idea into it yet, but rather, just cleaning up the project and getting everything ready at first with architecture as a feature option (mvvm or default == None).

@markgravity @doannimble @luongvo please feel free to debate 🙇

[manh-t]

@sleepylee your concern is valid 🤗 we already discussed the structures used in flutter_templates too, then it comes to challenges which are:

• If the mvvm has a piece of code that need to append/ modify an existing file (e.g., change network_module.dart to add service class into this), we need to build a script (or find a third-party lib) that can update the existing file properly (maybe the file will be maintained to fix or add more code, the script is still able to edit it).
• How to verify the code we added into mvvm is correct via CI/CD. So we fall back to a more straightforward option, as mentioned in the description above 🙇

If you are still unsure about it, I recommend NOT taking the example/ idea into it yet, but rather, just cleaning up the project and getting everything ready at first with architecture as a feature option (mvvm or default == None).

Okay, I will not take the example idea into the project until the idea becomes possible to me 🙇 perhaps I'll create a PoW first 😁

[sleepylee]

If the mvvm has a piece of code that need to append/ modify an existing file (e.g., change network_module.dart to add service class into this), we need to build a script (or find a third-party lib) that can update the existing file properly

I think if the change is small, we should just update it to the current example repo.

How to verify the code we added into mvvm is correct via CI/CD.

If you do it manually as above, then you can verify it. The idea is that CI/CD should only verify a project init from the template but NOT committed to the vcs.

So, what happens if there are more updates that you can't bring to the example repo we already had? 👉 create a new example from the latest state of the template. Adding the same small demo features that can ensure you will have the latest example code.

[manh-t]

@luongvo I think we can close this epic, since the project was re-organized in 1.0.0. What do you think?

[luongvo]

@manh-t I'm planning a short flutter-templates meeting every 2 weeks or 1 month to discuss the plan & backlog. I think we can have decisions from that meeting, I will send you guys the invitation for the first one soon 👋