The Price of Using Local Packages in Flutter

[@RobertBrunhage]

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!

[@hyungtaecf]

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.

[@rydmike]

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 😀💙

[@RobertBrunhage]

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

[@krzysztofk.8842]

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.

[@rydmike]

@@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.

[@krzysztofk.8842]

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.

[@RobertBrunhage]

Agreed

[@artofnessa]

I really LOVE the new set up you have🎉

[@DadjaBASSOU]

Should made a Tuto on how to get that one I think it’s a Vim editor

[@RobertBrunhage]

Thank you! 🧪

[@RobertBrunhage]

@@DadjaBASSOU Ohh, I have so much planned for vim content and Flutter that I almost feel bad about it 😅

[@diecat4463]

Yes. Would like a complete vim & flutter configuration tutorial. Thank you

[@RobertBrunhage]

@@diecat4463 Recorded a quick kind of showcase and "minimal" example with link to my setup. Hope to have it out this weekend!

[@easazade]

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

[@RobertBrunhage]

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.

[@easazade]

@@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]

Then you take that when the time comes. Don’t optimize for the future, write code for the ”now”.

[@chordfunc3072]

@@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.

[@TechBuddy_]

wow the nvim setup looks cool, also the new video style is good I love it

[@RobertBrunhage]

Thanks, appreciate it!

[@imamhatipoglu4040]

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.

[@RobertBrunhage]

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

[@samafaby]

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]

I just used google translate, but I think if you go for 100% test coverage you are also doing it wrong 😅

[@samafaby]

@@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. 🤔

[@leoingson]

I agree, overengineered. Being prepared for eventualities vs just solving the problem. Keep the trash coming!

[@RobertBrunhage]

We love us some trash!

[@DevLife717]

Excellent points I agree. Digging the nvim setup also but why do the line numbers seem out of sequence?

[@RobertBrunhage]

Relative line numbers Makes it simple to jump up and down specific line amounts!

[@juanignacioagu960]

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.

[@_undecided]

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.

[@jeromestsauver]

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?

[@msiprime]

so how would you handle it ????

[@KeithDCommiskey]

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.

[@RobertBrunhage]

Just copy it and don't ask questions 🙃

[@codegambit2507]

I enjoyed the video. Thank you. Please I can u share your vim config for flutter?

[@RobertBrunhage]

Just open sourced my dotfiles: github.com/RobertBrunhage/.dotfiles

[@codegambit2507]

@@RobertBrunhage thank u ❤️

[@dhanniekristanto]

It's been a while since you last upload something about flutter. I thought you switched to react 😄

[@RobertBrunhage]

I should leave for another year and learn Rust 🙃

[@mohamedislambenoaie8308]

i can't join your discord !!!! Why

[@RobertBrunhage]

Good question, what happens when you try to join?

[@mohamedislambenoaie8308]

@@RobertBrunhage unable to accept invite

[@RobertBrunhage]

@@mohamedislambenoaie8308 maybe this works? discord.gg/HF5XuSbSVS

[@mohamedislambenoaie8308]

@@RobertBrunhage Same Problem maybe i am banned or something else ?

[@RobertBrunhage]

@@mohamedislambenoaie8308 What is your discord name?

[@kuba12-n9b]

Random youtuber critizies very good ventures architecture 🤣🤣🤣 Anyway you just said words, but zero arguments, very bad video.

[@chordfunc3072]

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);

[@chordfunc3072]

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?

[@RobertBrunhage]

No, I would not spend my time on this. This is a typical case of reaching "100%" test coverage

[@RobertBrunhage]

@@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.

[@chordfunc3072]

@@RobertBrunhage It is also leacking implementation details, so its making a test that is extremely brittle