Improving Your Code With Dart Code Metrics
Getting familiar with Dart Code Metrics – Flutter Warsaw #16
Not so long ago, Dart Code Metrics became a Flutter Favourite Package listed among other great packages. We had a chance to invite Dmitry Zhifarsky to Flutter Warsaw #16 - Dart Code Metrics co-author - to our event just two days before that. Some may say it’s a coincidence. Others - it’s the power of the Flutter Community! Anyway, it’s definitely worth getting familiar with Dart Code Metrics - a static analysis tool that helps you analyze and improve your code. So as you know, Dart Analyzer isn’t the only option you have. Dmitry, during his talk, covered its features and showed how it could help you become a more efficient Dart and Flutter Developer.
Find out more about Dmitry and how he helped develop the Dart Code Metrics tool by reading the interview.
The presentation contains insights on:
- Dark Code Metrics Overview
- Metrics
- Anti-patterns
- Custom lint rules
- Lint rules pitfalls
- CLI commands
- Integrations
Watch the video about Dart Code Metrics
Questions after the Dart Code Metrics presentation:
1. You said about Codemagic integration. How did that Codemagic (cloud-based #CICD tool for building, testing, and publishing mobile applications) integration with Dart Code Metrics happen?
[Dmitry Zhifarsky]: The story is that we have a very popular Flutter podcast and we asked the CTO of Codemagic what he thinks about our project and that’s how the discussion started. We ended up collaborating on adding Dart Code Metrics integration for them, and it has been available for a few months.
2. I learned Provider but now doing more complex things is very limiting. Moving forward I am confused between Riverpod and bloc. Bloc is mature production-ready but Riverpod is new but easy to transition from a Provider. Any thoughts?
[Matej Rešetár]: This is the same as the Provider and Bloc. They can’t really be compared. Although, you can use some basic providers, whether from Riverpod or from the actual Provider package like FutureProviders, StreamProviders, you name it, and build a really good app. But you can also use Bloc together with Provider and Bloc or together with Riverpod, and it will again be a good app. It depends on your style, what you prefer, how you write code, if you like immutable state, and so on. Because you can provide Bloc using Riverpod and provide Bloc using the Provider package too. If it’s easy to transition Riverpod from Provider? I would say “yes”.
It’s a bit different mindset to go with if you use Riverpod because you don’t create providers in your widget tree. You create them as global variables, but they aren’t really globals. It’s something like classes are global, but once you instantiate an object, an instance of the class is not global. It’s local to the scope and the method. Providers from the Riverpod are declared globally, but they are locally scoped to the widget once you actually use them. And if you instantiate them, you actually just listen to them, and they instantiate automatically. Once the widget is disposed of, if you use a dispose method provided from Riverpod that Provider is also disposed. So it’s not a global thing. Riverpod is local. It can be confusing, but the same thing is with the class and an instance of the class. Class is global, but an instance of the class is not. Once you have this in mind, the transition to the Riverpod will be very easy.
[Mateusz Wojtczak]: It’s really good also to learn bloc because it’s a whole different look at state management. For example, change notifier and Provider. It’s more data-driven, so I think it’s really good to learn the concept of bloc and Qubit just for you to have in mind that you can look at the flow of the data in a different way than in an imperative way, especially in frameworks like Flutter.
3. Thoughts on monorepos and splitting up a project into multiple Dart packages? What did you do at Wrike? I don't see much benefit of splitting up into small packages, it adds complexity and doesn't bring many benefits. Am I missing something?
Dmitry: First of all, Wrike has around 20 teams working on different features of the product and they also have the concept of micro frontends. So, if you are able to keep your code in a good shape and you have the right tools, I think you probably should go with monorepo. Wrike decided to invest more in tools for multiple packages and separate deploys because they have had different teams, different deploys, and tools for multiple projects and packages in multiple repos.
The product was written in JavaScript and in ExtJS and people who worked there faced a huge problem with a single repository and decided they will never try this approach again, and that’s the reason why they have multiple repositories. I agree that there are a lot of problems with that but if you have the right tools like Melos it helps you. Also, if you can keep your codebase in your team and cooperate with them easily then monopereos is a better approach.
Mateusz: Monorepo doesn’t mean that it contains one package because you can still split your project into multiple packages and the decision about source code in the repository is orthogonal. It doesn’t have to go with each other. For example, you can have multiple packages with Mellos and it’s still monorepo. Some may think that going into multiple packages means multiple repositories but it’s not always the case. It can be even harder if you go to multiple repos especially in some complex organization.
