[HN Gopher] Whatever you do, don't autoload Rails `lib/`
       ___________________________________________________________________
        
       Whatever you do, don't autoload Rails `lib/`
        
       Author : todsacerdoti
       Score  : 28 points
       Date   : 2023-05-05 06:58 UTC (1 days ago)
        
 (HTM) web link (island94.org)
 (TXT) w3m dump (island94.org)
        
       | p-o wrote:
       | At my current place of work, we have this strategy and I think
       | it's a mistake. app/lib is just another way of writing
       | app/service. It becomes, over time, a chaotic place where
       | everything goes. If it doesn't fit for _any_ reason, app/lib
       | becomes the place where those files live.
       | 
       | The benefit of lib/ is clearer in my opinion. Files that live
       | there are only explicitly loaded. Some might be loaded in
       | development, some in production, some in test. The conversation
       | about the structure becomes more important because you need to
       | think about what is going to consume your class.
       | 
       | But I think we could take this a step further and instead replace
       | lib/ with engines/. This way, you can create multiple Rails
       | engines that will have their own paradigm and environments'
       | handling.
       | 
       | Every Rails application I got to work on had a lib/ (or
       | app/service) that could have been grouped in a few different
       | engines/. The benefit of using those kind of engines is that
       | conversation about architecture, pros/cons get more defined. At
       | least that's been my experience.
        
         | LesZedCB wrote:
         | services are IMO the biggest misfire of an attempted rails
         | convention. "service" is completely domain agnostic and because
         | there's no standard API like there is for controllers or model,
         | the "service" API ranges from `MyService.call` to
         | `MyService.new.call` `MyService.do_thing` etc etc.
         | 
         | service became the junk drawer of junk drawers even worse than
         | lib because people at least 'believe' there is supposed to be a
         | convention when there isn't. at least you know lib is kinda
         | wild west.
         | 
         | rails has failed to channel applications into domain logic once
         | it scales past start-up rapid development to a huge team of ICs
        
       | jack_riminton wrote:
       | Tbh I'm getting tired of these "you must never do x" or "you've
       | been doing y wrong" articles, they're always such overblown
       | statements for mostly trivial things
        
         | btown wrote:
         | While this is generally true, systems like Rails have so much
         | magic going on that "best practices" are actually closer to
         | being part of a specification. Whether that's noteworthy enough
         | for a dedicated post, and why it can't just be part of Rails
         | documentation, is a separate question - but there's nothing
         | trivial about this kind of advice.
        
       | nightpool wrote:
       | Why do people keep spelling it "Mastadon"? It's such a strange
       | spelling to me, it's not how it's pronounced and it doesn't
       | really make any sense to me (unlike some mispellings where the
       | "wrong" spelling clearly makes more sense then the actual
       | spelling). But this is just a bog-standard greek root, right up
       | there with masticate and smilodon and all the other -odon
       | prehistoric animals of the world. is there some kind of
       | connection here i'm missing? It's so common that I feel like
       | there must be some kind of underlying logic driving it
        
         | kjeetgill wrote:
         | Some people just actually pronounce it as Mastadon over
         | Mastodon.
        
         | capableweb wrote:
         | I think there is a lot of topics one might discuss online that
         | you don't talk with others AFK with, and then the connection
         | between spelling<>pronunciation never gets cemented.
         | 
         | I see the same thing all the time with Etherium/Ethereum as
         | well for example.
         | 
         | I had the same problem when NGINX first came out. It wasn't
         | until maybe a year later after starting to use it that I
         | actually talked with another person AFK about NGINX, and they
         | said "engine-x" which I had never heard of.
        
         | [deleted]
        
         | BugsJustFindMe wrote:
         | The sounds are not as different as you believe they are. It's
         | the same reason people write Tobasco.
        
         | tdeck wrote:
         | > I's not how it's pronounced
         | 
         | I pronounce it rougly /maest@dan/ and I imagine many other
         | people do as well. That sounds is closer to "a" than "o".
        
         | a1369209993 wrote:
         | Probably because they're parsing it as masta+don rather than
         | mast+odon, and word-final schwa[0] is written with a "a".
         | Compare eg "arenadon", "pastadon", or other somethinga+"don"
         | psuedo-portmanteaus.
         | 
         | 0: I assume they don't pronounce it as mas-TO-don, since that
         | would be a rather bizzare stress pattern, so the "o" generally
         | gets weakened to a schwa as is typical for unstressed vowels.
        
       | [deleted]
        
       | viraptor wrote:
       | I'm not sure the article really explains why. If one of the
       | solutions is to just move lib to app/lib where it's autoloaded -
       | what's the actual issue with autoloading lib?
        
       | nico wrote:
       | What's the difference between lib and app/lib if they both
       | autoload or both don't?
       | 
       | Or is the solution to just put everything in a folder that always
       | get autoloaded?
       | 
       | Wouldn't that be the same as autoloading lib?
        
         | wkdneidbwf wrote:
         | if they both did or didn't autoload there would be no practical
         | difference.
         | 
         | but by default every dir under `app/` autoloads, and `lib/`
         | does not.
         | 
         | so using app/lib is really just a reasonable solution for not
         | breaking the existing defaults and conventions.
        
         | jrochkind1 wrote:
         | The issue OP has run into, if I understand it, is that there
         | are some things that _can 't_ autoload and work properly, and
         | when you configure lib/ with a non-default configuration to
         | autoload, there's no place for these things, as lib/ is
         | ordinarily just about the only place in a Rails app that is on
         | the load path but doesn't autoload.
         | 
         | No idea what about HN algorithm made this wind up on the front
         | page! It's not an _especially_ interesting post, I agree.
         | Perhaps just a testament to the in fact continued interest in
         | Rails?
        
       | benatkin wrote:
       | If you miss Rails but are slinging JavaScript these days there's
       | Nuxt 3. It autoloads all the things.
        
       | rco8786 wrote:
       | Ehhh I've autoloaded lib for like 10 years and never experienced
       | any of the problems the author says that arise from doing so.
        
         | buf wrote:
         | Yep - me too. Don't know what the author's on about.
        
       ___________________________________________________________________
       (page generated 2023-05-06 23:00 UTC)