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