Let's take a look at why the common, horizontal code structure is not ideal, where it breaks down, and what we can do about it.
  • I Cast Fist@programming.dev
    2·
    2 days ago

    TLDR; don’t group files by “what they do in common” but rather the ones that “work with the same thing”. So instead of components, libraries, icons folders, group them like table1, table2, etc

    • BlackEco@lemmy.blackeco.com
      3·
      3 days ago

      Most React devs either colocate styles with their JSX with CSS-in-JS or skip CSS entirely with Tailwind class soup in their JSX. I must be one of the few that use CSS Modules instead (so CSS is in a separate file from JSX)

  • Eager Eagle@lemmy.worldEnglish
    6·
    3 days ago

    as someone who only writes frontend now and then, I agree, and I don’t know how react devs find anything in their projects with the horizontal organization. I work regularly on a small one like that and it’s already a pain every time I have to backtrack where this component I’m looking at is defined.

    I have the same strong feeling about how most distros and OSes have Projects/ Documents/ Videos/ Images/ etc in the home directory: this lazy “organization” is totally useless. The first thing I do on a fresh image is to get rid of these directories.

    They’re all grouped by what they are instead of what project / domain they belong to, so finding anything is very inconvenient. My file explorer can help grouping files by type automatically, but it won’t know what is their intent.

  • idriss@lemmy.ml
    5·
    3 days ago

    if you are following DDD and/or clean architecture, this article would be giving you terrible advice. You go vertical but the moment you need a type/utility from another place it stops making sense.

    • Kache@lemmy.zip
      2·
      2 days ago

      In the short term, a small amount of duplication to prevent bad abstraction spaghetti is worth it

      In the medium term, true duplications are better extracted after the fact rather than correctly guessing future reusability.

      In the long term, total extraction into separate vertical or external package, as suggested by the author.

      Over time, this progression is natural and unforced. If you don’t need an abstraction to be de-deuplicated, then don’t. If you don’t need to promote an abstraction into its own vertical/package, then don’t.