The Price of Using Local Packages in Flutter

Поділитися
Вставка
  • Опубліковано 31 бер 2023
  • I hate over complicating solutions that doesn't need it, here is my take on packages.
    I do shit here: robertbrunhage.com
    Want to support me?
    ♥ Patreon: / robertbrunhage
    ♥ BuyMeACoffee: buymeacoffee.com/robertbrunhage
    ♥ Paypal: paypal.me/robertbrunhage
    ····················································································
    You can find me on:
    ● Website: robertbrunhage.com
    ● Twitter: / robertbrunhage
    ● Join our community: / discord
    ····················································································
    😎 Subscribe: bit.ly/2SUyRhx

КОМЕНТАРІ • 55

  • @RobertBrunhage
    @RobertBrunhage  Рік тому +7

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

  • @krzysztofk.8842
    @krzysztofk.8842 Рік тому +6

    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.

  • @rydmike
    @rydmike Рік тому +8

    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
      @RobertBrunhage  Рік тому +1

      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
      @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
      @rydmike Рік тому +2

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

  • @TechBuddy_
    @TechBuddy_ Рік тому +3

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

  • @artofnessa
    @artofnessa Рік тому +6

    I really LOVE the new set up you have🎉

    • @DadjaBASSOU
      @DadjaBASSOU Рік тому +3

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

    • @RobertBrunhage
      @RobertBrunhage  Рік тому +2

      Thank you! 🧪

    • @RobertBrunhage
      @RobertBrunhage  Рік тому +5

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

    • @diecat4463
      @diecat4463 Рік тому +1

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

    • @RobertBrunhage
      @RobertBrunhage  Рік тому

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

  • @easazade
    @easazade Рік тому +5

    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
      @RobertBrunhage  Рік тому +2

      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
      @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
      @RobertBrunhage  Рік тому +1

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

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

  • @jeromestsauver
    @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?

  • @DevLife717
    @DevLife717 Рік тому +1

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

    • @RobertBrunhage
      @RobertBrunhage  Рік тому +1

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

  • @imamhatipoglu4040
    @imamhatipoglu4040 Рік тому +2

    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
      @RobertBrunhage  Рік тому +1

      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

  • @codegambit2507
    @codegambit2507 Рік тому +1

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

    • @RobertBrunhage
      @RobertBrunhage  Рік тому

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

    • @codegambit2507
      @codegambit2507 Рік тому +1

      @@RobertBrunhage thank u ❤️

  • @samafaby
    @samafaby Рік тому +2

    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
      @RobertBrunhage  Рік тому +2

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

    • @samafaby
      @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
    @leoingson Рік тому +2

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

  • @KeithDCommiskey
    @KeithDCommiskey Рік тому +1

    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.

  • @mohamedislambenoaie8308
    @mohamedislambenoaie8308 Рік тому +1

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

  • @dhanniekristanto
    @dhanniekristanto Рік тому +1

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

    • @RobertBrunhage
      @RobertBrunhage  Рік тому +1

      I should leave for another year and learn Rust 🙃

  • @juanignacioagu960
    @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
    @_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.

  • @chordfunc3072
    @chordfunc3072 Рік тому +1

    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
      @chordfunc3072 Рік тому +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?

    • @RobertBrunhage
      @RobertBrunhage  Рік тому

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

    • @RobertBrunhage
      @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
      @chordfunc3072 Рік тому

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