If you agree or disagree, let me know. I would love to be proven wrong here! Hope you find the new format interesting, I am trying it out and with that can tackle a lot more interesting topics. If there is anything you want me to cover, let me know!
I find myself in the same dilemma in my project. It currently has a lot of cons keeping all my code in the same package. I want to separate it into different packages but it seems it would become way too complex to maintain it.
Talking about overengineering. 90% of the time these packages will be only used inside this particular app so generally they could be just inside `lib` directory and be part of the app.
Nice to see you back Robert! There is a lot to be said for avoiding complexity, but sometimes it also needed. Right balance can be tricky. I'm guessing the news toolkit sample is also intended to demonstrate this technique, but went a bit overboard with it, for its particular use case. Cool studio 😀💙
Agreed, always pros and cons. Just thought this was a bit too much (have seen worse/more). Which beginners usually use as reference which results in horrible projects just for "scalability" 😅 Ohh yeah the studio. Making it in Blender, so that will hopefully look better soon haha
Haven't really looked into the news toolkit (or whatever the name is) but I think they went with the `packages` option just to facilitate copy/paste of that packages into your own app.
@@krzysztofk.8842 that makes sense, but I don't know if that is any easier or more difficult than just copying classes from a sample, after all you will have to provide your implementations to the packaged sample as well. Certainly makes it more contained. The approach has it advantages, but also increases complexity for small/mid sized apps,.where it might not be necessary.
I think in this project they made the right choice, implementing it like this. since this is a template project. and being easy to customize is the top priority. this way you have all the components of your app decoupled and hence customizing them is easier. but the trade-offs are the points you mentioned
This is the example project, why does it need to have that for the example? Those packages aren't reused anywhere? I understand the decoupling part, but it's decoupling parts that has little to no value decoupling.
@@RobertBrunhage in case of reusability I agree with you. But for big enterprise-level apps, I think this is a good approach. since any app component can get really big and needs different configurations for different releases you have based on each region or language. But sure if you're not aiming for that this is overkill.
@@RobertBrunhage 100% agree with this, So many people write closed-sourced codebases like they are immutable. Its ridiculous. Just change the thing when the time comes. Over use of abstraction is a topic that you could cover on the channel... I come over code so often where at every layer there is just a lot of unessecary abstractions. So instead of having one file with maybe 70-100 lines of code. You have 10 files with 400 lines of code where if you want to make a change you have to essentially get familiar with the whole part of the codebase because you dont know how or even if the thing you want to change is used elsewhere. So essentially the benefit that most people claim they try to deliver is not delivered upon, and you get the exact opposite effect.
Yaay 🎉 New video. İt's cool setup, i like it. I'm using GNU Emacs for Python, but it's hard on flutter. Even I love Emacs, I don't think vim or emacs good enough for flutter. About the packages you're right local packages is good for dictionary structure. İ have big project but i got long analyze times, even sometimes not response about the autocomplete, especially about the auto imports.
Interesting, my setup feels faster than VSCode. I have no prior experience with Emacs though so not sure how it's setup. I use Neovim's built in LSP to get everything I need in terms of autocomplete, imports etc. Which is the same as what VSCode uses
La respuesta universal es, depende. Depende del proyecto, del tamaño, de la estructura que la compañía defina, son muchos los factores. En mi visión con proyectos grandes, la complejidad es menor al enfocar reglas de negocios específicas en módulos o paquetes que sólo cuiden ese objetivo. En proyectos pequeños esto no sería necesario y lo consideraría sobre-ingeniería. En mi experiencia con un proyecto empresarial muy grande, estamos tratando de modularizar para acortar los tiempos de desarrollo-producción ya que nuestro talón de aquiles son los tiempos de ejecución de pruebas. Cuando el primer requerimiento es tener 100% de coverage, las pruebas tomarán mucho de tu tiempo en el día a día.
@@RobertBrunhage Es curioso ese "also", asumir que un punto de vista esté equivocado y "también" decir que una práctica esté errónea, deja mucho que pensar cuando generalmente el desarrollo es una abstracción que depende en gran parte del contexto de las diferentes necesidades, es para pensarlo. 🤔
Not all understand reason of using packages. I can explain in short. You create package then if you can use it in another app that's reason for why packages is, but if package is created only for the one app then it called overengineerig.
I think that it's ok to use the local package approach when it's necessary. I do not justify creating a LOCAL package for a single or couple of repositories, but I'm in favor to use local packages to create domain boundaries and expose only the necessary for specific modules or features.
I'm curious what some alternatives to packages might be for sharing code in flutter? I'm at a point that I would like to share a piece of functionality across 2 projects. I started down the packages path, but agree with the complexity of managing dependencies. Any thoughts about this?
After looking at the code, is having an `api` folder (or similar) as a sibling to `lib` and `packages` a common pattern? Feels weird having Dart files outside of `lib` or `packages`, but maybe I just haven't had the exposure to such.
I have a topic for you: Testing like in the news_repository_test.dart in the example app you referenced. What are your thought of this type of testing... to me it seems completely bonkers. when(apiClient.getCategories) .thenAnswer((_) async => categoriesResponse); expect( newsRepository.getCategories(), completion(equals(categoriesResponse)), ); verify(apiClient.getCategories).called(1);
Its just testing the mocking framework... This is the only thing that is actually bringing some value: verify(apiClient.getCategories).called(1); And I don't know if that is something you would test, thoughts?
@@chordfunc3072 Yes that is the only thing of value in that test. In 99% of scenarios I would not test this. I would only add a test for this if it's actually something that broke and I would just create a test to validate my fix faster. To be honest, I think this is just extra time spent with pretty much no value.
